It's referenced in the dockercfg secret openshift.io/token-secret.name
annotation
On Fri, Dec 2, 2016 at 9:32 AM, Mateus Caruccio <
mateus.caruc...@getupcloud.com> 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 <jligg...@redhat.com>
> wrote:
>
>> They are managed by different controllers, and it gives you individual
>> revocation ability.
>>
>> On Dec 2, 2016, at 9:14 AM, Aaron Weitekamp <aweit...@redhat.com> wrote:
>>
>> On Thu, Dec 1, 2016 at 5:19 PM, Jordan Liggitt <jligg...@redhat.com>
>> 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) <
>>> skot...@cisco.com> 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 <jligg...@redhat.com>
>>>> *Date: *Thursday, December 1, 2016 at 1:39 PM
>>>>
>>>> *To: *Srinivas Naga Kotaru <skot...@cisco.com>
>>>> *Cc: *dev <dev@lists.openshift.redhat.com>
>>>> *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) <
>>>> skot...@cisco.com> 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 <jligg...@redhat.com>
>>>> *Date: *Thursday, December 1, 2016 at 12:26 PM
>>>>
>>>>
>>>> *To: *Srinivas Naga Kotaru <skot...@cisco.com>
>>>> *Cc: *dev <dev@lists.openshift.redhat.com>
>>>> *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) <
>>>> skot...@cisco.com> 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 <jligg...@redhat.com>
>>>> *Date: *Thursday, December 1, 2016 at 12:04 PM
>>>> *To: *Srinivas Naga Kotaru <skot...@cisco.com>
>>>> *Cc: *dev <dev@lists.openshift.redhat.com>
>>>> *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) <
>>>> skot...@cisco.com> 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
>>>> dev@lists.openshift.redhat.com
>>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> dev mailing list
>>> dev@lists.openshift.redhat.com
>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>>>
>>>
>>
>> _______________________________________________
>> dev mailing list
>> dev@lists.openshift.redhat.com
>> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>>
>>
>
_______________________________________________
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
