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]> 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]> wrote:
>
> 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
>
>
_______________________________________________
dev mailing list
[email protected]
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Reply via email to