-
Notifications
You must be signed in to change notification settings - Fork 97
Description
Describe why this change is needed
In order to manage this plugin across many different workloads requires a lot of boilerplate. If a workload has an annotation or label signifying that AWS credentials for a specific role are needed, then the appropriate sidecars, envvars and volumes should be inserted.
Describe solutions and alternatives considered (optional)
A kubernetes MutatingWebhookConfiguration will check each Pod for a matching label key, e.g.aws.privateca.cert-manager.io/role-arn, and patch the resource before committing. There should be default values for trust-arn, profile-arn and trust-certificate that can be overridden by labels too.
Alternatives:
Something akin to the AWS IRSA mechanism that can sit on each node as a metadata service shim. I think there would be some issues regarding container access to the generated credentials though. A cluster-wide volume mount (ceph, beegfs, etc) could manage the credentials as a volume mount much like the serviceAccountToken, maybe.
Is there anything else you would like to add?
No response