Implement a default centrally managed Azure secret as an option for authentication to the Azure subscriptions

[Donka Dimitrova]

How to categorize this issue?

/area security
/kind enhancement
/priority 2
/platform azure

What would you like to be added:
Allow Gardener service providers to offer default Client ID & Client Secret for each supported Azure Active Directory.
Why is this needed:
When Gardener service consumers want to start using Gardener to manage shoot clusters on Azure, thay should provide as an "Azure secret" all details necessary for Gardener to target the proper Azure subscription(subscriptionID and tenantID) and to be able to authenticate (Client ID and the Client Secret of an SPN user that is granted access in that Azure subscription).

When Gardener is hosted for internal corporate purposes, the list with Azure Directories "in scope" is not so long and many of the "registered" (inside Gardener) Azure Client Secrets belong to SPN users from one and the same Azure Directory. In the same time all SPN owners are responsible to rotate regularly their SPN secrets because these secrets are static. Secret rotation when done manually could lead to some complications as described here: gardener/gardener#4630. When it is automated via the Gardener API, the automation is implemented separately by individual consumers because of the reconciliation dependencies.

Centrally managed (by the Gardener operations team) SPN users on each Azure Active Directory can replace the need to create and control many SPN users individually by each Gardener service consumer because if Gardener can take care for the SPN lifecycle management, the Gardener consumers can simply grant such central Gardener SPN user the proper permissions in their Azure subscriptions (just like they do this now for their own SPN users). The difference will be only in the ownership of the SPN secret that will be controlled by the central Gardener operations team.

In order to implement a feature, that will allow configuring a default central Azure Directory SPN (Client ID) for a Gardener service, Gardener project has to be extended to allow the option for consumers [1] to name in the "Azure secret" as a Client ID a centrally managed SPN name, [3] to omit the Client Secret and [3] to declare (in a special new "Azure secret" field) that they want Gardener to use the mentioned in the Client ID SPN when authenticating to their Azure subaccount for manage Azure resources. The field "for the declaration" is required (I think) because Gardener has to be able to differentiate between an Azure secret registration with an own SPN and a secret with a centrally managed SPN.

This solution could resolve the issue 4630 for Azure clusters because I expect that the Client Secret sync with the Seeds (after Client Secret rotation) could be organized without the involvement of the consumer shoot clusters reconciliation.

[Dominic Kistner]

Tasks related to provider-azure:

• The provider-azure need an option to inject a list of global service principal (spn) secrets (with keys tenant_id, client_id and client_secret).
  • Those global spn secrets should be deployed also via the ControllerDeployment
  • The extension should fail on startup if multiple global spn secrets are maintained with the same tenant_id value field
• Add a seed admission controller to the provider-azure which mutates the cloudprovider secret on creation/update in the Shoot namespaces
  • It should check if the cloudprovider secret in a Shoot namespace contain a client_id and a client_secret
  • If not it should add the client_id and the client_secret from the global spn secret of the extension whose tenant_id matches to the tenant_id in the cloudprovider secret
• The azure-admission-controller need to allow to create azure secrets client_id and client_secret within the garden cluster

/assign