OpenID Connect with Pinniped and Keycloak

OpenID Connect (OIDC) allows us to use an Identity Manager Provider (IDP) with our Kubernetes cluster. Keycloak will act as the IDP alongside the Active Directory and Pinniped will provide kubernetes the ability to use the Active Directory users for role assignment.

The following article goes over Pinniped installation and configuration, keycloack should be installed by the Domain admins. Pinniped is an authentication service for Kubernetes clusters. The Pinniped Supervisor should be installed once per environment and Pinniped Concierge on every Kubernetes Cluster that requires the use of authentication services. The Pinniped CLI needs to be installed on every jump server.

Please install kapp on your jump server before proceeding from Carvel

Pinniped Supervisor

Install the Pinniped Supervisor with default options using kapp

Login to the kubernetes cluster and run the following command:

kapp deploy --app pinniped-supervisor --file https://get.pinniped.dev/v0.12.0/install-pinniped-supervisor.yaml

Configure the Pinniped Supervisor as an OIDC issuer

Expose the Supervisor app as a service

The Supervisor app’s endpoint should be exposed as HTTPS endpoint with proper TLS certificate signed by certificate authority (CA) which is trusted by your user’s web browsers. The following command will create a self-signed certificate. Please change the options according to the specific environment. 

openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 900 –nodes -subj "/C=US/ST=Florida /L=Miami/O=YourOrg/OU=ITDepartment/CN=oidc.k8s.yourdomain.lo.cal" -addext "subjectAltName = DNS:oidc.k8s.yourdomain.local"

Create a secret file with the pem files supplied by the openssl ran in the previous step

kubectl create secret tls pinneped-supervisor-default-tls-certificate -n pinniped-supervisor --cert=/path/to/pem/cert.pem --key=/path/to/pem/key.pem

Install contour for HttpProxy

run the command

kubectl apply -f https://projectcontour.io/quickstart/contour.yaml

Verify the Contour pods are ready by running the following

kubectl get pods -n contourproject -o wide

Create ClusterIP service for the Pinniped Supervisor pods. Save the following YAML and apply it:

kubectl apply -f pinniped-supervisor-clusterip.yaml

pinniped-supervisor-clusterip.yaml

apiVersion: v1
kind: Service
metadata:
name: pinniped-supervisor-clusterip
# Assuming that this is the namespace where the supervisor was installed. This is the default in install-
supervisor.yaml.
namespace: pinniped-supervisor
spec:
type: ClusterIP
selector:
# Assuming that this is how the supervisor pods are labeled. This is the default in install-supervisor.yaml.
app: pinniped-supervisor
ports:

  • protocol: TCP
    port: 8080
    targetPort: 8080

Save and apply the following YAML to create HTTPProxy :

kubectl apply -f httpProxy.yaml

httpProxy.yaml

apiVersion: projectcontour.io/v1
kind: HTTPProxy
metadata:
name: pinniped-http-proxy
namespace: pinniped-supervisor
spec:
virtualhost:
fqdn: oidc.yourdomain.lo.cal
tls:
secretName: pinneped-supervisor-default-tls-certificate
routes:
– conditions:
– prefix: /
services:
– name: pinniped-supervisor-clusterip
port: 8080

Create a Federation Domain for Pinniped Supervisor

pinniped-FederationDomains.yaml
apiVersion: config.supervisor.pinniped.dev/v1alpha1
kind: FederationDomain
metadata:
name: my-provider
# Assuming that this is the namespace where the supervisor was installed. This is the default in install-
supervisor.yaml.
namespace: pinniped-supervisor
spec:
# The hostname would typically match the DNS name of the public ingress or load balancer for the cluster.
# Any path can be specified, which allows a single hostname to have multiple different issuers. The path is op
tional.
issuer: https://oidc.k8s.yourdomain.lo.cal/oidc
# Optionally configure the name of a Secret in the same namespace, of type kubernetes.io/tls,
# which contains the TLS serving certificate for the HTTPS endpoints served by this OIDC Provider.
tls:
secretName: pinneped-supervisor-default-tls-certificate


Contact the Domain Admin with the following details and ask for OIDC Issuer URL, Client-ID and Client-secret.

sign-in redirect uris: https://oidc.k8s.yourdomain.lo.cal/oidc/callback

Download the certificate from the keycloak https site, encode to Base64, add to the following YAML along with the details provided by the domain admin and apply.

OIDCIdentityProvider-keycloak.yaml

apiVersion: idp.supervisor.pinniped.dev/v1alpha1
kind: OIDCIdentityProvider
metadata:
namespace: pinniped-supervisor
name: keycloak
spec:
issuer: https://keycloak.server.local/auth/realms/REALM_NAME
claims:
username: preferred_username
groups: group-membership
client:
secretName: keycloak-client-credentials
tls:

