Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Add support for AWS Secrets Manager #151
feat: Add support for AWS Secrets Manager #151
Changes from all commits
d171240
37a2583
86fda1d
f7c0c1f
6969af4
a7ecae1
ea2fadf
72cb216
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm is there a better default here than allowing access to all secret managers? It looks like the default we are setting for the other policies is
["arn:aws:iam::${data.aws_caller_identity.current.account_id}:role/${aws_iam_role.node.name}"]
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think limitations are based on the secret, not the secret manager (you can think of the secret manager as some service you can't control)
Our secrets are prefixed, so maybe we can change to:
from:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Got it. Yeah we need some way to make this a no-op so that we don't give installs access to all secrets. Maybe just put in some junk for the prefix? cc: @gls4 if you have any better ideas here. It be nice to refactor this at some point to not provision the policy at all in the case that no secret manager arn is present.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For simplicity, maybe we can just enforce that the prefix is non-null (or hardcode it as
wandb-secret
)I don't think we use the Secret Manager for anything else atm, but maybe in future?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not correct. Please see https://docs.aws.amazon.com/secretsmanager/latest/userguide/reference_iam-permissions.html.
Access to SECRETS needs to be scoped to the cluster, and only for PUT, GET, UPDATE, DELETE operations. There is no need to provide the additional permissions. Moreover, we cannot allow one customer's cluster to read the secrets from another customer, so permissions have got to be scoped correctly from the start.
As for not provisioning the policy in the absence of the arn -- we need to do that now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
modified permission to be more tightly scoped