Gardenlet to project a service account token into the Seed for IaaS authentication purposes
donistz opened this issue · comments
How to categorize this issue?
/area security
/kind enhancement
What would you like to be added:
Gardenlet to project a service account token or centrally managed SPN secret into the Seed for IaaS authentication purposes
Why is this needed:
In order Gardener to start supporting this scenario:
- Enable alternative authentication method for "Azure secret configuration" by using a default (centrally managed) SPN per Azure Directory (Tenant) ID for managing consumer IaaS resources as described in the issue #383
gardenlet has to be extended to support the following scenario:
gardenletto check for refreshed centrally managed Azure SPNs and to update it in the Seed cluster so that the Azure extension provider can find it and use it for authentication to the Azure APIs
@donistz We have moved all infrastructure (and other) functionality from Gardener in-tree to out-of-tree (extensibility). We won't go back and let the gardenlet know something about Azure (it has to remain infrastructure-agnostic). Also, @dkistner already described everything necessary for the Azure SPN solution, so let's drop it from here (conflicting).
Therefore, let's strike out the second aspect about the Azure SPN from this BLI and only keep the first aspect around how pods in the seed get to a garden cluster JWT. However, I believe we should clarify a few more questions, e.g. around audiences:
- Will we settle on one audience (large role with the superset of permissions needed for all components) or multiple separate audiences ("Principle of Least Privilege", custom-tailored to the different components such as Terraform, MCM, CCM, CSI Controller, etc.)
- Are we going to allow custom audiences (suffixes to whatever we decide above), so that stakeholders can associate different roles (segregating access) per cluster
Of course, with one SPN, that's no option / there is no equivalent solution in Azure, but for AWS and GCP we can offer that, if we want.
For security reasons, it is very important to make sure that the token audience can be uniquely defined on the Gardener side. This is why the best will be to consider as audience the combination between the name of the K8S namespace (of the project) and the name of the secret, for example <k8s_namespace_name>-<secret_name>.
This is because the names of the secrets are unique only in the context of a Gardener project (K8S namespace).
@donistz No, I don't understand that. If the end user gives us an audience, we can use it. Also, what secret? There is none necessary anymore.
Can we clarify this purpose of the ticket? Otherwise, I assume we have to close it.
@rfranzke I changed the issue, so that only the Azure SPN is concerned because after discussions we came to the conclusion that it is better for Gardener to integrate with an external OIDC Provider for OIDC based authentication to IaaS APIs instead to play the OIDC Provider role.
@dkistner Please, provide more details what improvements you think are necessary for the gardenlet in order to start supporting the concept for a central Azure SPN per Azure tenant ID. Thanks in advance!
OK, I will move this issue to the Azure extension repo since it is cloud provider specific - gardenlet/gardener itself is agnostic and will not implement such specifics.
@donistz See above, as written in the first comment, the gardenlet is provider-agnostic.
@donistz cc @rfranzke See above, as written in the first comment, why are we duplicating what @dkistner already described after our call in #383 (comment). What are the differences in the tickets? I am getting lost here. Even "more tickets" are not "more helpful".
@rfranzke Hi Rafael, I close the ticket because according to what is planned to be implemented with #383 (comment) as mentioned by Vedran, there will be no need to change the gardenlet logic. There is a change planned in the ControllerDeployment resource that will be detected and used by the gardenlet.