In our company, all Jenkins jobs are only created via the Jenkins DSL. Our Jenkins permissions are controlled via LDAP. For this we use the Jenkins LDAP Plugin (https://wiki.jenkins.io/display/JENKINS/LDAP+Plugin) version 1.20.
Currently individual LDAP users are authorized:
freeStyleJob ('Jobname') {
[...]
authorization {
permission('hudson.model.Item.Build', 'User1')
permission('hudson.model.Item.Build', 'User2')
[...]
}
[...]
}
I would like to use LDAP groups instead of authorizing individual users:
freeStyleJob ('Jobname') {
[...]
authorization {
permission('hudson.model.Item.Build', 'LDAPROLE_BUILD')
}
[...]
}
How do I have to adjust my DSL files to use LDAP roles instead of single users?
That is exactly the way you have to do it:
freeStyleJob ('Jobname') {
[...]
authorization {
permission('hudson.model.Item.Build', 'LDAPROLE_BUILD')
}
[...]
}
If you want to give multiple LDAP Roles the rights to build you have to do it with an array:
freeStyleJob ('Jobname') {
[...]
authorization {
permission('hudson.model.Item.Build', ['LDAPROLE_BUILD1', 'LDAPROLE_BUILD2'])
}
[...]
}
It is also usefull to give the role that has rights to build also the rights to cancel a build hudson.model.Item.Cancel
To give a LDAP role only rights to 'read' a job you can use Read and Workspace:
hudson.model.Item.Read
hudson.model.Item.Workspace
Related
I can't figure out how I can tell gradle to take the credentials id from jenkins and apply them? I use such a construct in build.gradle:
repositories {
maven {
name ’test'
url «test.com"
credentials {
username = System.getenv("JENKINS_CREDENTIALS_ID")
password = System.getenv("JENKINS_CREDENTIALS_ID")
}
}
}
How do I transfer the account id from jenkins?
The documentation from the plugin site seems to be wrong: https://github.com/jenkinsci/gitlab-plugin
Example from job dsl documentation: https://jenkinsci.github.io/job-dsl-plugin/#method/javaposse.jobdsl.dsl.helpers.triggers.TriggerContext.gitlabPush
In GitLabPushTrigger you can set secretToken but how can I set it via job dsl?
My current Job:
job('seed-job-v2') {
description('Job that makes sure a service has a build pipeline available')
triggers {
gitlabPush {}
}
...
}
Use the dynamic DSL:
job('example') {
triggers {
gitlab {
secretToken('foo')
}
}
}
The dynamic DSL supports almost all config options.
Alternative would be this
job('Test') {
triggers {
gitlabPush {
}
}
configure {
it / triggers / 'com.dabsquared.gitlabjenkins.GitLabPushTrigger' << secretToken('SECRET')
}
}
There is direct support for this in pipelineTriggers which you can only view in the live API viewer in you jenkins server.
Refer
https://stackoverflow.com/a/66111017/1606098
I have created a credential in Jenkins called AZURE_CLIENT_ID. I have the "Credentials Binding Plugin" installed.
If I create a Job manually in the UI I am able to select the Binding I would like for the Environment and select my Secret Text type.
I want to replicate this in my Jobs DSL script. I have found the following snippet which is very close to what I want to do:
job('example-2') {
wrappers {
credentialsBinding {
usernamePassword('PASSWORD', 'jarsign-keystore')
}
}
}
However the credential I want to inject is Secret Text and I cannot find what the function to it with is, e.g. instead of usernamePassword. Does anyone know what this should be please?
'Secret text' kind credentials are retrieved as 'string()' in the credentialBinding context.
For example:
job('example') {
wrappers {
credentialsBinding {
string('SECRETWORD', 'name_of_credential')
}
}
}
Documentation at: https://jenkinsci.github.io/job-dsl-plugin/#method/javaposse.jobdsl.dsl.helpers.wrapper.WrapperContext.credentialsBinding
I want to know how can i use Job Dsl to configure trigger "Trigger build remotely" a pipeline job.
I need input string as Authentication Token.
My sample code:
pipelineJob("PipelineJobs") {
logRotator {
daysToKeep(7)
numToKeep(10)
}
concurrentBuild(false)
parameters {
stringParam('PHID',null,null)
stringParam('SHA1',null,null)
}
triggers {
}
}
Thanks.
Internally that option is not a trigger, so you can't find it within the triggers context.
You need to use authenticationToken on the job level, see the API Viewer
pipelineJob('example') {
authenticationToken('secret')
}
I want to implement permission-based access control as discussed in this post.
I am not familiar with the implementation - is there any detailed example on how to implement this from start to finish?
Have you seen the Spring security plugin? Main docs are here
As in this post you could also consider the Shiro plugin as well. I find the Spring security plugin a simpler but the Shiro one does have some advantages as discussed in the post.
I have just solved this (mostly) so I post it here for reference. This solution works on Grails 2.2.4 and Spring Security 2.0 RC
1) Security Domain Model
You model your security domain classes as described in the article, so you will have these domains in the end:
- Permission
- Role
- RolePermission
- User
- UserRole
2) Querying authorities for users
You make sure that your User class returns Permissions instead of Roles as authorities in the getAuthorities() method:
/**
* Gets authorities for the user.
*
* It will return all of the Permissions of the User assigned by the Roles
* which the User has
*/
Set<Permission> getAuthorities() {
Set allPermissions = []
// Collect all Roles of the User
UserRole.findAllByUser(this).each { userRole ->
// Collect all Permissions from the Role
Role role = userRole.role
// Returning the collected permissions
RolePermission.findAllByRole(role).each { rp ->
allPermissions.add(rp.permission)
}
}
return allPermissions
}
3) Spring Security Config
I have this in my Config.groovy for Spring Security configuration (non-relevant parts omitted):
grails {
plugin {
springsecurity {
...
userLookup {
userDomainClassName = 'limes.security.User'
}
authority {
nameField = 'name'
className = 'limes.security.Permission'
}
...
}
}
}
One important highlight is the authority.nameField which MUST conform with your Permission class. The name attribute is called 'name' in my model (and the article).
Naturally, you set your Permission class as the authority.className in order to make it fit with the return values of User.getAuthorities().
4) Using in security expressions
The solution above does not solve the limitation of the Grails Spring Security plugin that you can use only authority name starting with "ROLE_".
So, if you want to call your permissions like "PERM_PERMISSION1", than you have to write EL expressions for checks everywhere (notybly on controller #Secured annotations and static url rules).
So instead of
#Secured(["PERM_PERMISSION1"])
You write
#Secured(["hasRole('PERM_PERMISSION1')"])