Details
-
New Feature
-
Status: Resolved (View Workflow)
-
Major
-
Resolution: Fixed
-
None
Description
To properly perform access control on activities inside build steps, we need executors to carry an Authentication object just like HTTP request handling threads do. In effect, a build is going to impersonate someone (or a subset of someone) while it executes, and when a build tries to access other things inside Jenkins (be it artifacts from another build, access to a slave, etc.), it'll be automatically subject to the same error checks that request handling threads g et.
The major unresolved question has been how/who determines which build carries which Authentication object, as there are several use cases:
- imod told me in the past that his environment enforces a naming convention for all the jobs, and that's enough to programmatically determine the identity that the build will run under. His environment also ties AuthorizationStrategy based on the job names, so this creates an effective access control.
- In a Jenkins instance with the folder plugin, a folder that the jobs are in could determine the identity of the build (in much the same way the naming convention works.)
- Sometimes it might be appropriate to run the build with the identity of the user who triggered a build. (or is it? what's the concrete use case?)
- Sometimes perhaps it should allow the user to click a button in the job config screen to let the build run as that user. This is obviously a sensitive operation as the job configuration can be updated by someone else after that.
All this seems to point toward the direction of making this pluggable, which makes sense. OTOH, if this is pluggable, what should be the default implementation?
Attachments
Issue Links
- depends on
-
JENKINS-22949 QueueItemAuthenticator fallback behavior cleanup
-
- Resolved
-
- is blocking
-
JENKINS-16956 Require authentication for build triggers
-
- Resolved
-
Activity
Another good thought exercise is to think about what the recommended security setup for those who want to "enable security" for some reasonable definition of it.
That is, if one integrates Active Directory and do a global matrix security, what should be the identity of the executors? I guess some fixed user would do.
Now what if it's the per-project matrix security? Then it's the one that lets you set it on job-by-job basis?
Code changed in jenkins
User: Kohsuke Kawaguchi
Path:
changelog.html
core/pom.xml
core/src/main/java/hudson/ExtensionListView.java
core/src/main/java/hudson/model/AbstractProject.java
core/src/main/java/hudson/model/Executor.java
core/src/main/java/hudson/model/Fingerprint.java
core/src/main/java/hudson/model/Node.java
core/src/main/java/hudson/model/Run.java
core/src/main/java/hudson/model/queue/AbstractQueueTask.java
core/src/main/java/hudson/model/queue/AbstractSubTask.java
core/src/main/java/hudson/model/queue/MappingWorksheet.java
core/src/main/java/hudson/model/queue/QueueTaskFilter.java
core/src/main/java/hudson/model/queue/SubTask.java
core/src/main/java/hudson/model/queue/Tasks.java
core/src/main/java/hudson/security/GlobalSecurityConfiguration.java
core/src/main/java/hudson/util/CopyOnWriteList.java
core/src/main/java/hudson/util/PersistedList.java
core/src/main/java/jenkins/security/ProjectAuthenticator.java
core/src/main/java/jenkins/security/ProjectAuthenticatorConfiguration.java
core/src/main/java/jenkins/security/ProjectAuthenticatorDescriptor.java
core/src/main/resources/hudson/model/Messages.properties
core/src/main/resources/jenkins/security/ProjectAuthenticator/config.groovy
core/src/main/resources/jenkins/security/ProjectAuthenticatorConfiguration/config.groovy
test/src/test/java/hudson/model/QueueTest.java
http://jenkins-ci.org/commit/jenkins/2d09a0e54be7bea3ae8d0f203aa5baac6e062275
Log:
[FIXED JENKINS-18285] Merge the feature branch
Compare: https://github.com/jenkinsci/jenkins/compare/3c01366e0bc5...2d09a0e54be7
Unfortunate that you filed a new issue rather than referring to the existing JENKINS-16956 where I had been gathering related issues and notes, so linking now.
I guess the right default implementation is the one that keeps the backward compatible behaviour, which means running all the builds as the SYSTEM user.