The Problem
Surely and like me, you are trying to be more secure when connecting Jenkins with your AWS Accounts assuming a role. If you are asking What is that? , please read this: https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html
Of course, there are many different options to use, but the problem always surrounds us, if you use a plugin then the maintainability and security when talking about Jenkins plugins for sure decrease.
I particularly hate Jenkins, from my point of view this is an obsolete tool trying to survive in the modern world, and if you are concerned about security (and maintainability) sure understand my point.
So, why I’m writing about that?
- Because unfortunately I still using Jenkins and sweating their maintenance
- Because as a rule of thumb I try to avoid plugins that don’t have any release in the time windows of 6-12 months
- Helps others to avoid loose time and security when needs the same that me, AWS cross-account connections using Jenkins assuming a role
- Because at least if I have an Issue this is my code and I can fix it
What’s this?
- This is a guide and code for somebody using Jenkins shared library
- This is a minimal blog entry to help someone that understands Jenkins and Groovy
- This could help you if you are using Jenkins + Jenkins shared library + AWS cross-account and cross-region roles
what it is not?
- A tutorial
- A very well-explained and step-by-step guide
- Something you surely need to use
- An AWS cross-account tutorial or explanation guide
The Solution
This is how looks a segment of the code on my production Jenkins declarative pipeline.
Look at withAwsEnVars (lines: 4, 11) pipeline tags
|
|
withAwsEnVars is a Groovy function used in my Jenkins Shared Library and this is the withAwsEnVars.groovy file content:
|
|
and this is my awsCredentials.groovy file content:
|
|
from the code above, definitions are located in the Jenkins Shared Library
- codeArtifact.setupNpmrc(…) -> codeArtifact.groovy
- codeArtifact.getOwner(…) -> codeArtifact.groovy
- cicd.getRole() -> cicd.groovy
The minimal requirements on your Jenkins controller and agents
- AWS CLI
- Jenkins Plugin – Pipeline Utility Steps –> How to use?
- Jenkins Plugin – Pipeline: Basic Steps –>How to use?
- Jenkins Plugin – Mask Passwords –> How to use?
So, What is the Magic? Why do I say this is secure?
Maybe after looking at the following pipeline code, you will see how easy is to use this, and this is secure because if you execute the following code in your pipeline:
you will see masked the TOKEN, KEY and ID. Instead of seeing the real value, you will see *********** characters.
Tools and Concepts
There are various tools and concepts I used here, the first that allows me to do that so easily was Groovy Closures and it is explained how to use on Jenkins Shared Library –> Defining custom steps.
Then we have the tool withEnv provided by the Jenkins Plugin – Pipeline: Basic Steps and in combination with the use of the Groovy Closures allowed me to export the AWS Environment Variables coming from awsCredentials.getFromAssumeRole(…) groovy function into a container script part.
But, make sure that anyone who will use Jenkins Controller and Pipeline doesn’t have access to the values of the AWS Environment Variables is the job of wrap provided by the Jenkins Plugin – Pipeline: Basic Steps + maskPasswords provided by Jenkins Plugin – Mask Passwords.
Others Links
- https://www.jenkins.io/doc/book/installing/
- https://www.jenkins.io/doc/book/using/
- https://www.jenkins.io/doc/book/security/#securing-jenkins
- https://www.jenkins.io/doc/book/pipeline/
Closing
Even hating Jenkins like me, you can find different ways to do your life easy and secure with him.
If you want to look at my GitHub repositories related to Jenkins, here you have: