That is cool stuff and intrigue
oc get secret/cae-ops-dockercfg-04ccd -o yaml | grep token-secret.name
openshift.io/token-secret.name: cae-ops-token-jdhez
❯ oc get secrets | grep cae-ops
cae-ops-dockercfg-04ccd kubernetes.io/dockercfg 1 20h
cae-ops-token-5vrkf kubernetes.io/service-account-token 3 20h
cae-ops-token-jdhez kubernetes.io/service-account-token 3 20h
again, I would like to take this as an opportunity and liberty to comment on
OpenShift documentation. The documentation has to be bit clear, easy explain,
easy to quickly find and navigate, to knew these tricks and day to day use
cases. Lot of scope to improve documentation.
--
Srinivas Kotaru
From: <[email protected]> on behalf of Jordan Liggitt
<[email protected]>
Date: Friday, December 2, 2016 at 6:40 AM
To: Mateus Caruccio <[email protected]>
Cc: dev <[email protected]>
Subject: Re: cluster wide service acount
It's referenced in the dockercfg secret
openshift.io/token-secret.name<http://openshift.io/token-secret.name> annotation
On Fri, Dec 2, 2016 at 9:32 AM, Mateus Caruccio
<[email protected]<mailto:[email protected]>> wrote:
It would be nice if I could identify which token belongs to dockercfg. Maybe by
name like "cae-ops-dockercfg-token-5vrkf"
--
Mateus Caruccio / Master of Puppets
GetupCloud.com - Eliminamos a Gravidade
On Fri, Dec 2, 2016 at 12:18 PM, Jordan Liggitt
<[email protected]<mailto:[email protected]>> wrote:
They are managed by different controllers, and it gives you individual
revocation ability.
On Dec 2, 2016, at 9:14 AM, Aaron Weitekamp
<[email protected]<mailto:[email protected]>> wrote:
On Thu, Dec 1, 2016 at 5:19 PM, Jordan Liggitt
<[email protected]<mailto:[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]<mailto:[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<http://kubernetes.io/dockercfg> 1
1h
cae-ops-token-5vrkf
kubernetes.io/service-account-token<http://kubernetes.io/service-account-token>
3 1h
cae-ops-token-jdhez
kubernetes.io/service-account-token<http://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]<mailto:[email protected]>>
Date: Thursday, December 1, 2016 at 1:39 PM
To: Srinivas Naga Kotaru <[email protected]<mailto:[email protected]>>
Cc: dev <[email protected]<mailto:[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]<mailto:[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<http://kubernetes.io/service-account-token>
3 35m
cae-ops-token-jdhez
kubernetes.io/service-account-token<http://kubernetes.io/service-account-token>
3 35m
--
Srinivas Kotaru
From: Jordan Liggitt <[email protected]<mailto:[email protected]>>
Date: Thursday, December 1, 2016 at 12:26 PM
To: Srinivas Naga Kotaru <[email protected]<mailto:[email protected]>>
Cc: dev <[email protected]<mailto:[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]<mailto:[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]<mailto:[email protected]>>
Date: Thursday, December 1, 2016 at 12:04 PM
To: Srinivas Naga Kotaru <[email protected]<mailto:[email protected]>>
Cc: dev <[email protected]<mailto:[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]<mailto:[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]<mailto:[email protected]>
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
_______________________________________________
dev mailing list
[email protected]<mailto:[email protected]>
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
_______________________________________________
dev mailing list
[email protected]<mailto:[email protected]>
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
_______________________________________________
dev mailing list
[email protected]
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
