Hi all, I’m wondering about a best practice for ma...
# sst
d
Hi all, I’m wondering about a best practice for managing keys and IDs generated by AWS and used in my mobile app, and how the app can use these values. Here’s the scenario: my mobile app uses Cognito for authentication to AppSync. It needs the user pool ID, a client ID, and an Identity pool ID. For unauthenticated requests to AppSync, I use an API key. However, if I ever have to regenerate my production stacks, all of those keys will change and the mobile app will break because they are currently stored in a file in the mobile app. How can I prevent this brittleness? I think it’d be nice to have an API endpoint that the client app calls upon opening to download those values. Should those values be stored in a Secrets Manager, read by a lambda, and sent to the client? If you’ve got any ideas, I’d really appreciate it! Thanks!
a
If you are serving them up with an unauthenticated endpoint, then there's no need to keep them secret on the cloud side. You can pass them into a Lambda that provides them as environment variables. CDK can get them from your Cognito stack as input to your API stack.
This doesn't seem like a very real scenario though - at least for production. If you rebuild the cloud to the point of having new Cognito IDs, then you just lost all your customer's accounts too(?).
d
Very true. I would have lost those accounts.
Back to AppSync. I was reading this article (https://tsh.io/blog/aws-appsync/) on AppSync and there’s a section called “Unstable API keys”. Here’s the text: You can only generate AppSync’s API key and update its validity date. You can’t set it to a given value as with API Gateway. This may not sound like an obstacle, but remember that if you recreate your AWS application, the API key will be different. That might happen after an issue with your Infrastructure-as-a Code. Take my word for it. Those who manage client applications connected to your API won’t be too happy. You can deal with this by employing a common solution for the API and the client applications that use the API key as one source. AWS Parameter Store or the Secret Manager can do that.
I suppose AppSync would then be the only key I’d be concerned about if I had some problem with the infrastructure as code. So then one more question - is it best practice to have the persistent stacks decoupled from other stacks like the API, AppSync, etc? Right now I have all of these living in a single SST project. Should I split dynamo & cognito into a different project to prevent the scenario where rebuilding the stack loses customer data?
f
@David Martin You can remove individual stacks ie.
sst remove api-stack
I’d say having all stacks in the same app.