Open JiayangZhou opened 1 year ago
This would also helpful in the cases where we want to create a kubernetes secret to sync with AWS secrets manager for tools which doesn't support CSI secret driver like Flux
Thank you for the report - we will look into this.
As described in the Usage section in this repo, we need to create an AWS IAM role with proper access to the secret manager or parameter store and have that IAM role attached to a SA, used by a pod. Then ASCP would come to retrieve the pod identity and exchange it for the IAM role. ASCP assumes the IAM role of the pod.
Could we have a feature to attach the IAM role to the SA of ASCP so that ASCP could assume the IAM role of its own SA and have enough access to a secret manager? This does not really sound secure enough, as its SA will have to contain all IAM permission required to access different sercert managers for a cluster. but it would help eliminate the redundant SA creation for each pod,
nginx-deployment-sa
in this exampleMore onto it, as
SecretProviderClass
is per namespace object, could we specify a name of SA, in SecretProviderClass's yaml file for instance. ASCP could be smarter enough to assume IAM role from that SA instead. The SA is attached to an IAM role with all necessary permission required for one namespace to access its secret managers. It goes somewhat against the less privileged principle but it would help tremendously for the use case, such as: we have manyDeployment
in a namespace but only need to access one secret manager. We already use SA inDeployment
, repetitive modification in each SA feels really unnecessary. Plus, that seems to be how Azure is implementing their CSI.