[kontinuity-dev-public] Jenkins service account does not work on slaves (only on master)

[Ben Parees]

On Jun 19, 2016 4:05 AM, "Tomas Nozicka" <tnozicka at redhat.com> wrote:
>
> On So, 2016-06-18 at 19:05 -0700, Ben Parees wrote:
>>
>>
>>
>> On Fri, Jun 17, 2016 at 7:27 AM, Tomas Nozicka <tnozicka at redhat.com>
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 https://kubernetes.default/ --token=$(cat /run/secrets/
kubernetes.io/serviceaccount/token) --certificate-authority=/run/secrets/
kubernetes.io/serviceaccount/ca.crt
>>>   "Logged into "https://kubernetes.default:443" 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/
kubernetes.io/serviceaccount/token'
> }
> node('redhatdistortion-maven') {
>     sh "oc login https://kubernetes.default/ --token=${k8s_token}
--certificate-authority=/run/secrets/kubernetes.io/serviceaccount/ca.crt"
> }
>
> 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
>>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/kontinuity-dev-public/attachments/20160619/8c4442e1/attachment.htm>