I'm currently using AWS Secrets Manager to manage my secrets, but I've hardcoded the secret names and ARNs for resources like Secrets Manager, IAM, and Lambdas directly in my GitHub repo. Is this a bad practice? What kinds of risks might I face if someone gets access to these secret names and ARNs?
5 Answers
It's generally alright, as ARNs aren't sensitive info. As long as your IAM configurations are tight, you should be okay. Just remember, if someone compromises your account or a user with access, that could lead to issues. Often, if a user has access to the secrets, they need permission to list them too, so exposing them isn't a huge concern as long as your overall security is strong.
I wouldn't recommend adding them to source control if you can avoid it. If someone intends to compromise you, having secret ARNs in source control is basically handing over information. Once you have an account number, it opens doors for testing misconfigured IAM roles, etc. We’ve migrated to using AWS SDK/Boto to fetch secrets based on tags instead of hardcoding anything. That's a safer approach!
It’s fine to have them hardcoded for convenience, but ideally, use argument passing instead to avoid hardcoding sensitive data.
While ARNs are not credentials, they do reveal a lot about your infrastructure, making it easier for someone to see how your app relies on various services. A best practice is to use environment variables. If you’re using Terraform, you can define the secrets and Lambda in the same stack and pass the secret's ARN to the Lambda's config as an environment variable.
ARNs by themselves aren't sensitive, they're just identifiers for resources. But exposing them isn’t ideal, even in a private repo. It would be smarter to store them in a configuration file rather than hardcoding them.
Exactly, and keeping things like that in environment variables can help maintain security and cleanliness in your code.