jenkinsci / aws-credentials-plugin

CloudBees Amazon Web Services Credentials Plugin
https://plugins.jenkins.io/aws-credentials/
MIT License
29 stars 75 forks source link

MFA required on assuming IAM role #16

Open saimak opened 7 years ago

saimak commented 7 years ago

I am trying this plugin for the first time. When trying to configure the Jenkins job to assume iam role in advanced settings, getting error related to MFA. Whereas MFA is disabled for the user. Also, the trust policy of the role being assumed does not have any condition for MFA specified. Can you please guide what can be wrong.

"There was an error assuming the specified IAM role, a MFA may be required by your organization"

alexejk commented 7 years ago

Does the user have permission to assume role and the role you are assuming has proper trust relationship that allows such action?

I've had an issue with Session variables not set but that seems like a different case.

philmcardle commented 7 years ago

I'm not able to use this on roles that require MFA to assume.

e.g., with this condition on the target role:

"Condition": { "Bool": { "aws:MultiFactorAuthPresent": "true" } }

I can configure the credentials fine with the role name, MFA Serial Number (ARN), and a one-time code from the MFA device, and it will validate in the UI, but as soon as I try to run a job that uses those credentials, I'll get:

User: arn:aws:iam::111:user/source-user is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::222:role/target-role (Service: AWSSecurityTokenService; Status Code: 403; Error Code: AccessDenied; Request ID: XYZ)

This error only occurs when the target role requires MFA, otherwise everything is fine.

I'm assuming roles across accounts, if that's not clear, but presumably shouldn't be relevant.

More clarification, I'm using the AWS CLI from within a withCredentials block, and I've installed the version of the plugin from #20 or I can't use the CLI with roles, of course.

alexejk commented 7 years ago

Im actually not sure how it was thought that MFA would work at all in this scenario. We had to create a new role specifically for Jenkins to assume that does not require MFA.

MFA tokens are bound to time, they expire fast and this is why it validates one-time for you but does not validate when a job runs - they are already consumed and expired. There might be a way to make a job query for a token as a parameter before the job runs, and then directly use it to create a credential binding - but I don't think its obvious if it will work. I'll look a bit into it when time permits, as I have an idea about it.

evisar commented 7 years ago

Providing MFA token at credentials creation time doesn't make sense, as the whole credential will become unusable just seconds after your click save. This needs to allow MFA token code input in the params UI just before running the build to make it work, otherwise it's completely useless.

marcelloromani commented 5 years ago

allow MFA token code input in the params UI just before running the build to make it work

Provided the MFA token is used within its expiration, which is pretty much random

weaversam8 commented 2 years ago

I have a job configured this way which prompts for token in the params UI before running, but I'm not sure the AmazonWebServicesCredentialsBinding even allows you to specify mfaToken from within a pipeline. With a configuration like this:

withCredentials([[
    $class: 'AmazonWebServicesCredentialsBinding',
    credentialsId: deployCredentialsId,
    mfaToken: mfaCode
]]) {
    // ...
}

The following error appears during run:

WARNING: Unknown parameter(s) found for class type 'com.cloudbees.jenkins.plugins.awscredentials.AmazonWebServicesCredentialsBinding': mfaToken

The Javadocs don't look very promising here. Is there another parameter name I should be using here, or is this still completely unsupported?

If so, why is there an mfaToken input supported by this plugin at all if it's only supported within the credentials UI?

weaversam8 commented 2 years ago

I've drafted an initial pull request (#160) that takes a stab at addressing this issue. It isn't merged yet (and needs some additional polishing re: tests and a few other things) but if you urgently need this feature (like I did) you're welcome to clone that branch and build from scratch.