Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for ApplicationGateway #3176

Merged
merged 30 commits into from
Oct 27, 2023

Conversation

vimorra
Copy link
Contributor

@vimorra vimorra commented Aug 2, 2023

Closes #2990

What this PR does / why we need it:
Add support for Application gateway service
Special notes for your reviewer:
Still working on the sample
How does this PR make you feel:
gif

If applicable:

  • this PR contains documentation
  • this PR contains tests

│ ├── Owner: github.com/Azure/azure-service-operator/v2/api/resources/v1apiv20191001.ResourceGroup
│ ├── Spec: Object (37 properties)
│ │ ├── AuthenticationCertificates: Object (2 properties)[]
│ │ │ ├── Data: *string
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this just a public key, or does it contain private details?

It looks like probably just public data based on the documentation, in which case this is fine.

Copy link
Contributor Author

@vimorra vimorra Aug 23, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the public key certificate that is uploaded to enable mtls on the application gateway, this is used by the app gateway to trust the client. It not contains sensitive data of the users.

v2/api/network/v1api20220701/structure.txt Show resolved Hide resolved
v2/api/network/v1api20220701/structure.txt Show resolved Hide resolved
},
}
publicIPAddress := newPublicIp(tc, testcommon.AsOwner(rg))
tc.CreateResourceAndWait(publicIPAddress)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

minor, you can combined all of these into a single create+wait

tc.CreateResourcesAndWait(publicIPAddress, vnet, subnet)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed

- name: app-gw-http-listner-1
frontendIPConfiguration:
reference:
armId: /subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/<rgName>/providers/Microsoft.Network/applicationGateways/<appgatewayname>/frontendIPConfigurations/<feIpConfigName>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can replace <rgname> with aso-sample-rg sincethat's the sample rg which the sample is written in the context of.
Same with appgatewayname, it can be aso-sample-application-gateway, the name of this application gateway. Use the actual feIpCOnfigName too.

Same for all the refs below as well.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed

armId: /subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/<rgName>/providers/Microsoft.Network/applicationGateways/<appgatewayname>/frontendIPConfigurations/<feIpConfigName>
frontendPort:
reference:
armId: /subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/<rgName>/providers/Microsoft.Network/applicationGateways/<appgatewayname>/frontendPorts/<fePortName>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@super-harsh, is this going to pass sample validation? Do we deal with swapping subid into raw ARM refs?

@matthchr matthchr added this to the v2.4.0 milestone Aug 28, 2023
@theunrepentantgeek theunrepentantgeek changed the title first commit app gateway Add support for ApplicationGateway Sep 1, 2023
Copy link
Member

@theunrepentantgeek theunrepentantgeek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Still a few cleanup items required (see comments by @matthchr) - including more reliance on Go type inference, which will clean up the test in controllers some. I'll have a look at the test and work out what the failure means.

@@ -1561,6 +1561,51 @@ objectModelConfiguration:
$exportAs: VirtualNetworksVirtualNetworkPeering
$supportedFrom: v2.0.0-alpha.1
2022-07-01:
ApplicationGateway:
$export: true
$supportedFrom: v2.3.0
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this will make it for v2.3.0.

Suggested change
$supportedFrom: v2.3.0
$supportedFrom: v2.4.0

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed in updated commit

