On Thu, Dec 1, 2016 at 5:19 PM, Jordan Liggitt <[email protected]> wrote:
> The dockercfg secret contains the value of one of the tokens (which is > required to exist in order for the service account token to continue to be > a valid credential) in dockercfg format > > This has been a source of confusion. I understand the need for a separate dockercfg SA that references an actual token, but why the second token? It's seems unnecessary and users don't know which one to use, why it's there, etc. > On Thu, Dec 1, 2016 at 4:59 PM, Srinivas Naga Kotaru (skotaru) < > [email protected]> wrote: > >> For Docker login purpose, I could see another token ( I think this is >> what you are talking about) >> >> >> >> cae-ops-dockercfg-04ccd kubernetes.io/dockercfg >> 1 1h >> >> cae-ops-token-5vrkf kubernetes.io/service-account-token >> 3 1h >> >> cae-ops-token-jdhez kubernetes.io/service-account-token >> 3 1h >> >> >> >> 1st token being used for Docker. Was wondering about other 2 tokens. >> >> >> >> -- >> >> *Srinivas Kotaru* >> >> >> >> *From: *Jordan Liggitt <[email protected]> >> *Date: *Thursday, December 1, 2016 at 1:39 PM >> >> *To: *Srinivas Naga Kotaru <[email protected]> >> *Cc: *dev <[email protected]> >> *Subject: *Re: cluster wide service acount >> >> >> >> One token is the one generated to mount into pods that run as the service >> account. >> >> The other is the one wrapped into a dockercfg secret used as a credential >> against the internal docker registry. >> >> >> >> On Thu, Dec 1, 2016 at 3:56 PM, Srinivas Naga Kotaru (skotaru) < >> [email protected]> wrote: >> >> Thanks, it is working. Able to login using service account token >> >> >> >> # oc get sa >> >> # oc get secrets >> >> # oc get secret cae-ops-token-5vrkf --template='{{.data.token}}' >> >> >> >> decode base64 token >> >> >> >> # oc login –token=<decoded token> >> >> >> >> *Qeustion:* >> >> >> >> I can see 2 secrets for each service accont and both are valied to login. >> Any idea why 2 ? >> >> >> >> # oc get secrets >> >> >> >> cae-ops-token-5vrkf kubernetes.io/service-account-token >> 3 35m >> >> cae-ops-token-jdhez kubernetes.io/service-account-token >> 3 35m >> >> >> >> -- >> >> *Srinivas Kotaru* >> >> >> >> *From: *Jordan Liggitt <[email protected]> >> *Date: *Thursday, December 1, 2016 at 12:26 PM >> >> >> *To: *Srinivas Naga Kotaru <[email protected]> >> *Cc: *dev <[email protected]> >> *Subject: *Re: cluster wide service acount >> >> >> >> If you have the service account's token, you can use it from the command >> line like this: >> >> oc login --token=... >> >> >> >> The web console does not provide a way to log in with a service account >> token. >> >> >> >> On Thu, Dec 1, 2016 at 3:19 PM, Srinivas Naga Kotaru (skotaru) < >> [email protected]> wrote: >> >> Jordan >> >> >> >> That helps. Thanks for quick help. >> >> >> >> Can we use this sa account to login into console and OC clinet? If yes >> how? I knew SA account only has non expired token but no password >> >> >> >> >> >> -- >> >> *Srinivas Kotaru* >> >> >> >> *From: *Jordan Liggitt <[email protected]> >> *Date: *Thursday, December 1, 2016 at 12:04 PM >> *To: *Srinivas Naga Kotaru <[email protected]> >> *Cc: *dev <[email protected]> >> *Subject: *Re: cluster wide service acount >> >> >> >> Service accounts exist within a namespace but can be granted permissions >> across the entire cluster, just like any other user. For example: >> >> oadm policy add-cluster-role-to-user cluster-reader >> system:serviceaccount:openshift-infra:monitor-service-account >> >> >> >> On Thu, Dec 1, 2016 at 3:02 PM, Srinivas Naga Kotaru (skotaru) < >> [email protected]> wrote: >> >> I knew we can create a service account per project and can be used as a >> password less API work and automations activities. Can we create a service >> account at cluster level and can be used for platform operations >> (monitoring, automation, shared account for operation teams)? >> >> >> >> Intention is to have expiry free tokens. >> >> >> >> -- >> >> *Srinivas Kotaru* >> >> >> _______________________________________________ >> dev mailing list >> [email protected] >> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev >> >> >> >> >> >> >> > > > _______________________________________________ > dev mailing list > [email protected] > http://lists.openshift.redhat.com/openshiftmm/listinfo/dev > >
_______________________________________________ dev mailing list [email protected] http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
