-
Bug
-
Resolution: Not A Defect
-
Minor
-
None
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.