feat: option to assume role to get credentials #6

elventear · 2025-04-14T23:12:26Z

When fetching credentials after obtaining the boto3 session, we check if the configuration has an optional assume_role field, which indicates that role needs to be assumed to obtain the credentials.

If found, the role is assumed and used to obtain the credentails. If not the original boto3 session is used to obtain the credentials.

When fetching credentials after obtaining the boto3 session, we check if the configuration has an optional `assume_role` field, which indicates that role needs to be assumed to obtain the credentials. If found, the role is assumed and used to obtain the credentails. If not the original boto3 session is used to obtain the credentials.

jmkeyes · 2025-04-17T17:57:01Z

Thanks for making this contribution! I agree that having the option to assume a role would be a good addition to the accepted configuration keys: using temporary credentials is a much better option than static access/secret keys.

jmkeyes

/lgtm

The whitespace changes in the diff of the test code made things a bit harder to read, but I can run black later if needed.

keyrings/codeartifact.py

tests/test_backend.py

jmkeyes · 2025-04-17T19:05:18Z

Not strictly relevant to the PR, but the AWS SDK can also assume a role if configured to do so.

While it is nice to explicitly configure it ourselves here, it begs the question of how much responsibility this library should take in replicating that logic.

This also ties into #8: where do we draw the line between the behaviour of this library (via configuration) and the implicit behaviour of the boto3 library and the AWS SDK?

* Run black. * Make role assumption logic more explicit. * Make role session name optional.

elventear · 2025-04-17T20:50:58Z

Not strictly relevant to the PR, but the AWS SDK can also assume a role if configured to do so.

While it is nice to explicitly configure it ourselves here, it begs the question of how much responsibility this library should take in replicating that logic.

This also ties into #8: where do we draw the line between the behaviour of this library (via configuration) and the implicit behaviour of the boto3 library and the AWS SDK?

We have a considerable number of profiles and AWS child accounts that require cross-account authentication. Tightly coupling IAM configuration between identity roles and resource access can become difficult (one reason being IAM policy size limits) and keeping our identity roles loosely coupled from some resource access roles makes maintenance easier.

We could have additional configuration settings for the AWS SDK to assume the roles, but all the combinations we have would create an explosion of configuration entries. Being able to have loose coupling between the identity roles we use and resource roles in the configuration for this library makes management of all these things much simpler for our users.

jmkeyes · 2025-04-17T23:50:14Z

Not strictly relevant to the PR, but the AWS SDK can also assume a role if configured to do so.

While it is nice to explicitly configure it ourselves here, it begs the question of how much responsibility this library should take in replicating that logic.

This also ties into #8: where do we draw the line between the behaviour of this library (via configuration) and the implicit behaviour of the boto3 library and the AWS SDK?

We have a considerable number of profiles and AWS child accounts that require cross-account authentication. Tightly coupling IAM configuration between identity roles and resource access can become difficult (one reason being IAM policy size limits) and keeping our identity roles loosely coupled from some resource access roles makes maintenance easier.

We could have additional configuration settings for the AWS SDK to assume the roles, but all the combinations we have would create an explosion of configuration entries. Being able to have loose coupling between the identity roles we use and resource roles in the configuration for this library makes management of all these things much simpler for our users.

I agree.

The first use case for this keyring backend had very little need for configuration at all.

While it is convenient to define access/secret keys in the keyringrc.cfg for a trivial use case doing so is still a bad practice: this library isn't responsible for managing the credentials to access AWS but it should use the existing ones.

For version 3.x of this backend, I'm tempted to drop support for specifying access/secret keys in configuration and explicitly require users to migrate them to ~/.aws/credentials.

This would substantially limit the configuration options that this library needs to be aware of.

elventear · 2025-04-18T22:19:34Z

@jmkeyes does this look good to merge?

elventear · 2025-04-22T21:50:25Z

keyrings/codeartifact.py

