https://serverless-stack.com/ logo
Join Slack
Powered by
We have an SSM parameter that is called at build. ...
# help
r
We have an SSM parameter that is called at build. We've updated it. It's changed - really. It is. Yet, every time we attempt a deploy or build the old SSM parameter is used. We can't figure out where it's coming from. Has anyone else had this issue? Does SST cache SSM parameters?
r
Are you using a specific version of the parameter?
t
And how are you referencing the ssm parameter
r
Copy code
import { StringParameter } from "@aws-cdk/aws-ssm";

const api = StringParameter.valueFromLookup(
      this,
      "/thingy/api/url"
    );
In a 
sst.Stack
class constructor
Are you using a specific version of the parameter?
No. But, we have removed it and added again to ensure there is no history. Good thought.
t
So I believe valueFromLookup writes it to your cdk.context.json file - can you check if it's there?
You normally want to use 
StringParameter.fromStringParameterName
which will pass in a token which gets resolved during the cfn deploy
r
Oh! That's helpful! Thanks. I'm looking for the 
cdk.context.json
is that in he 
.build
directory?
t
it should be next to your sst.json
One of my earliest posts in here 😄
r
@thdxr curious how you are handling non string secrets with this. I would like to use a simpler solution like you all have mentioned, 
fromStringParameterName
as it seems to not require the full secret ID. For now I've been using this little helper utility, but maybe there is a better way?
Copy code
getRef(secretName: string, field?: string) {
      const SecretId = `arn:aws:secretsmanager:${region}:${account}:secret:${secretName}`
      return SecretValue.secretsManager(SecretId, {
        jsonField: field,
      }).toString()
    },
t
I don't use secrets I only use SSM
I think what you have there is what I'm aware of
r
Wow 🤦‍♂️ all this time I thought SSM was secrets manager. There is a whole separate thing haha
t
Yeah it's confusing lol - SSM is way easier
r
Well what the heck haha ok but it does look like SSM can only be a string, where a secret can be json and have fields. So is it best to just store one value per SSM param, or do folks parse strings into json? This is confusing. I guess maybe if you don't need secret rotation SSM is a better option. secrets have a monthly storage cost as well.
t
Yeah you do one value per SSM parameter. And if you prefix them like 
/app/stage/<KEY>
there's an API for pulling all of them by prefix
there's an api for multi-get as well
We're gonna bake all this into SST (been saying that forever lol) so that you can set hand managed secrets in the console scoped to your app+stage
r
ah i gotcha, so you fake structure with string
Well, now i get to go swap secrets for SSM params haha. So how does versioning work here with SST. If you update the SSM param (i assume this means a new version exists now) will SST deploy pick it up or does something need to be done on the JS side. Like updating a version number for the param?
r
Until recently CDK forced you to specify a version of the parameter that you wanted to grant access to but now if no version is provided, the latest is assumed
and it’ll continue to pick up the latest as that parameter changes over time
r
@Ross Coundon (great name btw) 🙂, so if i login to AWS and change a SSM param, then do 
sst deploy
it will somehow get the latest param? Isn't the data in CF just a reference? Trying to make sure i understand what the "update a param and get it into production" workflow looks like, if you are using build time params and not runtime.
r
Likewise 😉 I believe the function is being granted access to the latest alias for the parameter, therefore, as the latest alias points to different versions, the code still retains the right access privileges
r
hmm... it doesnt look like 
fromStringParameterName
is async though, I am guessing it doesnt actually call out to AWS to get latest info. I would think this is making a token for CF to pick up the latest on deploy... Guess i need to do some tests here, see if i have the same trouble here as i did with secrets where the secret updated but the SST deploy was unware so there was no delta and thus no updates.
r
What I'm describing is happening at runtime rather than deploy time. I've only granted privileges to a lambda based on a retrieved parameter in the stack, rather than retrieving the value of that parameter
6 Views
Open in Slack
PreviousNext
Powered by