Add support for aws ec2 backend

[dineshba]

Signed-off-by: Dinesh dineshudt17@gmail.com

You enter your Vault AWS auth role name and mountPath (default: aws). The pkcs7 will be retrieved from AWS Instance Metadata server (IMDS) and used for authentication. This requires that Jenkins master is running on an AWS instance.

Note: IMDSv1 is used to fetch the pkcs7. For more details about IMDS refer

[dineshba]

Need some suggestion on the aws client nonce

Can we capture nonce as the secret in the credentials panel ? Currently it is hardcoded as string nonce in the code.

Few of my understanding about nonce:

• nonce cannot be changed once the jenkins authenticated against vault using aws ec2 instance data. Vault will cache the nonce against the aws ec2 instance id
• If we really want to change nonce, we can delete the identity allowlist in vault vault delete auth/aws/identity-whitelist/<ec2-instance-id>
• nonce cannot be empty. If empty, vault will return the nonce in the first authentication call. For the subsequent calls, we have to send that nonce to the vault. Which means jenkins server should hold nonce across restarts.
• we can provide the initial nonce and same should be used for subsequent auth requests to vault. Can we provide this initial nonce as a value in the credential panel ?

Please provide your thoughts. Thanks

[jetersen]

I don't think this belongs here.

https://github.com/jenkinsci/aws-secrets-manager-credentials-provider-plugin

[dineshba]

Hi @jetersen,

aws-secrets-manager-credentials-provider-plugin looks like the plugin for aws-secrets-manager

In this current PR, I used the aws auth method to login to vault. This is very similar to GCP Credential flow in this plugin.

Please correct me if I am wrong @jetersen

[dineshba]

@jetersen Am I missing something ? I still hope this PR belongs to this repo. Could you please verify it once ?

[jetersen]

For the nonce I think it would be best to generate a random secret value once. The field should be a Secret and for databinding needs to be a hidden field on the form.

Not sure how it would work if two credentials are defined with different roles.

[dineshba]

Sure @jetersen I will make the nonce as secret.

Regarding two credentials with different role, I will do some testing in aws instance and get back to you.

[dineshba]

In Vault, client_nonce is stored against the ec2 instance.

$ vautl read auth/aws/identity-whitelist/<ec2-instance-id>
Key                          Value
---                          -----
client_nonce                 <client_nonce>
disallow_reauthentication    false
role                         jenkins-role

which means we should to use the same nonce for login using ec2-instance

Lets say, we are running two jenkins instance inside same ec2-instance, then we have to specify the same nonce for the both the instance.

So I feel we can make the nonce as secret field as discussed. But we can let the user give some random value. Thoughs @jetersen ?

Lets say user want to change the nonce (or forgot the nonce), then they to delete the old client_nonce from vault server

vault delete auth/aws/identity-whitelist/<ec2-instance-id>

(this instruction, we can add it in the readme)

[jetersen]

I was more thinking of having two credentials with different nonce.
Perhaps the AWS nonce should be an global setting?

[dineshba]

I feel, we may not need two credentials for aws itself. Even if it is needed, if user is able to enter the random value for nonce field, they can enter same value in both the credentials. Does it make sense ? I prefer not having global nonce for aws. Thoughts ?

[dineshba]

@jetersen Any updates ?

[jetersen]

@dineshba waiting on you? 😅 Still missing the nonce implementation?

[dineshba]

Sorry @jetersen I wanted to confirm with you before proceeding with the nonce implementation.

I will update the PR soon with nonce implementation. Users can enter the random value for the nonce (which is secret)

[riain0]

Hey - I'm quite interested in the use case this PR will bring. Has there been any further updates on this/is there anything I can help with to get this across the line? :)

[dineshba]

Hi @Stetchy ... I have implemented to get nonce value from user as secret for aws-ec2-backend. This part is not yet testing by running jenkins and configuring the vault plugin with ec2 backend. I dont have infra now. So it is taking time to test.

Other than testing, updating readme with details is the only pending thing in this PR

[riain0]

Hi @dineshba, thanks for the update, that's great. I can test the plugin on my infra if you'd like? I'd love to help out!

Also, does this PR have the scope for including updates for JCasC? If so, I can also help contribute that, it seems like it would be good to get done too.

[dineshba]

Hi @Stetchy Thanks for the help. If you could test it, we can merge this PR.

What would you mean by JCasC updates ?

[riain0]

Hi @dineshba, sorry I'm taking so long to test this - my access to Vault was changed so just waiting for it to go back to normal. Hopefully done this/next week.

Re JCasC, I may have misunderstood it in the code, but there are environment variables used to help set up this plugin via JCasC and I couldn't see the same for the EC2 Backend - for example, something like this

[dineshba]

Hi @Stetchy Re JCasC, it is for secretSource. It can be seperate PR as this is different functionality altogether. We can create a different PR once this is merge.

Once you have tested this feature, we can merge this PR.

[dbnicholson]

I didn't notice this when working on #166, which does the IAM flow rather than the EC2 metadata flow. However, my thinking for the EC2 metadata flow is that you don't supply the nonce but let vault return it to you on first use. Then you store the nonce per instance ID as a secret and try to retrieve it when needed. I.e., it's not a configuration parameter but rather secret state. But that got further into jenkins secret storage than I was familiar with.