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
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
