https://metaplay.io logo
AWS Secrets in Staging & Production
# questions-and-feedback
a
Hi! We have been using the pre-launch dev envs so far, but now switched to the production plan and got the proper staging & productions envs. I got to deploy to Staging OK, but I have trouble adding AWS secrets there. I didn't find from the docs how it is supposed to work, I don't remember from where we got the info for how it has been working for dev envs. Is it somehow different? I authenticated using metaplay-auth and it worked to deploy the docker image fine, but starting the server fails as secrets are missing. With the same auth I get this when trying to add secrets: > $ aws secretsmanager create-secret --region eu-west-1 --name metaplay/p1/deployments/imaginedesign-staging/test --secret-string test > > An error occurred (AccessDeniedException) when calling the CreateSecret operation: User: arn:aws:sts::252344532344:assumed-role/metaplay-p1-rare-rice-gameserver-admin/stackapi is not authorized to perform: secretsmanager:CreateSecret on resource: metaplay/p1/deployments/imaginedesign-staging/test because no identity-based policy allows the secretsmanager:CreateSecret action rare-rice is the name our staging env and i did the auth with the eval that works for deploying > $ eval $(npx @Metaplay Support/metaplay-auth get-aws-credentials -o beyondlabs -p imaginedesign -e staging -f env)
j
Hey, instead of
metaplay/p1/deployments/imaginedesign-staging/test
you probably want
metaplay/p1/deployments/race-rice/test
a
right, i think i tried that yesterday but maybe made a different mistake then
j
race-rice is the unique identifier that won't change even if the project name changes, so the infra stack is called that instead of imaginedesign-staging
a
yes that worked! thanks. indeed i did realize that maybe that's it but somehow failed yesterday anyway
j
Happens 😄
Our CLI tool knows how to translate
-o beyondlabs -p imaginedesign -e staging
to the permanent name but AWS's cli tool doesn't unfortunately
At some point, we'll add secret management to our CLI tool as well but we're not there yet 😄
a
that would be handy yes. the current way is not bad though
hm .. so where we get secrets in the code, i need to make a mapping from the env to the infra name? earlier we've used the string from GetEnvironmentInfo.GetEnvironmentFamily() directly in the path no prob to do the mapping ofc but i just wanted to check and i guess in the yaml files with the aws-sm:// refs it needs the infra name too
lol that GetEnvironmentFamily is our own method, i forgot 😄
j
Ah yeah, we generally set the secret per environment in the options (e.g. options.staging.yaml refers to race-rice)
a
yep i have that too but i also have code which gets secrets, and a util class for doing it easily i guess i could have put them to options too .. but it's actually less work to just have a single get call with the secret name and then the generic code constructs the path depending on the env