svcacct token issuer should support oidc discovery #2314

mikedanese · 2018-06-26T17:39:57Z

This was omitted from the original document for the purpose of expediting it's merge. Reintroducing now that we've made progress.

This change allows clients with knowledge of oidc discovery to validate service account tokens. Simpler clients can choose to ignore the discovery document and validate tokens against the keys directly by fetching the JWKs URL.

@kubernetes/sig-auth-feature-requests @kubernetes/sig-auth-api-reviews

k8s-ci-robot · 2018-06-26T17:40:05Z

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: liggitt

Assign the PR to them by writing /assign @liggitt in a comment when ready.

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

contributors/design-proposals/auth/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

micahhausler

This is really great stuff! Can the kid for a given signing key be included in the JWT header? The existing proposal didn't specify, and that would be something I'd like to see. The existing proposal's decoded header comes out to

{
  "alg": "RS256",
  "typ": "JWT"
}

One other question about this, would the existing SA signing key in the Controller Manager remain or would it be deprecated?

micahhausler · 2018-07-03T02:36:06Z

contributors/design-proposals/auth/bound-service-account-tokens.md

+      "kty": "RSA",
+      "alg": "RS256",
+      "use": "sig",
+      "kid": "ccab4acb107920dc284c96c6205b313270672039",


I see multiple keys here, would the --service-account-signing-key: file contain multiple keys? Would the flag be specified multiple times? Would a apiserver restart be required to trigger a new list of keys (for that specific server)? How do you determine the kid for a given key? How would the apiserver determine which key is used for a TokenRequest response?

I assume these would be populated from the --service-account-key-file flag, which is used for verifying presented tokens, and does take multiple files (or files with multiple key PEM blocks):

File containing PEM-encoded x509 RSA or ECDSA private or public keys, used to verify ServiceAccount tokens. The specified file can contain multiple keys, and the flag can be specified multiple times with different files.

a server restart is required to pick up new public keys today

How would the apiserver determine which key is used for a TokenRequest response?

the signing key specified by --service-account-signing-key-file is used

the signing key specified by --service-account-signing-key-file is used

Sorry I wasn't clear on the last question. When given a list of keys, which one is used to sign a TokenRequest? Ex: I want to rotate out a certain key and stop signing new tokens with it, but still keep it around for verification of existing tokens.

Also, is kid derived from the key? I'm just fuzzy on where that comes from, and how it is coordinated across API servers.

When given a list of keys, which one is used to sign a TokenRequest

--service-account-signing-key-file takes a single key, and is used to sign TokenRequests.

--service-account-key-file takes multiple keys for verification purposes.

ah that part makes sense. I wasn't paying close enough attention and was merging --service-account-key-file and --service-account-signing-key-file.

micahhausler · 2018-07-03T02:46:49Z

contributors/design-proposals/auth/bound-service-account-tokens.md

