Required claims does not support arrays and failing kubernetes auth with oidc - EKS

[aws-sidhartha]

We have added an IDP called "lmiprod" to the EKS cluster with the following command and it has requiredClaims which specifies roles as a list and everyone in the list who has access prod role should be able to access the cluster and currently they are receiving the unauthorized error with requiredClaims but without that everyone in the OIDC app is able to access the cluster.

---

aws eks associate-identity-provider-config --cluster-name xxxx-1 --oidc 'identityProviderConfigName=lmiprod,issuerUrl=https://login.microsoftonline.com//v2.0,clientId=ClientId,usernameClaim=email,usernamePrefix=oidc:,groupsClaim=groups,groupsPrefix=oidc:,requiredClaims={roles=prod}' --region us-west-2

The token which we are trying to use looks like this:

{
"aud": "xxx",
"iss": "https://login.microsoftonline.com/ffe3c2ff-f367-4962-b7ee-6e7bba609fb8/v2.0",
"iat": 1618472379,
"nbf": 1618472379,
"exp": 1618476279,
"email": "xxxxx",
"groups": [
"xxxx",
"xxxx",
"xxxx"
],
"name": "xxxx",
"nonce": "xxxx",
"oid": "xxxx",
"preferred_username": "xxxx",
"rh": "xxxxx",
"roles": [
"rxxxx",
"dxxx",
"pxxxx"
],
"sub": "xxxxxx",
"tid": "xxxxxx",
"uti": "xxxxxx",
"ver": "2.0"
}

So the "roles" claim is a list and we want to allow everyone that has the "prod" role to access the cluster. This doesn't work,

we get back:

I0415 10:16:40.885213 2190013 round_trippers.go:445] GET https://xxxxx.sk1.us-west-2.eks.amazonaws.com/api?timeout=32s 401 Unauthorized in 319 milliseconds
I0415 10:16:40.885240 2190013 round_trippers.go:451] Response Headers:
I0415 10:16:40.885260 2190013 round_trippers.go:454] Date: Thu, 15 Apr 2021 08:16:40 GMT
I0415 10:16:40.885269 2190013 round_trippers.go:454] Audit-Id: 19ef2f74-52c0-43b0-9d0e-b8338256efa7
I0415 10:16:40.885276 2190013 round_trippers.go:454] Cache-Control: no-cache, private
I0415 10:16:40.885284 2190013 round_trippers.go:454] Content-Type: application/json
I0415 10:16:40.885291 2190013 round_trippers.go:454] Content-Length: 129
I0415 10:16:40.888998 2190013 request.go:1107] Response Body: {"kind":"Status","apiVersion":"v1","metadata":{},"status":"Failure","message":"Unauthorized","reason":"Unauthorized","code":401}
I0415 10:16:40.892985 2190013 cached_discovery.go:121] skipped caching discovery info due to Unauthorized
I0415 10:16:40.893256 2190013 helpers.go:216] server response object: [{
"metadata": {},
"status": "Failure",
"message": "Unauthorized",
"reason": "Unauthorized",
"code": 401
}]

Not specifying the "requiredClaims" field works, but allows all people in that OIDC app to access the cluster.

Arrays are supported with groups but not with requiredClaims:

For more information:

Array support is present only for group claims -

kubernetes/staging/src/k8s.io/apiserver/plugin/pkg/authenticator/token/oidc/oidc.go

Lines 600 to 610 in 27cf50d

	if a.groupsClaim != "" {
	if _, ok := c[a.groupsClaim]; ok {
	// Some admins want to use string claims like "role" as the group value.
	// Allow the group claim to be a single string instead of an array.
	//
	// See: https://github.com/kubernetes/kubernetes/issues/33290
	var groups stringOrArray
	if err := c.unmarshalClaim(a.groupsClaim, &groups); err != nil {
	return nil, false, fmt.Errorf("oidc: parse groups claim %q: %v", a.groupsClaim, err)
	}
	info.Groups = []string(groups)

Required claims does not support arrays -

kubernetes/staging/src/k8s.io/apiserver/plugin/pkg/authenticator/token/oidc/oidc.go

Line 626 in 27cf50d

// NOTE: Only string values are supported as valid required claim values.

[k8s-ci-robot]

@aws-sidhartha: This issue is currently awaiting triage.

If a SIG or subproject determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[neolit123]

/sig auth
cc @micahhausler

[fejta-bot]

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-contributor-experience at kubernetes/community.
/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue.

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[enj]

@aws-sidhartha with #121078 merged, this should be possible now as an alpha feature in v1.29.