-
Notifications
You must be signed in to change notification settings - Fork 146
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
Add support for aws ec2 backend #126
base: master
Are you sure you want to change the base?
Conversation
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 Few of my understanding about nonce:
Please provide your thoughts. Thanks |
Signed-off-by: Dinesh <[email protected]>
I don't think this belongs here. https://github.com/jenkinsci/aws-secrets-manager-credentials-provider-plugin |
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 |
@jetersen Am I missing something ? I still hope this PR belongs to this repo. Could you please verify it once ? |
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. |
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. |
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) |
I was more thinking of having two credentials with different nonce. |
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 ? |
@jetersen Any updates ? |
@dineshba waiting on you? 😅 Still missing the nonce implementation? |
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) |
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? :) |
Signed-off-by: Dinesh <[email protected]>
Hi @Stetchy ... I have implemented Other than testing, updating readme with details is the only pending thing in this PR |
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. |
Hi @Stetchy Thanks for the help. If you could test it, we can merge this PR. What would you mean by JCasC updates ? |
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 |
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. |
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. |
Signed-off-by: Dinesh [email protected]
You enter your Vault AWS auth
role
name andmountPath
(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