kcp-dev / kcp

Kubernetes-like control planes for form-factors and use-cases beyond Kubernetes and container workloads.
https://kcp.io
Apache License 2.0
2.35k stars 381 forks source link

bug: 403 forbidden when kcp is enabled with OIDC #2952

Closed yogesh-reddy closed 1 year ago

yogesh-reddy commented 1 year ago

Describe the bug

Started KCP with oidc creds

oidc: 
  issuerUrl: https://dev-xxxx.okta.com/oauth2/default
  clientId: xxxxx
  usernameClaim: preferred_username
  groupClaim: groups

Provided kubconfig with oidc login creds

Error from server (Forbidden): services is forbidden: User "https://dev-xxx.okta.com/oauth2/default#user@abc.com" cannot list resource "services" in API group "" in the namespace "default": access denied

Created Roles and Rolebindings for the same

kind: Role
metadata:
  name: kaurd-svc-role
rules:
- apiGroups: [""]
  resources: ["services"]
  verbs: ["get","watch","list"]
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: kaurd-dev-oidc-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: kaurd-svc-role
subjects:
- kind: Group
  name: user@abc.com

FYI: looked at this issue https://github.com/kcp-dev/kcp/pull/2319 and made sure preferred_username is present in claims

Steps To Reproduce

k get svc

Expected Behaviour

listing the services

Additional Context

No response

embik commented 1 year ago

Hi @yogesh-reddy, I'm not sure if you are still looking for a solution, but there are two things standing out to me:

First: Your username is prefixed with the issuer URL as you can see from your server error. With your configuration, your user name isn't user@abc.com (as configured in the RBAC you provided) - it's https://dev-xxx.okta.com/oauth2/default#user@abc.com. That is a different entity than what your RBAC targets.

If you want to change this, take a look at the --oidc-username-prefix flag, it describes this behaviour and how to alter it:

--oidc-username-prefix string
                If provided, all usernames will be prefixed with this value. If not provided, username claims other than 'email' are prefixed by the issuer URL to avoid clashes. To skip any prefixing, provide the value '-'.

Secondly: If you fix the issue above to bring RBAC and actual user identity in line, you might also need to configure workspace access for your OIDC user entity.

Note: I suspect this is not a bug but "working as intended".

embik commented 1 year ago

Closing since there has been not a response, please reopen if there is still an issue.