Use Open ID Connect for Kubernetes API server
Vložit
- čas přidán 30. 03. 2018
- One of the most scalable approaches to Kubernetes Authentication has to be OpenID Connect Token. These JWT (Json Web Tokens) are issued by a third party (in our case Keycloak) Token Issuer. Kubernetes can then verify whether the token is valid, without having to query Token Issuer. This is what makes this setup quite decoupled and very scalable.
In this video, you'll learn how to configure the apiserver using a minikube Kubernetes cluster. We're running Keycloak as an Identity Provider outside of the Cluster on our local machine using Docker. This leads us to yet another problem though: How can the Minikube cluster (which is running inside a virtual machine) access the Keycloak instance on the host machine? Learn how we tackle this and other issues in this brand new episode on Kubernetes Authentication. - Věda a technologie
i feel this video is incomplete. keycloak issued id_token (with sub as uuid). but there is no mention in the video the configuration and settings at kubernetes to provide clusterrole / role and clusterrolebinding/rolebinding to provide authorization at the kubernetes for the trusted identity (value of uuid in sub claim)
Just an AMAZING video series. Thanks for sharing.
Amazing, i am beginner and learned actual background of keycloak openid by your this video
I'm doing completely unrelated stuff to Kubernetes but I find this really helpful to understand how OAuth 2 works.
Very much detailed video series.
Thanks for sharing.
Really awesome series, thanks a lot. Also amazed by your shell setup hope you have other videos covering that too
Thanks, there's no dedicated video on the setup yet, but I linked my dotfiles ( github.com/etiennedi/dotfiles ) before in case you want to copy parts of the setup. Which topics would you like to see addressed in a video about the setup?
Amazing video series, very thorough.
Extremely well explained to make it understand
Very nice tutorial, very helpful. Please add about Authorization also
I just have to say thank you, man. the're perfect!
Hi, can you share your tmux theme? That is beautiful!
Thank you for a great video sets. Would be great to hear any advice about some helper/proxy for setting the config for kubectl in case token expiration time is to small.
Thanks for your feedback and your input. I'm not entirely sure I get what you're talking about? Do you mean a tool that will use the refresh_token to update the kubeconfig? Or just getting the token into the kubeconfig in an automated fashion? Or retrieving the token using various OAuth Flows and then setting it? Sounds like an interesting topic, I'd be happy to add a video about it, just let me know what it is exactly that you're interested in.
As it seems for me - some tool which can cache IDP credentials and update kubeconfig. Let me briefly describe case:
Let's assume we have requirement to keep expiration timeout for refresh_token as short as possible(10 mins). I believe in Keycloak it's limited by "SSO Session Idle". So far we have option to set IDP params, tokens in kubeconfig as auth-provider-arg- parameters. And that would work perfectly, tokens would refreshes until user is calling kubectl APIs. Otherwise (idle timeout reached), user should requests new tokens and update kubeconfig. Would be great to have some more friendly way for that.
At 15:48 , after starting minikube, I am stuck at the screen "Booting up control plane ...". Then I get a bunch of errors as follow:
Waiting for the kubelet to boot up the control plane as static Pods from directory "/etc/kubernetes/manifests". This can take up to 4m0s
[kubelet-check] Initial timeout of 40s passed.
Unfortunately, an error has occurred:
timed out waiting for the condition
This error is likely caused by:
- The kubelet is not running
- The kubelet is unhealthy due to a misconfiguration of the node in some way (required cgroups disabled)
If you are on a systemd-powered system, you can try to troubleshoot the error with the following commands:
- 'systemctl status kubelet'
- 'journalctl -xeu kubelet'
Additionally, a control plane component may have crashed or exited when started by the container runtime.
To troubleshoot, list all containers using your preferred container runtimes CLI.
Here is one example how you may list all Kubernetes containers running in docker:
- 'docker ps -a | grep kube | grep -v pause'
Once you have found the failing container, you can inspect its logs with:
- 'docker logs CONTAINERID'
Nice tutorial. Out of curiosity, how does keycloak figure out that it's hit by `10.0.2.2` or `localhost`? Based on what address it's referred as, its response changes which has implications on further interactions with it (the realm base URL changes).
i didn't had this issue when running minikube and docker-toolbox in windows
even from minikube i was able to curl the keycloak with the docker-machine ip
$ minikube ssh
$ curl -k 192.168.99.x:8443/auth/realms/master
Nice channel, nice work, keep it going, suggest a full fledged K8s if was possible in the future even that minikube does the job for now
Thanks, glad you like it :) My experience is more with using and administering kubernetes clusters, not so much with operating them, so that's why I use minikube in the videos. The API is (almost) the same, but I can avoid a lot of the trouble involved with building real production grade clusters.
@@kubucation I support managed production grade clusters in one of those Cloud providers, but I'm from a Windows background shifted my career recently so I am trying to improve since I'm very new to the K8s world
Interesting to know. Going for a managed solution is a good decision, the public cloud clusters are becoming better and better and operating it yourself is not an easy task. Interesting to hear you’re from a Windows background, I was thinking about creating a mini series about “Introduction to bash scripting” Is this something that would help you?
Sure, Bash, Docker and anything that will help operating containers is something I like to see in this channel.
Specially Microsoft still maturing their docker architecture, it's useful to look at the Windows side of things as I see it's being used on production grade solutions as well.
Vielen Dank
When I run minikube using the script start_minikube.sh, I am getting error 'Unknown flag --Authentication.OIDC.CAFile'
I am using Kubernetes version V1.13.3
I'm not sure what version of kubernetes was in use but IIRC the name pattern changed from CamelCase to kebab-case sometime after kubernetes version 1.7 or 1.8 for the parameters ( hyphen-case lisp-case naming for hyphenation is apparently controversial )
replacing your-ip:port
minikube start \
--extra-config=apiserver.oidc-issuer-url=your-ip:port \
--extra-config=apiserver.oidc-username-claim=email \
--extra-config=apiserver.oidc-groups-claim=groups \
--extra-config=apiserver.oidc-client-id="dex-auth" \
YMMV