[JIRA] (JENKINS-53453) k8s volumes user and group

[llibic...@gmail.com (JIRA)]

Title: Message Title

Dmytro Kryvenko created an issue   Jenkins / JENKINS-53453 k8s volumes user and group Issue Type: Bug Assignee: Carlos Sanchez Components: kubernetes-plugin Created: 2018-09-07 04:20 Priority: Minor Reporter: Dmytro Kryvenko So here is the chicken-egg challenge I'm having hard times solving. I am not sure if this a bug, so yet to be classified.   1. file created by different container which was root: env.K8S_POD_LABEL = "test-${BUILD_NUMBER}" podTemplate(cloud: "k8s.example.com", label: env.K8S_POD_LABEL, yaml: """ { "apiVersion": "v1", "kind": "Pod", "spec": { "volumes": [ { "emptyDir": { }, "name": "aws-credentials" } ], "containers": [ { "name": "jnlp", "image": "jenkins/jnlp-slave", "tty": true, "volumeMounts": [ { "name": "aws-credentials", "mountPath": "/home/jenkins/.aws" } ] }, { "name": "aws-cli", "image": "mesosphere/aws-cli", "tty": true, "command": [ "cat" ], "volumeMounts": [ { "name": "aws-credentials", "mountPath": "/root/.aws" } ] } ] } } """) { stage('Debug') { node(env.K8S_POD_LABEL) { container("aws-cli") { sh 'echo foo > ~/.aws/bar.txt && chmod 400 ~/.aws/bar.txt' } sh 'cat ~/.aws/bar.txt' } } } Will fail due to no access from jnlp (jenkins user) container user to the file owned by root. 2. Suggestions in google is to use securityContext.runAsUser: env.K8S_POD_LABEL = "test-${BUILD_NUMBER}" podTemplate(cloud: "k8s.example.com", label: env.K8S_POD_LABEL, yaml: """ { "apiVersion": "v1", "kind": "Pod", "spec": { "securityContext": { "runAsUser": 1000, "allowPrivilegeEscalation": false }, "volumes": [ { "emptyDir": { }, "name": "aws-credentials" } ], "containers": [ { "name": "jnlp", "image": "jenkins/jnlp-slave", "tty": true, "volumeMounts": [ { "name": "aws-credentials", "mountPath": "/home/jenkins/.aws" } ] }, { "name": "aws-cli", "image": "mesosphere/aws-cli", "tty": true, "command": [ "cat" ], "volumeMounts": [ { "name": "aws-credentials", "mountPath": "/root/.aws" } ] }, { "name": "chefdk", "image": "chef/chefdk:3.1.0", "tty": true, "command": [ "cat" ], "volumeMounts": [ { "name": "aws-credentials", "mountPath": "/root/.aws" } ] } ] } } """) { stage('Debug') { node(env.K8S_POD_LABEL) { writeFile(file: '/home/jenkins/.aws/foo.txt', text: 'bar') container("aws-cli") { writeFile(file: '/home/jenkins/.aws/bar.txt', text: 'baz') // just to make sure writeFile will act on behalf of jnlp, even though it's in the context of aws-cli } sh 'chmod 400 /home/jenkins/.aws/*' container("chefdk") { sh 'cat /root/.aws/foo.txt' sh 'cat /root/.aws/bar.txt' } } } } This fixes original issue, but now every time I use writeFile or similar directive that has to do with a file systems - it will write a file on behalf of whatever UUID I specified in the security context, that will not be matching the UUID of other container users. Besides, forcibly running my containers with given UUID really messing things up, there is no such user with that UUID in the container, so it'll have no home directory (it's / by default that I'll likely have no access to write to), and even simple `whoami` won't work. Most of the other software and tools doesn't like it that way too. 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. For more options, visit https://groups.google.com/d/optout.