+> GET /.well-known/openid-configuration
+{
+  "issuer": "https://dev.cluster.internal",
+  "jwks_uri": "https://dev.cluster.internal/serviceaccountkeys/v1",


For this non-resource URL, would a RBAC policy/binding like below be required for applications utilizing this K8s IDP? I'm guessing this would require --anonymous-auth=true with something similar to the below policy/binding

apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: system:oidc rules: - nonResourceURLs: - /.well-known/openid-configuration - /serviceaccountkeys/v1 verbs: - get --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: system:oidc roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: system:oidc subjects: - apiGroup: rbac.authorization.k8s.io kind: Group name: system:unauthenticated

That should work.

You want both system:unauthenticated and system:authenticated.

liggitt · 2018-07-03T03:16:39Z

contributors/design-proposals/auth/bound-service-account-tokens.md

+{
+  "issuer": "https://dev.cluster.internal",
+  "jwks_uri": "https://dev.cluster.internal/serviceaccountkeys/v1",
+  "authorization_endpoint": "urn:kubernetes:programmatic_authorization",


is this compatible with https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata:

authorization_endpoint REQUIRED. URL of the OP's OAuth 2.0 Authorization Endpoint

that specifies a URL, not a URI (which would allow a URN)

Does authorization_endpoint even make sense? There is no way to actually do an OAuth flow with the API master.

liggitt · 2018-07-03T03:19:01Z

contributors/design-proposals/auth/bound-service-account-tokens.md

+  "claims_supported": [
+    "sub",
+    "iss"
+  ]


if grant_types is omitted, the default value is ["authorization_code", "implicit"], which means that token_endpoint is also required

using an openid discovery doc as a vehicle for publishing links to public keysets gets weird when the tokens we're wanting to allow someone to validate can't actually be obtained via an openid flow... we'd have to do things like advertise grant_types_supported:[] and make our authorization_endpoint point to a URL that rejected all requests. that seems pretty weird.

However, grant types are extensible:

https://tools.ietf.org/html/rfc6749#section-8.3

An alternative is to make

"grant_types":["urn:kubernetes:grant_type:programmatic_authorization"]

and make authorization_endpoint point somewhere bogus.

@BrenoDeMedeiros do you have any thoughts on how we should express the Kubernetes id_token flow in a openid-configuration to support oidc discovery?

mikedanese · 2018-07-03T03:59:49Z

@mdietz

enj · 2018-08-28T18:43:21Z

While discovery in general sounds like a good idea, especially to allow distributed auth models, the OpenID Provider Metadata is clearly focused on Open ID flows.

If we take OpenShift as an example, today you can do:

$ oc get --raw '/.well-known/oauth-authorization-server'

Which returns:

{
  "issuer": "https://<master>",
  "authorization_endpoint": "https://<master>/oauth/authorize",
  "token_endpoint": "https://<master>/oauth/token",
  "scopes_supported": [
    "user:check-access",
    "user:full",
    "user:info",
    "user:list-projects",
    "user:list-scoped-projects"
  ],
  "response_types_supported": [
    "code",
    "token"
  ],
  "grant_types_supported": [
    "authorization_code",
    "implicit"
  ],
  "code_challenge_methods_supported": [
    "plain",
    "S256"
  ]
}

But that makes sense because a user can actually go through an OAuth flow with the server and have an OAuth token returned to them. No such flows exists for SA tokens, and I do not think anyone actually wants such a flow to exist.

Basically, Kube SA tokens are JWTs, but that does not have any specific relationship to OIDC. Perhaps there is a different way to discover a jwks_uri?

mikedanese · 2018-08-28T22:26:58Z

OIDC discovery would be exposed because it is widely adopted and supported by target integrations (e.g. AWS, vault, dex etc...). I think we need to meet integrations where they are rather then force them to implement a new spec to validate k8s service account identities. I'm open to considering other discovery mechanisms but level of support is my top consideration.

enj · 2018-08-29T02:11:24Z

OIDC discovery would be exposed because it is widely adopted and supported by target integrations (e.g. AWS, vault, dex etc...)

I do not think this actually succeeds in making any of those integrations easier. This still have to know that this is a Kube OIDC discovery doc, and that only meaningful field is jwks_uri. @liggitt's concerns in #2314 (comment) basically point out that this proposed endpoint simply fails to meet the OIDC contract. Having custom grant types just further couples any integration with Kube specifics. So if integrations already need to know that "this is a Kube SA token and all you can do is verify it - you cannot do any other OIDC things with it," than at best you have allowed them to reuse some existing structs for decoding.

I guess with this doc a generic verify method could be written for OIDC like endpoints:

func Verify(token, issuer string) bool {
    // get discovery doc
    // use it to get all info needed to verify token
}

I am not sure how critical reuse of any such logic would be to any integrator.

liggitt · 2018-08-29T04:14:11Z

I do not think this actually succeeds in making any of those integrations easier.

It would support discovery/loading of the info needed to verify a token obtained out of band (this is the same level of info the kube OIDC token verifier uses from the issuer discovery docs)

enj · 2018-08-29T11:00:02Z

It would support discovery/loading of the info needed to verify a token obtained out of band (this is the same level of info the kube OIDC token verifier uses from the issuer discovery docs)

Right, no disagreement there. I am mostly referring to the fact that integrators still have Kube specific knowledge in their codebase, so I am not seeing how this is different than a custom Kube specific endpoint (non-resource or resource) that does not pretend to be OIDC.

mikedanese · 2018-08-29T17:08:47Z

I am mostly referring to the fact that integrators still have Kube specific knowledge in their codebase

I think this is not true. This doc would be compatible with AWS and vault without any changes on their side.

enj · 2018-08-29T23:04:23Z

I think this is not true. This doc would be compatible with AWS and vault without any changes on their side.

Can you describe their use case? Or point me to the docs or code? I can see how they could use this endpoint (because it is close enough to everything else and they only care about the jwks_uri). As a user I would find it very confusing to be presented an OIDC discovery doc from a server that cannot perform any OIDC flow.

micahhausler · 2018-08-30T00:48:42Z

@enj A use case we're exploring based on this proposal is outlined here https://docs.google.com/document/d/1V_B24zNLInLPRIPRXQeKj4JAJDUvKe-hZPJvrgx80yQ/edit

We would like for Kubernetes would implement enough of OIDC to act as a federated identity provider in AWS. With the current proposal, there wouldn't be anything specific to Kubernetes we'd have to do on our side.

enj · 2018-09-12T18:23:20Z

contributors/design-proposals/auth/bound-service-account-tokens.md

+```
+> GET /.well-known/openid-configuration
+{
+  "issuer": "https://dev.cluster.internal",


This would match the issuer in the SA JWT I assume. Presumably that cannot change since that would invalidate the JWTs.

enj · 2018-09-12T18:25:40Z

contributors/design-proposals/auth/bound-service-account-tokens.md

+{
+  "issuer": "https://dev.cluster.internal",
+  "jwks_uri": "https://dev.cluster.internal/serviceaccountkeys/v1",
+  "authorization_endpoint": "urn:kubernetes:programmatic_authorization",


I feel like having a dummy authorization_endpoint does not really honor the OIDC spec.

Pretty sure token endpoint is also required:

token_endpoint URL of the OP's OAuth 2.0 Token Endpoint [OpenID.Core]. This is REQUIRED unless only the Implicit Flow is used.

scopes_supported also weird:

scopes_supported RECOMMENDED. JSON array containing a list of the OAuth 2.0 [RFC6749] scope values that this server supports. The server MUST support the openid scope value. Servers MAY choose not to advertise some supported scope values even when this parameter is used, although those defined in [OpenID.Core] SHOULD be listed, if supported.

fejta-bot · 2019-01-20T07:31:45Z

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

mikedanese · 2019-01-22T19:09:28Z

/remove-lifecycle stale

mikedanese · 2019-01-22T19:10:24Z

How do people feel about only exposing a JWKs URL and proceeding from there? That solves half of the problem. The other 49% is discovering the issuer URL.

liggitt · 2019-01-22T19:31:45Z

How do people feel about only exposing a JWKs URL and proceeding from there?

I think that's a much easier step to reason about, and makes sense to me as a starting point.

That would be necessary as a prereq for inclusion in an oidc discovery doc as well

cceckman · 2019-01-29T18:05:05Z

If a relying party wants to validate the token (including the iss claim), they'd still need a provider-specific discovery mechanism to find that issuer.

Could we offer a subset of the OIDC metadata (issuer, jwks_uri, anything else necessary) at a non-standard endpoint? e.g. /serviceaccountissuer/{keys,metadata} rather than /.well-known/openid-configuration?

cceckman · 2019-03-06T19:39:16Z

Some notes from this week's sig-auth meeting- I'm probably misrepresenting these a bit, apoligies:

@liggitt: "We're using this for validation, not for request flows. Not going to be helpful to offer at a nonstandard path" (as I suggested above; fair.) "Work out the minimal spec-compliant thing that won't cause validators to crash."
@mikedanese: "Authz endpoint is an actual URL, but always returns 403 / 404. Nothing that says grant types have to be well-known."

fejta-bot · 2019-06-04T19:51:12Z

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

cceckman · 2019-06-05T03:08:09Z

/remove-lifecycle stale

liggitt · 2019-07-10T16:53:24Z

can we move this into a KEP in enhancements? would be good to reconcile this with the external signing proposal to make sure whatever we end up with there supports this goal as well

mikedanese · 2019-07-11T23:37:40Z

Ya, was planning on doing that.

Move kubernetes/community#2314 to a KEP.

svcacct token issuer should support oidc discovery

330fc67

k8s-ci-robot added the size/M Denotes a PR that changes 30-99 lines, ignoring generated files. label Jun 26, 2018

k8s-ci-robot requested review from ericchiang and liggitt June 26, 2018 17:40

k8s-ci-robot added cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. kind/design Categorizes issue or PR as related to design. sig/auth Categorizes an issue or PR as relevant to SIG Auth. labels Jun 26, 2018

micahhausler reviewed Jul 3, 2018

View reviewed changes

liggitt reviewed Jul 3, 2018

View reviewed changes

enj reviewed Sep 12, 2018

View reviewed changes

k8s-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Jan 20, 2019

k8s-ci-robot removed the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Jan 22, 2019

enj mentioned this pull request May 31, 2019

serviceaccounts: Add JWT KeyIDs to tokens kubernetes/kubernetes#78502

Merged

k8s-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Jun 4, 2019

k8s-ci-robot removed the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Jun 5, 2019

liggitt mentioned this pull request Jul 10, 2019

Consider publishing the service account public key somewhere kubernetes/kubernetes#23064

Closed

mikedanese closed this Jul 11, 2019

cceckman mentioned this pull request Jul 29, 2019

Provide OIDC discovery for service account token issuer kubernetes/kubernetes#80724

Merged

mikedanese deleted the oidc branch October 23, 2019 18:34

k8s-ci-robot added a commit to kubernetes/enhancements that referenced this pull request Oct 23, 2019

Merge pull request #1190 from cceckman/original-kep

cba7bf6

Move kubernetes/community#2314 to a KEP.

svcacct token issuer should support oidc discovery #2314

svcacct token issuer should support oidc discovery #2314

Conversation

mikedanese commented Jun 26, 2018 • edited Loading

k8s-ci-robot commented Jun 26, 2018

micahhausler left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

micahhausler Jul 3, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

liggitt Jul 3, 2018 • edited Loading

Choose a reason for hiding this comment

mikedanese Jul 3, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mikedanese commented Jul 3, 2018

enj commented Aug 28, 2018

mikedanese commented Aug 28, 2018

enj commented Aug 29, 2018

liggitt commented Aug 29, 2018

enj commented Aug 29, 2018 • edited Loading

mikedanese commented Aug 29, 2018

enj commented Aug 29, 2018

micahhausler commented Aug 30, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

fejta-bot commented Jan 20, 2019

mikedanese commented Jan 22, 2019

mikedanese commented Jan 22, 2019 • edited Loading

liggitt commented Jan 22, 2019 • edited Loading

cceckman commented Jan 29, 2019

cceckman commented Mar 6, 2019

fejta-bot commented Jun 4, 2019

cceckman commented Jun 5, 2019

liggitt commented Jul 10, 2019

mikedanese commented Jul 11, 2019

mikedanese commented Jun 26, 2018 •

edited

Loading

micahhausler Jul 3, 2018 •

edited

Loading

liggitt Jul 3, 2018 •

edited

Loading

mikedanese Jul 3, 2018 •

edited

Loading

enj commented Aug 29, 2018 •

edited

Loading

micahhausler commented Aug 30, 2018 •

edited

Loading

mikedanese commented Jan 22, 2019 •

edited

Loading

liggitt commented Jan 22, 2019 •

edited

Loading