[JIRA] (JENKINS-58148) Jenkins pod reuse defeats cloud restrictions
Title: Message Title Jesse Glick commented on JENKINS-58148 Re: Jenkins pod reuse defeats cloud restrictions Your use case is probably better solved by locking down write access to the GitHub repository to trusted developers. That said, the behavior describes sounds like a bug; would need to check if it is reproducible. So far as I can tell there is no test coverage for KubernetesFolderProperty or KubernetesCloud.usageRestricted; none was included in the original PR and over a year has elapsed since then, so I would assume the feature does not work. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.200193.1561143547000.12609.1563304740279%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-58148) Jenkins pod reuse defeats cloud restrictions
Title: Message Title Jesse Glick updated an issue Jenkins / JENKINS-58148 Jenkins pod reuse defeats cloud restrictions Change By: Jesse Glick Labels: security Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.200193.1561143547000.12611.1563304740339%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-58148) Jenkins pod reuse defeats cloud restrictions
Title: Message Title Jesse Glick commented on JENKINS-58148 Re: Jenkins pod reuse defeats cloud restrictions Since Jenkinsfiles can be modified on a branch, and Jenkins will build whatever is in the modified Jenkinsfile Only if this modification is actually made in an origin branch; or it is made in a PR but the author of the PR has write access to the origin repository anyway. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.200193.1561143547000.12605.1563304320112%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-58148) Jenkins pod reuse defeats cloud restrictions
Title: Message Title Jesse Glick updated an issue Jenkins / JENKINS-58148 Jenkins pod reuse defeats cloud restrictions Change By: Jesse Glick *Summary*Per the Kubernetes plugin documentation, one can [restrict which can execute on clouds at the folder level| https://github.com/jenkinsci/kubernetes-plugin/ #restricting-what-jobs-can-use-your-configured-cloud]. ] Jenkins however, seems to use label selectors to find a build agent for a job (as reported by JENKINS-56546). These label selectors do not take into account whether the build agent selected is running in a restricted cloud or not.If you have a job in a folder that does not have access to a restricted cloud but specifies a label selector that matches an agent running in a restricted cloud, that job will run on the restricted cloud's agent regardless of the fact that cloud is restricted.*Use Case*Our organization has two tiers of developers: privileged and unprivileged. Unprivileged developers are not allowed to deploy to production environments.We use Jenkinsfiles to define pipelines. Our pipelines deploy to dev, test, and production environments. We want to build contributions from unprivileged developers, but ensure unmerged contributions don't go beyond dev environments. Since Jenkinsfiles can be modified on a branch, and Jenkins will build whatever is in the modified Jenkinsfile, there's nothing inherently preventing a unprivileged developer from modifying a Jenkinsfile to deploy say to production.To mitigate we have: * two different jobs ** a privileged job which triggers off master and tags ** an unprivileged job which triggers off pull requests. * those jobs are in two different folders ** a privileged folder ** an unprivileged folder. * two clouds ** privileged: restricted for use only by the privileged folder ** unprivileged: open to any job. Cloud is restricted to only have permissions and network access to our dev environments.Both the privileged and unprivileged jobs reference the same Jenkinsfile, but the cloud restrictions prevent modifications on branches to the Jenkinsfile from reaching beyond dev.The problem is, since these jobs reference the same Jenkinsfile, they used the same label, and we realized that we had unprivileged jobs running on privileged agents. We can parameterize the label so this doesn't happen by default, but since the labels are configured in the Jenkinsfile, you can't ensure the Jenkinsfile isn't modified on a branch to use a privileged agent. Not good.Is there a way to prevent jobs from running on agents in clouds they shouldn't have access to in a manner that is controlled outside of the Jenkinsfile?Currently the only solution we can think of is to have two separate Jenkins masters, one for privileged jobs and one for unprivileged, but this makes the folder restrictions for clouds seem less useful.
[JIRA] (JENKINS-58148) Jenkins pod reuse defeats cloud restrictions
Title: Message Title Chris K updated an issue Jenkins / JENKINS-58148 Jenkins pod reuse defeats cloud restrictions Change By: Chris K *Summary*Per the Kubernetes plugin documentation, one can [restrict which can execute on clouds at the folder level| [https://github.com/jenkinsci/kubernetes-plugin #restricting-what-jobs-can-use-your-configured-cloud].]Jenkins however, seems to use label selectors to find a build agent for a job (as reported by JENKINS-56546). These label selectors do not take into account whether the build agent selected is running in a restricted cloud or not.If you have a job in a folder that does not have access to a restricted cloud but specifies a label selector that matches an agent running in a restricted cloud, that job will run on the restricted cloud's agent regardless of the fact that cloud is restricted.*Use Case*Our organization has two tiers of developers: privileged and unprivileged. Unprivileged developers are not allowed to deploy to production environments.We use Jenkinsfiles to define pipelines. Our pipelines deploy to dev, test, and production environments. We want to build contributions from unprivileged developers, but ensure unmerged contributions don't go beyond dev environments. Since Jenkinsfiles can be modified on a branch, and Jenkins will build whatever is in the modified Jenkinsfile, there's nothing inherently preventing a unprivileged developer from modifying a Jenkinsfile to deploy say to production.To mitigate we have : * two different jobs , ** a privileged job which triggers off master and tags , and ** an unprivileged job which triggers off pull requests. Those * those jobs are in two different folders , ** a privileged folder and ** an unprivileged folder. We have * two clouds , ** privileged and : restricted for use only by the privileged folder ** unprivileged : open to any job . Unprivileged Cloud is restricted to only have permissions and network access to our dev environments.Both the privileged and unprivileged jobs reference the same Jenkinsfile, but the cloud restrictions prevent modifications on branches to the Jenkinsfile from reaching beyond dev.The problem is, since these jobs reference the same Jenkinsfile, they used the same label, and we realized that we had unprivileged jobs running on privileged agents. Not good.Now we We can parameterize the label so this doesn't happen by default, but since the labels are configured in the Jenkinsfile, you can't ensure the Jenkinsfile isn't modified on a branch to use a privileged agent. Not good. Is there a way to prevent jobs from running on agents in clouds they shouldn't have access to in a manner that is controlled outside of the Jenkinsfile?Currently the only solution we can think of is to have two separate Jenkins masters, one for privileged jobs and one for unprivileged, but this makes the folder restrictions for clouds seem less useful.
[JIRA] (JENKINS-58148) Jenkins pod reuse defeats cloud restrictions
Title: Message Title Chris K created an issue Jenkins / JENKINS-58148 Jenkins pod reuse defeats cloud restrictions Issue Type: Bug Assignee: Unassigned Components: kubernetes-plugin Created: 2019-06-21 18:59 Environment: Jenkins 2.176.1 LTS running on Kubernetes managed by Amazon EKS kubernetes-plugin 1.16.1 Priority: Major Reporter: Chris K Summary Per the Kubernetes plugin documentation, one can restrict which can execute on clouds at the folder level Jenkins however, seems to use label selectors to find a build agent for a job (as reported by JENKINS-56546). These label selectors do not take into account whether the build agent selected is running in a restricted cloud or not. If you have a job in a folder that does not have access to a restricted cloud but specifies a label selector that matches an agent running in a restricted cloud, that job will run on the restricted cloud's agent regardless of the fact that cloud is restricted. Use Case Our organization has two tiers of developers: privileged and unprivileged. Unprivileged developers are not allowed to deploy to production environments. We use Jenkinsfiles to define pipelines. Our pipelines deploy to dev, test, and production environments. We want to build contributions from unprivileged developers, but ensure unmerged contributions don't go beyond dev environments. Since Jenkinsfiles can be modified on a branch, and Jenkins will build whatever is in the modified Jenkinsfile, there's nothing inherently preventing a unprivileged developer from modifying a Jenkinsfile to deploy say to production. To mitigate we have two different jobs, a privileged job which triggers off master and tags, and an unprivileged job which triggers off pull requests. Those jobs are in two different folders, a privileged folder and an
