aws codecommit create-pull-request console user incorrect when using a profile with delegated role via sts

[randybasrs]

Describe the bug

The author of a PR appears incorrect when using the following command: aws codecommit create-pull-request --title $title --description $description --targets repositoryName=$repositoryName,sourceReference=$branchName --profile $profileName

In this case we're calling this from PowerShell. This command does submit a PR but when we look at the GUI for codecommit it shows botocore-session-1234567890 where 1234567890 is the botocore session ID I guess. This may be technically correct due to how the account switching is done in the code but does not provide information in the AWS GUI as to who actually created the PR and will not allow us to use this method as part of our PR process. Being able to see that from the AWS gui is a requirement of our infosec team and since the GUI properly displays this information when submitting a PR it seems like perhaps a change that can be made in the CLI

Expected Behavior

When the same action is performed through the AWS console with the same user role the author shows properly as the username who submitted the PR. This is what I would expect from the CLI as well.

Current Behavior

There are no errors in the process, it works great and creates the PR but just does not have the proper authorship information to allow us to review it and use it in our process.

We use a home account to log users in and then switch role to a role with permissions to CodeCommit in a separate account so when running the command we use the --profile flag to provide the profile. The base user has MFA and so MFA is required but that part of the process also functions properly.

Reproduction Steps

Setup:
Create/use 2 accounts with a user in account A with a role in Account B with codecommit access to a repo you create
Create a repository in account B with data in the main branch.
Create 2 branches in that repository with a change for the 2 scenarios below:

GUI:
Log user into account A
Switch role to account B to a role with permissions to create a PR on the target repo from a branch to main. (Targets are irrelevant but this is how we are using it)
Navigate to the branch in code commit and create the PR filling out the title and the description with references to this being the GUI test for the PR process.
Look at the PR list after it has been submitted and you will see the proper username in the user column.

CLI:
Create a proper aws cli credentials file with 2 entries:
The base entry for the user with the MFA device in Account A
the second profile for Account B using the delegated role:
Ex:
[AccountA]
region = us-west-2
aws_access_key_id = accesskeyid
aws_secret_access_key = secretaccesskey
mfa_serial = arn:aws:iam::accountAID:mfa/username

[AccountB]
region = us-west-2
role_arn = arn:aws:iam::accountBID:role/CodeCommitRoleName
source_profile = AccountA
mfa_serial = arn:aws:iam::accountAID:mfa/username

Run the command in the description above to submit a PR using AccountB profile
Check the PR interface in the AWS console. You will see the username for this PR is botosession

Possible Solution

Handle role switching better to do the submission in the same way that the AWS console does

Additional Information/Context

We do not have access to AWS organizations in our environment. This should not be relevant but in this case the accounts are not part of an organization.

CLI version used

aws-cli/2.10.3 Python/3.9.11 Windows/10 exe/AMD64

Environment details (OS name and version, etc.)

Microsoft Windows 10 Enterprise: 10.0.19045 N/A Build 19045

[aBurmeseDev]

Hello @randybasrs - thank you for reaching out with very detailed submission.

If I understand correctly, you're creating pull-requests with cross-account access and the behavior you're seeing is the incorrect author username on the PR.

I attempted to reproduce it on my end but unfortunately I'm not seeing the same behavior. However, I found this community post titled "Commit has the wrong author" that I think might be relevant. Let me know if that's the same behavior.

I'm also going to reach out to service team on your behalf to ask for their insights.

Hope that helps!

[randybasrs]

Cross account access through role switching, not directly accessing the repo using a user in another account. The role that access the codecommit repo is in the account with the repository.

The community post seems to be talking about the PR having a different author than the commits -- I understand that the author of the commits is not the author of a PR necessary but in this case I am saying that the author of the PR through the console is different than the author of the PR through the CLI when performing the same actions (log into Account A user with no permissions to the repo, role switch to account B delegated role with permissions, create PR in account B)

I've attached a screenshot for reference for what it looks like. The three with my normal username were created in the console. The 4th one was created using the command line. I'm not sure what I could've done differently with the CLI to make my user name appear instead.

Edit: I may be able to provide CFN templates for everything involved but it'll take a decent amount of time to pare our environment down to a very precise test case and I'll have to get authorization to spend that time on the templates. I do think for our case if we could get the username via this method it would be a decent productivity boost anyway from opening PRs in the console.

[aBurmeseDev]

Apology for the delay, I had reached out to CodeCommit team to get their insight on the API and will report back once I hear back. (ref: V1439111126)

[randybasrs]

Given the news that CodeCommit is being deprecated, I am closing this issue.

Thanks for following up on it. It was still on my list to work with you as well, but I suppose we'll be moving to a different Git service now.

Have a nice day!

[github-actions]

This issue is now closed. Comments on closed issues are hard for our team to see.
If you need more assistance, please open a new issue that references this one.