This is useful for using credentials but I'm hoping you could add another video on using credentials scope (i.e. user/system) and domain. Specifically how to define and use credentials for a single (non-admin) user.
This is a good summary of the basics, but what happens when we want to use parameters or other environment variables within the same shell string? Single quotes resolves the warning message and passes the secrets securely, but it breaks every other type of string interpolation. How can we do both at the same time?
Even if you use single quotes, a shell will perform variable interpolation and will run curl process with exposed credentials. So you will be able to see them in OS process list even if you use single quotes. So how can single quotes be much more secure? You will see the credentials in OS process list regardless of what kind of quotes you use.
Thank you for the video, this helped to understand about each KIND of credentials use, also do you have any video on how to use WITHCREDENTIALS syntax? how & what to use in it.? would be helpful if you can post
Nope, wrong. All you've done is silenced the warning in Jenkins, you haven't changed the actual security posture at all. What you did is move variable expansion from Groovy to the shell executing curl, but both forms will still toss the raw credentials to exec() and thus show up bright as day in a ps process listing by any user on the system. If you must use curl with basic auth credentials, use a netrc file and make sure you lock down its file permissions properly.
Timecodes ⏱:
0:00 Intro
0:19 Overview
0:34 environment directive
1:37 example pipeline
2:13 String interpolation
3:56 Interpolation of sensitive environment variables
5:32 Example pipelines
8:51 Conclusion
Information referenced in this video:
environment directive for declarative pipeline
www.jenkins.io/doc/book/pipeline/syntax/#environment
Interpolation of sensitive environment variables
www.jenkins.io/doc/book/pipeline/jenkinsfile/#interpolation-of-sensitive-environment-variables
This is useful for using credentials but I'm hoping you could add another video on using credentials scope (i.e. user/system) and domain. Specifically how to define and use credentials for a single (non-admin) user.
This is a good summary of the basics, but what happens when we want to use parameters or other environment variables within the same shell string? Single quotes resolves the warning message and passes the secrets securely, but it breaks every other type of string interpolation. How can we do both at the same time?
Even if you use single quotes, a shell will perform variable interpolation and will run curl process with exposed credentials. So you will be able to see them in OS process list even if you use single quotes. So how can single quotes be much more secure? You will see the credentials in OS process list regardless of what kind of quotes you use.
Extremely clear and precise!
Thank you for the video. Helped me a lot.
Thank you for the video, this helped to understand about each KIND of credentials use, also do you have any video on how to use WITHCREDENTIALS syntax? how & what to use in it.? would be helpful if you can post
How to pass aws access and secret key in Jenkins pipeline for running aws-describe instance command
I did not see any difference between the use of single and double quotes. Both were showing ****. Just the warning was missing in the single quote.
Thank you for sharing!
Great explanation! Liked and subbed.
I think the single-quote pattern was updated from '$CRED' to '%CRED%'
If the credential has a dollar sign in it? Why it isn't handled?
Thank you very much!
agent label linux crashed my pipeline but neverthless adding this label for my built-in-node in nodes fixed it again.
Nope, wrong. All you've done is silenced the warning in Jenkins, you haven't changed the actual security posture at all.
What you did is move variable expansion from Groovy to the shell executing curl, but both forms will still toss the raw credentials to exec() and thus show up bright as day in a ps process listing by any user on the system.
If you must use curl with basic auth credentials, use a netrc file and make sure you lock down its file permissions properly.
Jenkins is soooo frustrating