certificateAuthorityData: LS0tLS1….

apiVersion: v1
kind: Secret
metadata:
namespace: pinniped-supervisor
name: keycloak-client-credentials
type: secrets.pinniped.dev/oidc-client
stringData:
# The “Client ID” that you got from the domain admin.
clientID: “ClientID”
# The “Client secret” that you got from the domain admin.
clientSecret: “…”

Next step….
Install and configure Pinniped Concierge

Pinniped Concierge

Install the Pinniped Concierge app
The concierge app should be installed on every Kubernetes Cluster that requires the use of authentication services. Make sure you have installed the kapp binary
Install the latest version of the Concierge into the pinniped-concierge namespace with default options using kapp:kapp deploy –app pinniped-concierge –file https://get.pinniped.dev/v0.12.0/install-pinniped-concierge.yaml

What next?
Configure the Pinniped Concierge to validate JSON Web Tokens (JWT) issued by the Pinniped Supervisor

Pinniped Concierge and JWT

Configure the Pinniped Concierge to validate JSON Web Tokens (JWT) issued by the Pinniped Supervisor
Apply the following YAML. Change the audience object to a unique name and the certificateAuthorityData to the Base64 certificate of the pinniped supervisor server.
my-jwt-authenticator.yaml
apiVersion: authentication.concierge.pinniped.dev/v1alpha1 kind: JWTAuthenticator metadata:
name: my-supervisor-authenticator spec:
# The value of the issuer field should exactly match the issuer # field of your Supervisor’s FederationDomain. issuer: https://oidc.yourdomain.lo.cal/oidc
# You can use any audience identifier for your cluster, but it is # important that it is unique for security reasons. audience: my-unique-cluster-identifier
# If the TLS certificate of your FederationDomain is not signed by
# a standard CA trusted by the Concierge pods by default, then # specify its CA here as a base64-encoded PEM. tls:
certificateAuthorityData: LS0tLS1……………………ROZE

Logging into your cluster using Pinniped

This how-to guide assumes that you have already configured the following Pinniped server-side components within your Kubernetes cluster(s):

  1. If you would like to use the Pinniped Supervisor for federated authentication across multiple Kubernetes clusters then you have already
  2. 1. Installed the Pinniped Supervisor with working ingress.
  3. In each cluster for which you would like to use Pinniped for authentication, you have
  4. 2. installed the Concierge.
  5. In each cluster’s Concierge, you have configured an authenticator. For example, if you are using the Pinniped Supervisor, then you have configured each Concierge to 3. use the Supervisor for authentication.
    Download the pinniped binary to match your jump server’s OS rename to “pinniped” and move it to folder within the PATH
  6. .
    Generate a Pinniped-compatible kubeconfig file

  7. You will need to generate a Pinniped-compatible kubeconfig file for each cluster in which you have installed the Concierge. This requires admin-level access to each cluster so this would typically be performed by the same user who installed the Concierge, For each cluster use
    pinniped get kubeconfig

to generate the new kubeconfig file for that cluster.
You can save the output to a YAML file and send it to users without cluster-admin to replace the default kubeconfig file usually located at $HOME/.kube
pinniped get kubeconfig > pinniped-kubeconfig.yaml
Checking which user is working on the cluster can be done with:
pinniped whoami

Authorization


Pinniped provides authentication (usernames and group memberships) but not authorization. Kubernetes authorization is often provided by the Kubernetes RBAC system on each cluster.
In the example above, if the user gets an access denied error, then they may need authorization to list namespaces. For example, an admin could grant the user “edit” access to all cluster resources via the user’s username:
kubectl create clusterrolebinding my-user-can-edit –clusterrole edit –user my-username@yourdomain.local
Alternatively, an admin could create role bindings based on the group membership of the users in the upstream identity provider, for example:
kubectl create clusterrolebinding my-auditors –clusterrole view –group auditors

Other notes
Temporary session credentials such as ID, access, and refresh tokens are stored in: ~/.config/pinniped/sessions.yaml (Linux)
%USERPROFILE%/.config/pinniped/sessions.yaml (Windows).

KEYCLOAK CONFIGURATION

Create new Client . the Client TYPE should be – OPENID

(copy the Client ID to OIDCIdentityProvider-keycloak.yaml File)

Create Mappers (To includ with the claim – Groups & username)

Copy the Secret to Yaml file(OIDCIdentityProvider-keycloak.yaml) .

GOOD Luck ……

AVI E. , SHMUEL H.

One thought on “OpenID Connect with Pinniped and Keycloak

  1. can you please format your yaml, its all left aligned and has lost significant value

Leave a Reply

Discover more from Rafael IT Blog

Subscribe now to keep reading and get access to the full archive.

Continue reading