-
Notifications
You must be signed in to change notification settings - Fork 74
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
Allow specifying AWS role at runtime #81
Conversation
I am not a maintainer. |
@jglick Any idea who the maintainers are? |
@escoem perhaps. |
ping @escoem |
@escoem Is this project abandoned? This change is pretty important for us. |
ping @andresrc |
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.
The big missing part of this PR is a test.
I don't know how much of code coverage we have here but changing code related with credentials without tests is a big risk.
The RoleSessionDurationSeconds
limits problem I commented would have been detected with a test.
...n/java/com/cloudbees/jenkins/plugins/awscredentials/AmazonWebServicesCredentialsBinding.java
Outdated
Show resolved
Hide resolved
.withStsClient(stsClient); | ||
|
||
if (this.roleSessionDurationSeconds > 0) { | ||
assumeRoleProviderBuilder = assumeRoleProviderBuilder | ||
.withRoleSessionDurationSeconds(this.roleSessionDurationSeconds); | ||
} |
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.
We might have a problem here.
The setter requires a value between 900 and 3600, or it throws an IllegalArgumentException
. But we are not checking this.
However, the STSAssumeRoleSessionCredentialsProvider
constructor will use DEFAULT_DURATION_SECONDS
(900) if the value is equal to 0.
I would suggest to either have a doCheckX
method in the descriptor to validate that the duration is truly between 900 and 3600. You can even have the default value to 900
. This would not be used in pipeline setup.
Or you need to change the condition here.
(option 1)
.withStsClient(stsClient); | |
if (this.roleSessionDurationSeconds > 0) { | |
assumeRoleProviderBuilder = assumeRoleProviderBuilder | |
.withRoleSessionDurationSeconds(this.roleSessionDurationSeconds); | |
} | |
.withStsClient(stsClient) | |
.withRoleSessionDurationSeconds(this.roleSessionDurationSeconds); |
(option 2)
.withStsClient(stsClient); | |
if (this.roleSessionDurationSeconds > 0) { | |
assumeRoleProviderBuilder = assumeRoleProviderBuilder | |
.withRoleSessionDurationSeconds(this.roleSessionDurationSeconds); | |
} | |
.withStsClient(stsClient); | |
if (this.roleSessionDurationSeconds >= 900 && this.roleSessionDurationSeconds <= 3600) { | |
assumeRoleProviderBuilder = assumeRoleProviderBuilder | |
.withRoleSessionDurationSeconds(this.roleSessionDurationSeconds); | |
} |
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.
My intent was to let the bounds just be controlled by the AWS SDK so that you don't have to keep the two in sync. (For example, a newer version of the SDK might change it so you can assume a role for up to 2 hours.) Similarly, I think it makes more sense to allow the default value to be chosen by the SDK, as it currently is.
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 understand. The problem is that the "check" will be done by the library which throws an exception. I'm not sure this is the most clear way to handle the situation for users.
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 a little confused. What exactly would we do in this code if the role session duration is out of bounds other than throw an exception ourselves?
@alecharp I would need some guidance on how to write such tests. There don't appear to be any existing tests other than ConfigurationAsCodeTest.java (which is irrelevant). |
Neither this plugin, nor
Writing tests against live AWS is certainly possible, with some effort; making them exercise specific IAM/STS features is particularly hard, since the person/process running the test may not physically be permitted to use that feature, depending on how their account is set up. You can try to run Dockerized tests against OpenStack or various mock frameworks, but identity & security systems are likely to be the least accurately simulated, and anyway this is hardly proving that the code would actually work in AWS itself (though it could help detect regressions from routine refactorings not touching the basic design). |
ping @alecharp |
…ration at runtime. Fixes #80. Signed-off-by: Jesse Rittner <rittneje@gmail.com>
ping @alecharp |
7 similar comments
ping @alecharp |
ping @alecharp |
ping @alecharp |
ping @alecharp |
ping @alecharp |
ping @alecharp |
ping @alecharp |
2 similar comments
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. Seems we just have to wait a bit for @escoem to be available to merge and release this.
Fixes #80.
Testing
We have been using this feature on our CloudBees instance for several months now. We have not experienced any issues with it. We have been fetching credentials in two ways:
credentialsId
,roleArn
androleSessionName
providedcredentialsId
,accessKeyVariable
, andsecretKeyVariable
providedBoth have been working flawlessly.
In addition, when implementing this change, I did integration testing on our CloudBees instance to cover the following cases:
credentialsId
,roleArn
,roleSessionName
, androleSessionDurationSeconds
credentialsId
androleArn
credentialsId
androleArn
, withroleSessionName
as the empty stringcredentialsId
, withroleArn
as the empty stringcredentialsId
All of these cases passed, as verified by calling
sh 'aws sts get-caller-identity'
within thewithCredentials
block.