I want to grant a service account access to a secret in Google Secrets Manager.
I can access the secret like this:
gcloud beta secrets versions access 1 --secret="thesecret" --project="myproject"
But when my service account tries the same command, gcloud emits this error:
ERROR: (gcloud.beta.secrets.versions.access) PERMISSION_DENIED: Request had insufficient authentication scopes.
The main question is: What else do I need to do to ensure that the service account can access the secret?
I have granted that service account "roles/secretmanager.secretAccessor" in Terraform like this:
resource google_project_iam_binding the-binding {
project = myproject
role = "roles/secretmanager.secretAccessor"
members = [
"serviceAccount:[email protected]",
]
}
And I can verify that it has that role both in the gcp console and like this:
gcloud projects get-iam-policy myproject \
--flatten="bindings[].members" \
--format='table(bindings.role)' \
--filter="bindings.members:[email protected]"
ROLE
roles/secretmanager.secretAccessor
But there's this concept from the docs:
If a member only needs to access a single secret's value, don't grant that member the ability to access all secrets. For example, you can grant a service account the Secret Accessor role (roles/secretmanager.secretAccessor) on a single secret.
So it's like an iam-policy-binding can have an affinity to a particular secret, but I'm not sure which gcloud commands or terraform resources I can use to create such an affinity.
Service account permissions. Service accounts are both identities and resources. Because service accounts are identities, you can let a service account access resources in your project by granting it a role, just like you would for any other principal.
You can create a service account key using the console, the gcloud CLI, the serviceAccounts. keys. create() method, or one of the client libraries. A service account can have up to 10 keys.
To grant a user permissions to create a secret, we recommend you attach a permissions policy to an IAM group the user belongs to. See IAM user groups. The following policy grants permission to create secrets and view a list of secrets. To use this policy, see Attach a permissions policy to an identity.
The first problem is that I was mistaken about which service account my environment was configured to use. So I had granted access to the service account, but I wasn't using it after all (apparently they're initialized inconsistently in my case). I fixed that by running this command before trying to access the secret:
gcloud config set account [email protected]
Also, I didn't realize that there were more than one toplevel gcloud command that let you modify iam policy bindings. I had been exploring gcloud iam ...
when what I needed was:
gcloud beta secrets add-iam-policy-binding projects/myproject/secrets/mysecret --member serviceAccount:[email protected] --role roles/secretmanager.secretAccessor
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With