You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 example
More 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 many Deployment in a namespace but only need to access one secret manager. We already use SA in Deployment, repetitive modification in each SA feels really unnecessary. Plus, that seems to be how Azure is implementing their CSI.
The text was updated successfully, but these errors were encountered:
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
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.The text was updated successfully, but these errors were encountered: