I am trying to retrieve API key from google secret manager using a service callout, I took this example as a reference
https://www.googlecloudcommunity.com/gc/Apigee/Access-GCP-Secret-Manager-from-Apigee/m-p/482208
when I try to deploy the proxy I receive this error
<Authentication> <GoogleAccessToken> <Scopes> <Scope>https://www.googleapis.com/auth/cloud-platform</Scope> </Scopes> </GoogleAccessToken> </Authentication>
I didnot get this following part "Because this ServiceCallout is using the Authentication/GoogleAccessToken configuration, to get this to work, you will need to deploy the API proxy with a service account, that has "Secret Manager Secret Accessor" role in the project in which the secret is stored.
And then what you receive in the secretResponse content is a JSON payload, which is of this form: "
what are the steps to do this ?? will the proxy even deploy once we do this change, because I tried and the deployment failed
Solved! Go to Solution.
I replied on the other thread where you asked this question.
How are you deploying? If using the UI, then you need to specify the service account in the UI, at the time you request the deployment. If you are doing it from the command line (Eg with apigeecli) then you need to specify the service account on the command line. The documentation is here: https://cloud.google.com/apigee/docs/api-platform/security/google-auth/overview
The specific steps for getting set up:
To set the role on the service account to allow it to access a specific secret:
gcloud secrets add-iam-policy-binding "projects/myproject/secrets/mysecret" \
--member="serviceAccount:${FULL_SA_EMAIL}" \
--role="roles/secretmanager.secretAccessor"
the principal (user or service account) that deploys the proxy (either via UI or command line) must have the iam.serviceAccounts.actAs
permission on the service account. This can be done this way :
gcloud iam service-accounts add-iam-policy-binding "${FULL_SA_EMAIL}" \
--member="MEMBER" \
--role="roles/iam.serviceAccountUser"
...where MEMBER
is replaced by user:myemail@mydomain.com
or serviceAccount:FULL_EMAIL_OF_DEPLOYER_SA
.
With this command, you are granting one principal (MEMBER) some permissions on another principal (the service account that the proxy should run as).
You would use a user email for MEMBER, if you expect to deploy interactively, using your own identity, either via the UI or the command line. So that command would grant YOU the rights to act as the service account that the proxy should run as.
You would use a service account in the MEMBER placeholder, if the deployment is being initiated from a CI/CD flow or some automated pipeline that uses that service account as its identity. In this latter case, there will be two service accounts. 1st: the SA that the proxy runs as. 2nd: the SA that deploys the proxy. The 2nd SA must have actAs permission (available with serviceAccountUser role) on the 1st SA. I hope this is clear.
apigeecli apiproxy deploy --name "$proxy_name" --rev "$REVISION" \
--org "$PROJECT" --env "$APIGEE_ENV" \
--sa "${FULL_SA_EMAIL}" \
--ovr --wait \
--token "$TOKEN"
If you will deploy interactively, then just use the UI, it will ask what service account you'd like to use. This is described in the documentation I linked above.
There is a sample that does all this stuff using command-line tools, here.
I replied on the other thread where you asked this question.
How are you deploying? If using the UI, then you need to specify the service account in the UI, at the time you request the deployment. If you are doing it from the command line (Eg with apigeecli) then you need to specify the service account on the command line. The documentation is here: https://cloud.google.com/apigee/docs/api-platform/security/google-auth/overview
The specific steps for getting set up:
To set the role on the service account to allow it to access a specific secret:
gcloud secrets add-iam-policy-binding "projects/myproject/secrets/mysecret" \
--member="serviceAccount:${FULL_SA_EMAIL}" \
--role="roles/secretmanager.secretAccessor"
the principal (user or service account) that deploys the proxy (either via UI or command line) must have the iam.serviceAccounts.actAs
permission on the service account. This can be done this way :
gcloud iam service-accounts add-iam-policy-binding "${FULL_SA_EMAIL}" \
--member="MEMBER" \
--role="roles/iam.serviceAccountUser"
...where MEMBER
is replaced by user:myemail@mydomain.com
or serviceAccount:FULL_EMAIL_OF_DEPLOYER_SA
.
With this command, you are granting one principal (MEMBER) some permissions on another principal (the service account that the proxy should run as).
You would use a user email for MEMBER, if you expect to deploy interactively, using your own identity, either via the UI or the command line. So that command would grant YOU the rights to act as the service account that the proxy should run as.
You would use a service account in the MEMBER placeholder, if the deployment is being initiated from a CI/CD flow or some automated pipeline that uses that service account as its identity. In this latter case, there will be two service accounts. 1st: the SA that the proxy runs as. 2nd: the SA that deploys the proxy. The 2nd SA must have actAs permission (available with serviceAccountUser role) on the 1st SA. I hope this is clear.
apigeecli apiproxy deploy --name "$proxy_name" --rev "$REVISION" \
--org "$PROJECT" --env "$APIGEE_ENV" \
--sa "${FULL_SA_EMAIL}" \
--ovr --wait \
--token "$TOKEN"
If you will deploy interactively, then just use the UI, it will ask what service account you'd like to use. This is described in the documentation I linked above.
There is a sample that does all this stuff using command-line tools, here.
Thank you so much that is very detailed and informative !
User | Count |
---|---|
1 | |
1 | |
1 | |
1 | |
1 |