v2/azure-arm.yaml Outdated Show resolved Hide resolved
{
//KeyVaultSecretId: to.Ptr[string]("https://keyvaultname.vault.azure.net/secrets/secretname"),
Name: to.Ptr[string](subResname),
Data: to.Ptr[string](`MIIKEQIBAzCCCdcGCSqGSIb3DQEHAaCCCcgEggnEMIIJwDCCBHcGCSqGSIb3DQEH
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this is an embedded certificate, what's its expiry?

The test should either be self-contained (creating its own certificate, garanteeing that it's not stale), or at the very least there should be a comment here indicating when the certificate will expire so that a future dev knows what needs doing when the test fails.

@theunrepentantgeek theunrepentantgeek modified the milestones: v2.5.0, v2.4.0 Sep 7, 2023
Copy link
Member

@theunrepentantgeek theunrepentantgeek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We're keen to get this PR merged, it's looking very close to finished.

There are just two items outstanding:

  • The signature of getFrontendPortsARMID() needs to be modified to avoid the brittle nature of passing around arbitrary maps.
  • We can't commit secrets to the repo, so we need to tidy up the use of certificates.

I believe we have infrastructure available through the TestContext (tc) to create the required secrets on the fly, so that nothing needs to be hard coded. If you find the capability you need is missing, let us know and we'll fill in the gap for you.

return subRes, subResARMID
}

func getFrontendPortsARMID(tc *testcommon.KubePerTestContext, rg *resources.ResourceGroup, params map[string]string) (string, error) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As previously highlighted by @matthchr this method signature needs to be changed - passing around parameter in a map like this is brittle, creating a landmine for future maintainers where a simple change causes very non-obvious errors. We strongly prefer for problems to be identified by the compiler where possible.

There are two good alternatives.

Option 1: Replace the map with four parameters like this:

func getFrontendPortsARMID(
        tc *testcommon.KubePerTestContext, 
        rg *resources.ResourceGroup, 
        type1 string,
        value1 string,
        type2 string,
	value2 string,
) (string, error) {

calls would change to this form:

subResARMID, err := getFrontendPortsARMID(tc, rg, "applicationGateways", appGatewayName, "backendAddressPools", subResname)

Option 2: Replace the map with a varidic parameter:

func getFrontendPortsARMID(
        tc *testcommon.KubePerTestContext, 
        rg *resources.ResourceGroup, 
        params ...string,
) (string, error) {

This would allow any number of parameters, so you might want to include a check to panic if someone passes an odd number.

Calling would be the same:

subResARMID, err := getFrontendPortsARMID(tc, rg, "applicationGateways", appGatewayName, "backendAddressPools", subResname)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed with option 1. @theunrepentantgeek please review

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't want to have secrets committed to the repo, for all the usual policy reasons. I expect this would be promptly flagged as a security risk regardless of whether it's used elsewhere.

Remove this file.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove this file for the same reasons as appgwcert.pfx.

@matthchr
Copy link
Member

matthchr commented Oct 2, 2023

If you're busy @vimorra and don't have the time to finish updating based on our feedback, we can pick this up and get it over the line. No promises that it makes it into 2.4.0 but we'll try.

@vimorra
Copy link
Contributor Author

vimorra commented Oct 3, 2023

If you're busy @vimorra and don't have the time to finish updating based on our feedback, we can pick this up and get it over the line. No promises that it makes it into 2.4.0 but we'll try.

yes I will do my best, fixed the comment 1 about the signature of getFrontendPortsARMID. I will try to fix the certificate issue by adding the isSecret

@vimorra
Copy link
Contributor Author

vimorra commented Oct 3, 2023

We're keen to get this PR merged, it's looking very close to finished.

There are just two items outstanding:

  • The signature of getFrontendPortsARMID() needs to be modified to avoid the brittle nature of passing around arbitrary maps.
  • We can't commit secrets to the repo, so we need to tidy up the use of certificates.

I believe we have infrastructure available through the TestContext (tc) to create the required secrets on the fly, so that nothing needs to be hard coded. If you find the capability you need is missing, let us know and we'll fill in the gap for you.

not clear which option you are suggesting if create the certificate in an automated way or mark the attribute as "isSecret" ? in any case con you provide an example @theunrepentantgeek

@theunrepentantgeek
Copy link
Member

I went back and had another look, and it's actually both of the issues you've identified.

The issue I was referring to above is about hard coded certificates:

  • the file appgwcert64.pfx
  • the file appgwcert.pfx
  • the sslCertificates.data block in the sample v1api20220701_applicationgateway.yaml

Checking certificates into repos is a security issue even if they only contain public keys. They also expire, which will result in the test failing in the future.

The second issue is the authenticationCertificates.Data property on ApplicationGateway.spec - this should be configured with $isSecret: true so that the value is pulled from the cluster. Apologies for missing this earlier.

This will have two benefits.

  • When the certificate is rotated, updating the secret will result in ASO updating the ApplicationGateway, much easier (and more automated) than having to redeploy everything from scratch. (Rotating the certificate directly in Azure isn't an option because ASO will proactively restore the configured certificate next time it reconciles the resource.)
  • The certificate won't be disclosed to someone looking at the YAML for the resource. If the cert contains only a public key, this wouldn't matter - but people do take shortcuts and make mistakes, and if they use a cert containing a private key disclosure is a security risk.

We believe there's infrastructure available on the TestContext used in your test that should allow you to create a certificate on the fly as a part of the test. If this is missing, or if you can't find it, ping us and we'll dig in further.

@vimorra
Copy link
Contributor Author

vimorra commented Oct 4, 2023

@matthchr, @super-harsh and @theunrepentantgeek I need your support to understand how to generate an on the fly ssl certificate.
Meanwhile I have fixed the:

  • $isSecret: true point on all the resources that point to secrets and certificates
  • fixed the signature of $isSecret: true

@theunrepentantgeek
Copy link
Member

@vimorra - I'm looking into generating the SSL certificate; hoping to put together a sample for ASO users that will be relevant to your needs too. I'll update back here as that progresses.

Use HTTP protocol for Application Gateway in controller test to avoid certs and fix sample
@vimorra
Copy link
Contributor Author

vimorra commented Oct 24, 2023

Hi @theunrepentantgeek and @matthchr with the support of @super-harsh the PR should be ready to be merged
, shall we look together at how to solve the conflicts or I can assume that the incoming version is the one to merge?

@super-harsh
Copy link
Collaborator

@vimorra An easy way to deal with these conflicts is to merge main into your branch and run task controller:generate-types task and commit the files.

@codecov-commenter
Copy link

Codecov Report

Merging #3176 (d1ebad0) into main (db857cf) will decrease coverage by 0.12%.
The diff coverage is 58.04%.

@@            Coverage Diff             @@
##             main    #3176      +/-   ##
==========================================
- Coverage   54.32%   54.21%   -0.12%     
==========================================
  Files        1566     1570       +4     
  Lines      655434   663722    +8288     
==========================================
+ Hits       356073   359844    +3771     
- Misses     241588   245516    +3928     
- Partials    57773    58362     +589     
Files Coverage Δ
...zations/application_gateway_extension_types_gen.go 100.00% <100.00%> (ø)
...ork/v1api20220701/application_gateway_types_gen.go 47.22% <ø> (ø)
...pi/network/v1api20220701/bastion_host_types_gen.go 54.08% <ø> (ø)
...rk/v1api20220701/nat_gateway_spec_arm_types_gen.go 33.33% <ø> (ø)
...api/network/v1api20220701/nat_gateway_types_gen.go 57.76% <ø> (+0.35%) ⬆️
...rk/v1api20220701/storage/bastion_host_types_gen.go 52.72% <ø> (ø)
...ork/v1api20220701/storage/nat_gateway_types_gen.go 52.72% <ø> (ø)
...20220701/application_gateway_spec_arm_types_gen.go 33.33% <33.33%> (ø)
...i20220701/storage/application_gateway_types_gen.go 52.72% <52.72%> (ø)
...2/internal/controllers/controller_resources_gen.go 83.60% <61.53%> (-0.72%) ⬇️

... and 35 files with indirect coverage changes

@theunrepentantgeek
Copy link
Member

/ok-to-test sha=d1ebad0

@theunrepentantgeek
Copy link
Member

/azp run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@theunrepentantgeek theunrepentantgeek added this pull request to the merge queue Oct 27, 2023
Merged via the queue into Azure:main with commit 6daa0d3 Oct 27, 2023
9 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Development

Successfully merging this pull request may close these issues.

Support for Application gateway
5 participants