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
DRIVERS-1746 Add native support for AWS IAM Roles for service accounts, EKS in particular #9
Conversation
Thanks for working on this @basilnsage! We were actually just about to pick up this work as part of https://jira.mongodb.org/browse/DRIVERS-1746. I'm traveling today, but will take a closer look next week. |
That's convenient, thanks for pointing that out. Hopefully this PR helps satisfy the ticket's requirements. When you have a chance, please have a look and let me know if there's anything you'd like changed! |
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.
Great, thank you! As a note, we're planning to set up a test suite using botocore.stubber
, but since that suite doesn't exist we don't expect you to add a test. 😄
Thanks for the review y'all. I'm signing out for today but will address tomorrow. |
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.
LGTM, thank you!
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.
Code LGTM, just one question
pymongo_auth_aws/auth.py
Outdated
try: | ||
with open(irsa_web_id_file) as f: | ||
irsa_web_id_token = f.read() | ||
return _irsa_assume_role(irsa_role_arn, irsa_web_id_token, 'pymongo-auth-aws') |
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.
Is RoleSessionName=pymongo-auth-aws
important for your use case? Are we free to change this string in a future release without warning?
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.
Specifically, I'm wondering if we're going to need to standardize this name across all language apis for MongoDB. Perhaps "mongodb-aws" or "MONGODB-AWS" may be a better 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.
According to https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-envvars.html I believe this should be os.getenv('AWS_ROLE_SESSION_NAME')
:
AWS_ROLE_SESSION_NAME
Specifies the name to attach to the role session. This value is provided to the RoleSessionName parameter when the AWS CLI calls the AssumeRole operation, and becomes part of the assumed role user ARN: arn:aws:sts::123456789012:assumed-role/role_name/role_session_name. This is an optional parameter. If you do not provide this value, a session name is generated automatically. This name appears in AWS CloudTrail logs for entries associated with this session.If defined, this environment variable overrides the value for the profile setting role_session_name.
Used with the AWS_ROLE_ARN and AWS_WEB_IDENTITY_TOKEN_FILE environment variables.
For more information on using web identities, see Assume role with web identity.
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'm not wedded to the name, but I wouldn't count on that environment variable being present in all deployments. At present, AWS_ROLE_SESSION_NAME
isn't provided by a default IRSA deployment; from https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts-technical-overview.html:
The Amazon EKS Pod Identity Webhook on the cluster watches for pods that are associated with service accounts with this annotation and applies the following environment variables to them.
AWS_ROLE_ARN=arn:aws:iam::111122223333:role/iam-role-name AWS_WEB_IDENTITY_TOKEN_FILE=/var/run/secrets/eks.amazonaws.com/serviceaccount/token
So, would it make sense to check for this env var and default to pymongo-auth-aws
if not set?
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.
Pushed a commit to handle this. If the user cares enough, they can specify the env var to suit their own bookkeeping purposes this way.
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 believe we need to use the AWS_ROLE_SESSION_NAME environment variable instead of hard coding the RollSessionName. @blink1073 does that sound right?
I think we should use it, and fall back to |
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.
LGTM!
I also found these docs which mention explicitly that role session name is optional:
https://github.com/boto/boto3/blob/85b975af30c408f93b654a21930218edd58336ad/docs/source/guide/credentials.rst#assume-role-with-web-identity-provider
role_session_name - The name applied to this assume-role session. This value affects the assumed role user ARN (such as arn:aws:sts::123456789012:assumed-role/role_name/role_session_name). This maps to the RoleSessionName parameter in the AssumeRoleWithWebIdentity operation. This is an optional parameter. If you do not provide this value, a session name will be automatically generated.
So we could also choose to omit it when not defined but a fallback to "pymongo-auth-aws" sounds good to me. Thanks @basilnsage!
This PR adds support for Kubernetes environments using IAM Roles for Service Accounts (IRSA) to authenticate Pods. It looks for environment variables that are part of a standard IRSA configuration to fetch temporary credentials.
Resolves #8