I like the use of Jenkinsfiles and shared-libraries for their purported benefits, but i have some governance concerns about execution of arbitrary Jenkinsfiles (and potential use of broadly scoped credentials).
I'm thinking it would be convenient to lock down credentials to use by a specific shared-library to enforce usage patterns (at the same time, i think it's entirely possible that there are better ways to approach the problem space), so i'm just reaching out for any ideas/guidance in this space.
Not sure if our solution would work for you or not.
We have a shared library; reviewed and rather locked down so that not just anyone can make a change to it. We have that library attached to two separate folders on our Jenkins.
In one folder, our users have their own personal or team based folders and can create jobs and credentials in that space. There are no shared credentials on this big folder and teams do not share their credentials with each other.
There is a second folder, which none of the users/teams have edit access to, but can execute existing jobs. There are no Jenkinsfile, SCM-based jobs in that folder where they can modify the job via SCM. This folder has the "locked down" credentials on it that are not meant to be shared or accessible. The users/teams can edit their jobs (in their folders) to call these jobs - but they can't edit these protected jobs to gain access to the credentials.
It's awkward in a way. But it has preserved the divide between users and credentials they shouldn't have access to.
Related
This model looks good: https://cloud.google.com/architecture/managing-infrastructure-as-code-with-terraform-jenkins-and-gitops#infrastructure_proposal
However it's possible for anyone with repo access to create a feature branch, put any old content into a jenkinsfile, and create a PR - at which point Jenkins will run whatever's in the jenkinsfile. To me this kinda negates the controls to enforce peer review of code, or stops you allowing certain individuals only permitted to deploy changes to dev etc.
I'm not aware that you can "protect" the jenkinsfile and stop this happening (at least not in github).
Best solution may be to enforce controls at the cloud access key credential level (I'm an AWS user so I think in terms of secret access key) - so only certain jenkins (or github) users can pull the creds to make infrastructure changes?
We have Jenkins setup in our organisation with two organisational folders which basically does builds for repo's from two different github organizations.
We use Keycloak to authenticate to Jenkins. (Not sure if that's relevant or not) and we authenticate using openid connect with Keycloak.
I would like to know if it is possible to restrict access for a certain group of users to only be able to view builds on one of the github organizations. So for example if we have two github organizations: mrrobot_org and evilcorp_org, then I would like to be able to make an evilcorp_org_devs_group and add users to that group which would then restrict those developers from only accesing builds from the evilcorp_org github organization.
Someone told me this might be possible to do from Keycloak, but it does not seem likely.
I've tried quite a few things already but from what I've read the best option seems to use this plugin
https://plugins.jenkins.io/role-strategy/
and match the organzation using a regex to match a folder:"Folders can be matched using expressions like
^foo/bar.*".
Any other suggestions how I could do this?
Thanks so much.
For anyone reading this. I ended up using the Folder auth plugin for Jenkins.
I ended up sticking to Keycloak for Authentication, but used the folder auth plugin for Authorization.
So this allows me to restrict access per Jenkins folder. Each folder containing the builds of a given github organization.
The plugin is pretty easy to use. You can check it out here:
https://github.com/jenkinsci/folder-auth-plugin
The docs are here:
https://github.com/jenkinsci/folder-auth-plugin/blob/master/docs/usage.md
Is there a way to share Jenkins service endpoint credentials across multiple TFS projects? We have close to 30 projects, and each build requires us to configure the same set of credentials.
I would like to set an environment variable or something that would allow us to manage those credentials in one place for all TFS projects.
For a specific project, you click the gear here:
And then enter the credentials here:
This is not possible yet, there is a Feature Request about it, you can up vote there.
To automate the process you can create the Jenkins endpoints with the Rest API Endpoints - Create.
No. Service connections are scoped at the Team Project level. Team Projects are intended to be largely isolated from one another, so there is limited ability to share things between them. If you need to manage a service endpoint across many projects, you'll need to look at the REST APIs and write a programmatic solution.
We're using Jenkins (and precisely Cloudbees) for couple years. Well, it works.
Not I have new use case when I would like to allow trigger build remotely (w/o user account in Cloudbees).
Looks like it's impossible (standard token trigger mechanism requires an account in Cloudbees).
The only one way that I see it to set-up instant message integration (e.g. Jabber) and trigger builds in chat. It's nice solution that I would like to have, but ... it doesn't work for me. No errors and no messages (I tried different jabber servers).
Because I have only one such weird user I don't want to install special software (like Jabber/IRC server) and wanna use existing (like Gtalk or similar).
Any thoughts will be welcome.
standard token trigger mechanism requires an account in Cloudbees
You can use the Build Token Root plugin to bypass authentication long enough to check the token.
In the long term it would be desirable for Jenkins to let users create non-user principals that would have their own API tokens and SSH keys (but no UI login) and a restricted subset of permissions, so you could freely create a one-off principal for a specific purpose such as triggering builds. The infrastructure for such a feature does not exist today, however.
I don't know squat about TFS, other than as a user who has performed simple check in/outs.
I just installed it locally and would like to do joint development with a friend.
I was having trouble making my TFS web site on port 8080 visible (the whole scoop is here if your interested) and I wonder if it could be related to the fact that TFS is probably using Windows Authentication to identify the user.
Can TFS be set up to use forms authentication?
We probably need to set up a VPN, though that's a learning curve too.
To use TFS, do our machines have to belong to a domain?
We're not admin types, though he is better than me, though I would be interested in any feedback or advice on which path is likely to pan out the best. I already got AxoSoft OneTime working in this type of an environment and it suits us well, but I am tempted at all the bells & whistles with TFS and the ability to tie tracked bug items to code changes.
As far as finding a good way to share code, do sites like SourceForge allow one to keep code secure among members only?
It does not need to be installed in a domain. I'm running TFS at home within a workgroup on a virtual machine.
Create a user on the machine that hosts TFS. Let's assume this machine is named TFS-MACHINE. Grant that user appropriate Team and Project rights.
When connecting to TFS from the remote machine, the user should be prompted for a user ID and password. They should use a User ID of TFS-MACHINE\username and the appropriate password.
Regarding external spots to host code. If you're looking for cheap/free, you can look at something like Unfuddle, which supports SVN and Git.
If you're looking for hosted TFS, the only place I've been able to find thus far is SaaS Made Easy, but they can start getting a bit expensive, depending on the number of users you have.
Keep in mind if you're going to host locally that you'll still need to do things like periodic backups, etc.