-
Notifications
You must be signed in to change notification settings - Fork 3
Open
Labels
enhancementNew feature or requestNew feature or request
Description
We should have login mechanism based on the Kubernetes TokenReview (just like the Vault does: https://developer.hashicorp.com/vault/api-docs/auth/kubernetes)
An K8 pod is running with a service account with token review cluster role:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: tokenreview-integrator
rules:
- apiGroups: ["authentication.k8s.io"]
resources: ["tokenreviews"]
verbs: ["create"]
The K8 token present in the POD can be exchanged for the Keystone token.
For this Keystone sends a call to K8:
POST /apis/authentication.k8s.io/v1/tokenreviews
HEADERS:
authorization: bearer ${K8_TOKEN}
BODY:
{
"apiVersion": "authentication.k8s.io/v1",
"kind": "TokenReview",
"spec": {
"token": "TOKEN_RECEIVED_FROM_CLIENT",
"audiences": ["my-api-service"]
}
}
response:
{
"apiVersion": "authentication.k8s.io/v1",
"kind": "TokenReview",
"status": {
"authenticated": true,
"user": {
"username": "system:serviceaccount:default:my-client-app",
"uid": "a1b2c3d4-e5f6-7890-1234-567890abcdef",
"groups": [
"system:authenticated",
"system:serviceaccounts",
"system:serviceaccounts:default"
]
},
"audiences": [
"my-api-service"
]
}
}
With info like that we can map the data to the Keystone user and grant corresponding federated token.
This is not really a federated auth anymore since it is absolutely not OIDC based. So a brand new set of DB/API resources is necessary
Metadata
Metadata
Assignees
Labels
enhancementNew feature or requestNew feature or request
Type
Projects
Status
Backlog