Skip to content
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

Make session token duration configurable in AmazonWebServicesCredentialsBinding #52

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

nathandines
Copy link
Contributor

AmazonWebServicesCredentialsBinding is often used as the entrypoint to using this plugin in Jenkins pipelines. This change allows developers to override the session token duration in their pipelines.

This can be convenient if it's preferable to have a lower default value for session durations, but need a longer duration for a specific operation such as baking a large AMI.

Example usage:

stage('build') {
    steps {
        withCredentials([[
            $class: 'AmazonWebServicesCredentialsBinding',
            credentialsId: 'aws-dev-creds',
            stsTokenDuration: 7200
        ]]) {
            sh 'packer packer.json'
        }
    }
}

@nathandines
Copy link
Contributor Author

Hey @andresrc, could I please get a review on this?

AWSCredentials credentials = getCredentials(build).getCredentials();
AmazonWebServicesCredentials credentialRetriever = getCredentials(build);
if (stsTokenDuration != null) {
credentialRetriever.setStsTokenDuration(stsTokenDuration);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will potentially change the configuration in the credentials store, and thus change the behavior at least for all builds in the current session which do not specify this parameter.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah, I didn't realise this. Thanks for letting me know.

@jglick
Copy link
Member

jglick commented Jun 10, 2019

Perhaps you could have an AWSCredentialsImpl.getCredentials() overload taking an alternate int stsTokenDuration.

@nathandines nathandines force-pushed the feature/request-session-duration branch from 61bef5c to 5838c1f Compare June 12, 2019 22:47
@@ -87,14 +88,25 @@ public String getSecretKeyVariable() {
return secretKeyVariable;
}

@DataBoundSetter
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You also need a matching public getter; and an update to config.jelly.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cheers. Just for my benefit, could you please point me to the docs explaining the need for both the setter and the getter together? Or just briefly explain why? I believe that it's necessary, but would appreciate a better understanding of it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Docs are not really written I am afraid. The getter is needed so that the equivalent of ${instance.stsTokenDuration} would work when reconfiguring an object from Jelly. Something like this would be evaluated by having a databound control inside an f:entry. You can get a test to fail against your code as written by using JenkinsRule.configRoundtrip with a SecretBuildWrapper (or StepConfigTester with a BindingStep, a bit more work), though it would be overkill if you are not doing anything out of the ordinary.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, okay. That makes sense. Thanks for the explanation :)

return getCredentials(this.getStsTokenDuration());
}

public AWSCredentials getCredentials(Integer stsTokenDuration) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably int not Integer, or can this be null?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think it should generally be null. Probably better to prevent this.

I had used Integer rather than int, as it seems to be used pretty consistently across the project. For the moment, I've added the @NonNull annotation on it. Do you think this would be sufficient, or do you think I should still change it to int?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be int unless you have a clear use case for a null value.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay. Just changed it

@nathandines nathandines force-pushed the feature/request-session-duration branch 2 times, most recently from fdbd780 to f48977f Compare June 13, 2019 22:24
By enabling runtime configuration of the STS token duration, this
enables a shorter token duration to be defined by default on a Jenkins
master, but enables users to explicilty request a longer session token
for longer running jobs. This helps to ensure that the credential
lifetime is only as long as necessary.
@nathandines nathandines force-pushed the feature/request-session-duration branch from f48977f to 7e201fb Compare June 13, 2019 22:43
@nathandines
Copy link
Contributor Author

Hey @jglick, I made the requested changes last week. Are you able to re-review, please?

@jglick
Copy link
Member

jglick commented Jun 21, 2019

No time, sorry, will leave it to the plugin maintainer (whoever that may be).

@@ -45,6 +45,7 @@
String getDisplayName();

AWSCredentials getCredentials(String mfaToken);
AWSCredentials getCredentials(int stsTokenDuration);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Adding a new method is a binary incompatible change. Can you check if there are any implementations (at least in the jenkinsci organization) that could break? Anyway, some kind of notice would be needed.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @andresrc, I've just been thinking about this lately, what do you think if this change was removed, and the dependent class (AmazonWebServicesCredentialsBinding) was adjusted to reference our class rather than this interface?

As its usage is within the same package, I think this should be okay; could you please validate this? I'm not 100% sure on what's coming in through the build parameter, however, and not sure if this would influence whether the resulting var will always be of AWSCredentialsImpl type.

I haven't actually tested this theory, so it might not even functionally work, but just your thoughts on the approach before trying it.


Location: found here

        AmazonWebServicesCredentials credentialRetriever = getCredentials(build);

would become

        AWSCredentialsImpl credentialRetriever = getCredentials(build);

@Vlatombe Vlatombe added the enhancement New feature or request label Oct 1, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants