On Jun 19, 2016 4:05 AM, "Tomas Nozicka" <<a href="mailto:tnozicka@redhat.com">tnozicka@redhat.com</a>> wrote: > > On So, 2016-06-18 at 19:05 -0700, Ben Parees wrote: >> >> >> >> On Fri, Jun 17, 2016 at 7:27 AM, Tomas Nozicka <<a href="mailto:tnozicka@redhat.com">tnozicka@redhat.com</a>> wrote: >>> >>> I have modified my Jenkinsfile to use service account and I have found out that Jenkins master and slaves run under different service accounts. >>> >>> Ben's template creates ServiceAccount named "jenkins" with the correct permissions but slaves are run with ServiceAccount named "default" without permissions. This ends up for me after login with: >>> $ oc login <a href="https://kubernetes.default/">https://kubernetes.default/</a> --token=$(cat /run/secrets/<a href="http://kubernetes.io/serviceaccount/token">kubernetes.io/serviceaccount/token</a>) --certificate-authority=/run/secrets/<a href="http://kubernetes.io/serviceaccount/ca.crt">kubernetes.io/serviceaccount/ca.crt</a> >>> "Logged into "<a href="https://kubernetes.default:443">https://kubernetes.default:443</a>" as system:serviceaccount:catapult:default using the token provided. >>> "You don't have any projects. ..." >>> >>> Changing to the same project I am in ends with: >>> $ oc project catapult >>> error: You are not a member of project "catapult". >>> You are not a member of any projects. You can request a project to be created with the 'new-project' command. >>> >>> I tried those steps manually by "docker exec" into master instance and it works fine there with "jenkins" service account. >>> >>> Can I somehow set up Jenkins slaves to use the correct service account? >>> Or can we roll back to not having special service account for Jenkins and use the default one? I think it was in the template before... >>> >> using the default service account means we have to grant edit permission to the default service account, which is undesirable. Sounds like we need a patch to the k8s plugin to use the same service account the master is using and/or make the service account configurable as part of the podtemplate definition. >> >> Jimmi, what does the kubernetes-workflow plugin do with respect to this situation? >> >> in the meantime, if you grant edit permissions to your default svc account, you should be set. > > Thanks Ben, I have actually went with other workaround: > > #!/usr/bin/groovy > def k8s_token = '<unknown>' > node ('master') { > k8s_token = readFile '/var/run/secrets/<a href="http://kubernetes.io/serviceaccount/token">kubernetes.io/serviceaccount/token</a>' > } > node('redhatdistortion-maven') { > sh "oc login <a href="https://kubernetes.default/">https://kubernetes.default/</a> --token=${k8s_token} --certificate-authority=/run/secrets/<a href="http://kubernetes.io/serviceaccount/ca.crt">kubernetes.io/serviceaccount/ca.crt</a>" > } > > But it is still a workaround. > > Do you think we could think add some permission to jenkins service account to allow this: > > + oc policy add-role-to-user system:image-puller system:serviceaccount:test-prod:default --namespace=test No I don't think we can do that, that's a specific grant to a specific project that not all users will have. We can only add permissions relative to the current project(in your case, catapult I believe). There are really two problems: 1) the user may not have permission to grant themselves access to another project (you are presumably running that command as cluster admin) and 2) the project name is specific to your scenario. So this is something you'll have to set up explicitly. > > Error from server: User "system:serviceaccount:test:jenkins" cannot get policybindings in project "test" > > > It is the last think that does not work with using service accounts right now in my pipeline. > > Thanks, > Tomas > >> >> >>> >>> >>> Thanks, >>> Tomas >>> >> >>