OpenID Connect Tokens
OpenID Connect is a flavor of OAuth2 supported by some OAuth2 providers, notably Azure Active Directory, Salesforce, and Google. The protocol’s main extension of OAuth2 is an additional field returned with the access token called an ID Token. This token is a JSON Web Token (JWT) with well known fields, such as a user’s email, signed by the server.
To identify the user, the authenticator uses the id_token (not the access_token) from the OAuth2 token response as a bearer token. See above for how the token is included in a request.
(°0°)The user initiates a login request in the dex-k8s-authenticator (login.k8s.example.com)
dex-k8s-authenticator redirects the request to Dex (dex.k8s.example.com)
Dex redirects to the GitHub authorization page
GitHub encrypts the corresponding information and passes it back to Dex
Dex forwards this information to dex-k8s-authenticator
The user gets the OIDC token from GitHub
dex-k8s-authenticator adds the token to kubeconfig
kubectl passes the token to KubeAPIServer
KubeAPIServer returns the result to kubectl
The user gets the information from kubectl
Configuring the API Server
link
Doc
OpenId
Requirements
- ldap server
- k8s RBAC enabled
- k8s Api Server enable OpenID Connect
- Dex
- Dex Application
Setup
ldap server is running
-
Dex setup
-
generate secret
./gencert.sh
kubectl get secret dex
kubectl get secret loginapp
copy ssl/dex-ca.pem –> apiserver /etc/kubernetes/[SSL]/dex-ca.pem -
deploy Dex
kubectl create -f dex.yaml
kubectl get pods –show-lables -l app-dex
kubectl get services dex
Login App setup copy ssl/dex-ca.pem –> ca-cm.yaml
kubectl create -f ca-cm.yaml
kubectl get configmap ca
kubectl create -f loginapp-cm.yaml
kubectl get configmap loginapp
kubectl create -f loginapp-deploy.yml
kubectl get pod –show-labels -l app=loginapp
kubectl get service loginapp
k8s apiserver setup add below parameters to kube-apiserver.yaml, and restart apiserver container(sometimes need to restart docker daemon)
oidc-issuer-url — URL of our OIDC Identity Provider.
oidc-client-id — The unique name for this client, generated by your OIDC provider.
oidc-username-claim — This is sub by default, but sub can vary depending on your OIDC provider, or may not be friendly (e.g. a uuid). Other friendlier claims will have the full oidc-issuer-url prepended to the claim name. The exception for this is the email claim. It is for this reason that I strongly advocate for using email as the oidc-username-claim.
oidc-username-prefix — A string thats inserted in front of the username to both signify that it’s an OIDC user and prevent possible clashing with an account that’s already present. Default is oidc: e.g. oidc:bob@example.com
oidc-groups-claim — The name of the claim to map to groups within Kubernetes.
oidc-groups-prefix — String that is inserted in front of the group name to prevent clashing. Default is oidc: e.g. oidc:/kubernetes-users
oidc-ca-file — Path to the CA certificate that signed the certificate of the Identity Provider
- add RBAC
kubectl create -f rbac-parsec.yml
login website and get ID tokens
https://[hostnameB]:32002/
Request Token
Skip to https://[hostnameA]:32000/
Input Username and Password(your LDAP)
add the config to ~/.kube/config
result
SAML/OAuth2/OpenID
refer
-
OAuth: OAuth is different than OpenID and SAML in being exclusively for authorization purposes and not for authentication purposes.
-
SAML:Security Assertion Markup Language (SAML) is a product of the OASIS Security Services Technical Committee. Dating from 2001, SAML is an XML-based open standard for exchanging authentication and authorization data between parties.
The SAML specification defines three roles:
The principal, which is typically the user looking to verify his or her identity
The identity provider (idP), which is the entity that is capable of verifying the identity of the end user
The service provider (SP), which is the entity looking to use the identity provider to verify the identity of the end user
- OpenID
The OpenID specification defines three roles:
The end user or the entity that is looking to verify its identity
The relying party (RP), which is the entity looking to verify the identity of the end user
The OpenID provider (OP), which is the entity that registers the OpenID URL and can verify the end user’s identity
Main Purpose
OpenID: Single Sign-On for Consumers
OAuth: API Authorization Between Applications
SAML: Single Sign-On for Enterprise Users