how should I set up the lambda to have access to s...
# software-contributors
c
how should I set up the lambda to have access to secret values (SLACK_SIGNING_SECRET in this case)? Should I configure the cdk to forward it from the current environment when deploying, should I configure it to use aws secrets manager (like the app_home_page lambda)? If so, how do secrets get added to ASM? Is that part of the codebase or its done manually?
from looking at other code I assume I should be using AWS Secrets manager. Looks like we store one big json secret with many items using a key something like SlackApp-{environment}. I dont know how to create new secrets in AWSSM (or update the placeholders that seem to created by the cdk)
f
We already have a secret for slack signing secret
If you're using it it should probably be moved to stateful stack. You can search for it in the budget insights stack
c
I see that. But like baruch, I am testing in alpha. And with my own slack account, which has its own signing secret
it should probably be moved to stateful stack
whats "it" in this case? The lambda I am making?
f
Yeah but the secret exists no matter where you're testing @mysterious-tomato-10057 any secret changes for testing shouldn't be in the main region or the slack app in alpha would break
👍 1
So just update the secret value
c
So just update the secret value
Not sure what you mean by this? Meaning update the key from
SLACK_SIGNING_SECRET
to something else so it doesn't collide?
f
In secrets manager in aws console if you are using alpha I don't recall if it's in core or slack account I think maybe slack account But you can search it in cdk
c
well, currently I am in us-east-1 so I dont want to mess anything up.
f
@mysterious-tomato-10057 is he able to use a different region? Or just use localstack
c
yeah I will try localstack cause Im not sure I have access to secrets manager
f
We need to have a stable staging env especially now that we are starting to connect frontend
c
undesrstood. Localstack is working well in gitpod now?
f
you might need to install dockercompose (for debian based image) manually for now but yes
c
if I just run the deploy script in both repos will localstack automatically be configured properly with the two accounts?
f
yes and no but it will work rn they use the same account but if you want you can change the config to use different ones i.e. instead of 000000000 for both just change a digit to a 1
but it’s not fully supported
c
hmm how do I change the value? by editing stages.ts?
f
probably
in both repos
c
ok and can (should) I work on a pr that makes one of the repos always be 000000001
so that its recognized in the deploy scripts and everything
m
you can invoke a lambda with aws cli with custom overrides for env vars if you need to specify your own to test something.
c
no, I want to test when slack invokes it
m
but actually, in this case, you should create a new secret because anyway when you are done with this work it’ll be a new secret because this will be the admin app, not the app everyone else is using
so i think you can deploy to alpha with a new secret deployed alongside the SLACK_SIGNING_SECRET called ADMIN_SLACK_SIGNING_SECRET with our admin app secret
and you have the same permissions as zier in alpha, which should include secrets manager
c
ok. Now how does secrets manager work? Am I correct that the secret is a whole long json string?
f
@mysterious-tomato-10057 in the current pattern wouldn’t this be an additional aws account then?
though yeah if it’s a new secret name no harm I guess
m
@full-wall-37598 definitely! But I think we can migrate in the future when we have more team members to break it down. I think two accounts is complicated enough for a team that is mostly volunteer. I would definitely like to carve out the accounts more in the future.
✅ 1
for the time being, keep stacks separate is helpful to making that migration easier in the future
c
@mysterious-tomato-10057 If you wouldnt mind giving me the command I need to add my key as ADMIN_SLACK_SIGNING_SECRET id appreciate it. I can try to figure out myself but I dont want to mess up the environment.
m
its not a command, you create resources in the cdk code, you can find with the slack signing secret is created and then you'll see how to do it. once it is deployed and created, you will login to the console and replace the default value with the real secret. the only manual changes we make in the console is adding the secrets, since we don't want to put secrets in code.
c
oh oh its done in the console ok
m
you can see its created in the stateful stack.ts
c
yeah I see that
👍 1
does it get replaced on every deploy
m
no.
as long as the stack is not deleted, which we should never do for the stateful stack, which is why we put secrets in there.
👍 1
the stateful stack is meant to be the one stack that we can’t simply delete and recreate, anything that we can delete and recreate easily, shouldn’t be in there
c
amazing thanks
💪 1
can you guide me where to go?
m
retrieve secret value
c
image.png
it looks like a permissions thing
m
kk, dm me your secret i’ll do it, sorry
c
no problem