+            assumed_role = session.client("sts").assume_role(
+                RoleArn=config["assume_role"],
+                RoleSessionName=config.get(
+                    "assume_role_session_name", "KeyRingsCodeArtifact"


So the AWS SDK will not pick a RoleSessionName for you; you can see the docs that they say they are required. So I have include an explicit default as a fallback instead.

As mentioned in a comment, I'd like this fallback to be a dynamic value usable for auditing in CloudTrail, but that's not required for this PR.

jmkeyes · 2025-05-21T21:37:19Z

@jmkeyes does this look good to merge?

Almost! Here are some thoughts:

I'd like to rename the assume_role configuration option to assume_role_arn to be explicit about the content of the string.
I've finally had some time to rework the unit tests to use botocore.stub.Stubber to stub out the AWS interactions so I can avoid the drawbacks of monkey-patching boto3 internals. As of 537fe6f, CodeArtifactBackend has a session keyword argument that defaults to boto3.session.Session() if not provided. There's a StubbingSession in the tests directory that allows for injecting expected responses from AWS API calls.
Finally -- while not required in this PR -- since the role session name is mandatory for the AssumeRole call, I'd prefer to make the default something usable for auditing in CloudTrail rather than a just fixed string. I want to include information about the identity of the user invoking AssumeRole at minimum. (I can add this in a followup commit.)

Let me know what you think!

jmkeyes · 2025-05-21T21:45:16Z

keyrings/codeartifact.py

-            aws_access_key_id=config.get("aws_access_key_id"),
-            aws_secret_access_key=config.get("aws_secret_access_key"),
-        )
+        session = self.get_boto_session(region=region, config=config)


As part of 537fe6f, I've created a _get_codeartifact_client instance method that returns an initialized CodeArtifact service client with specific options.

jmkeyes · 2025-05-21T21:47:23Z

keyrings/codeartifact.py

+            assumed_role = session.client("sts").assume_role(
+                RoleArn=config["assume_role"],
+                RoleSessionName=config.get(
+                    "assume_role_session_name", "KeyRingsCodeArtifact"


As mentioned in a comment, I'd like this fallback to be a dynamic value usable for auditing in CloudTrail, but that's not required for this PR.

jmkeyes · 2025-05-21T21:47:57Z

requirements-test.txt

@@ -1,2 +1,3 @@
 pytest >= 6
 pytest-cov
+pytest-mock


This shouldn't be necessary with the recent unit test modifications.

jmkeyes · 2025-05-21T21:48:47Z

tests/test_backend.py

The recent changes to the unit tests in 537fe6f may help clean up these tests.

jmkeyes · 2025-05-21T21:54:54Z

README.md

  - `token_duration`: Validity period (in seconds) for retieved authorization tokens.
  - `aws_access_key_id`: Use a specific AWS access key to authenticate with AWS.
  - `aws_secret_access_key`: Use a specific AWS secret access key to authenticate with AWS.
+  - `assume_role`: Role ARN to assume with the current profile name to get the CodeArtifact credentials.


I'd like to rename this to assume_role_arn to be more explicit about the content it contains.

jmkeyes mentioned this pull request Apr 17, 2025

Backend Ignores boto3 Default Credential Lookup Mechanism #8

Open

jmkeyes reviewed Apr 17, 2025

View reviewed changes

keyrings/codeartifact.py Outdated Show resolved Hide resolved

keyrings/codeartifact.py Outdated Show resolved Hide resolved

tests/test_backend.py Outdated Show resolved Hide resolved

tests/test_backend.py Outdated Show resolved Hide resolved

elventear added 2 commits April 17, 2025 14:48

Address comments:

bed7137

* Run black. * Make role assumption logic more explicit. * Make role session name optional.

Parametrize credential for supported host

22b1a17

elventear requested a review from jmkeyes April 17, 2025 22:03

elventear added 2 commits April 22, 2025 16:45

fix: settings role session name

89310a9

provide default role assume session name

abfbd23

elventear commented Apr 22, 2025

View reviewed changes

jmkeyes reviewed May 21, 2025

View reviewed changes

nicholsn mentioned this pull request Jul 15, 2025

Authenticate using codeartifact token via environment variable #19

Open

feat: option to assume role to get credentials #6

Are you sure you want to change the base?

feat: option to assume role to get credentials #6

Uh oh!

Conversation

elventear commented Apr 14, 2025

Uh oh!

jmkeyes commented Apr 17, 2025

Uh oh!

jmkeyes left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

jmkeyes commented Apr 17, 2025

Uh oh!

elventear commented Apr 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jmkeyes commented Apr 17, 2025

Uh oh!

elventear commented Apr 18, 2025

Uh oh!

elventear Apr 22, 2025

Choose a reason for hiding this comment

Uh oh!

jmkeyes May 21, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jmkeyes commented May 21, 2025

Uh oh!

jmkeyes May 21, 2025

Choose a reason for hiding this comment

Uh oh!

jmkeyes May 21, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jmkeyes May 21, 2025

Choose a reason for hiding this comment

Uh oh!

jmkeyes May 21, 2025

Choose a reason for hiding this comment

Uh oh!

jmkeyes May 21, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

elventear commented Apr 17, 2025 •

edited

Loading

jmkeyes May 21, 2025 •

edited

Loading

jmkeyes May 21, 2025 •

edited

Loading

jmkeyes May 21, 2025 •

edited

Loading