cluster-api-provider-azure

cluster-api-provider-azure copied to clipboard

/kind feature

As part of the subnet creation inside of a CAPZ managed VNET it would be beneficial to users to be able to create Service Endpoints. Service Endpoints allow private connections to Azure services such as CosmosDB, ContainerRegistry, KeyVault and several others services.

We propose that as part of an AzureCluster.networkSpec.subnets[] a new optional field would be added called serviceEndpoints. This would be a list of endpoint names that would be validated against a valid list of endpoints. Based on the list in the new field, when a subnet is created, each Service Endpoint would be added to the subnet.

As part of an AzureManagedControlPlane.virtualNetwork.subnet the same new optional field called serviceEndpoints would also be added. This would follow the same validation process as with AzureCluster.networkSpec.subnets[].serviceEndpoints. Each Service Endpoint defined would be added to the subnet created as part of the VNET created for AKS.

This feature would only apply when the VNET is managed by CAPZ. BYO VNET would not manage Service Endpoints.

Outstanding questions:

• Would this require a new apiVersion even though it would be an optional field?
• Can the list of Service Endpoints be programmatically found via an API call and pre-validated or does the list need to be hardcoded? Or do we rely on the API call to return success/failure for the validation?

/assign @mtougeron @jantzenallphin

@mtougeron: GitHub didn't allow me to assign the following users: jantzenallphin.

Note that only kubernetes-sigs members, repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see the contributor guide

In response to this:

/kind feature

As part of the subnet creation inside of a CAPZ managed VNET it would be beneficial to users to be able to create Service Endpoints. Service Endpoints allow private connections to Azure services such as CosmosDB, ContainerRegistry, KeyVault and several others services.

We propose that as part of an AzureCluster.networkSpec a new optional field would be added called serviceEndpoints. This would be a list of endpoint names that would be validated against a valid list of endpoints. Based on the list in the new field, when a subnet is created, each Service Endpoint would be added to the subnet.

As part of an AzureManagedControlPlane.virtualNetwork the same new optional field called serviceEndpoints would also be added. This would follow the same validation process as with AzureCluster.networkSpec.serviceEndpoints. Each Service Endpoint defined would be added to the subnet created as part of the VNET created for AKS.

This feature would only apply when the VNET is managed by CAPZ. BYO VNET would not manage Service Endpoints.

Outstanding questions:

• Would this require a new apiVersion even though it would be an optional field?
• Can the list of Service Endpoints be programmatically found via an API call and pre-validated or does the list need to be hardcoded? Or do we rely on the API call to return success/failure for the validation?

/assign @mtougeron @jantzenallphin

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

Thanks @mtougeron for creating this feature request.

/assign @jantzenallphin

/milestone v1.6

@mtougeron quick question about the stated scope in the issue description:

Is the reason why this is not appropriate for BYO VNET because in those scenarios the various service endpoint configurations will have already have been defined? And maintaining those over time within the non-capz-managed VNET is something the user will continue to be able to do independently?

@mtougeron quick question about the stated scope in the issue description:

Is the reason why this is not appropriate for BYO VNET because in those scenarios the various service endpoint configurations will have already have been defined? And maintaining those over time within the non-capz-managed VNET is something the user will continue to be able to do independently?

Correct. IMO if the user is already maintaining the Vnet/Subnet outside of CAPZ, they should maintain all aspects of the Vnet/Subnet outside of CAPZ. Otherwise we could end up in a situation where CAPZ and tool "z" both end up trying to reconcile the state based on different definitions.