Securing your Kubernetes Cluster with SSO
When you are using Kubernetes in your company you are wondering how to secure your Kubernetes Cluster against an unauthorized access of users. Most user of Kubernetes don’t know that the Access Tokens used in Kubeconfig files are stored as secrets within Kubernetes in plain text. To secure these secrets you must block the reading of secrets for your developer. This sound easier as it is in reality, because Kubernetes RBAC does not know deny permissions. Such scenarios like allowing the reading of secrets in the developer project but deny the reading of secretes with the user tokens is complicated und must be organized per Kubernetes namespace.
Users and Groups in Kubernetes
Kubernetes does not know users or groups accounts for the access control of Kubernetes. Mean you cannot store user or group accounts in Kubernetes and use them for the access management. But users and groups can be used in Kubernetes if you are using managed Kubernetes in AWS for example. What AWS or Azure is simply doing is serving a Kubernetes Access Token provided by Kubernetes but based on an SSO-Authentication process with an Identity provider (IdP). An IdP can be for example Keycloak or AWS IAM which holds the group or user accounts.
Securing Kubernetes with SSO
In most of the companies Single sing-on (SSO) is part of the general service to grant the staff access to the internal applications. In a managed Kubernetes like in AWS or Azure the usage of SSO is a build in service of the Identity and Access Management (IAM).
But in self-hosted Kubernetes Cluster and some managed Kubernetes Cluster this service is not available. The connection to an SSO Identity Provider (IdP) based on OAuth2 like Keycloak must be set in the kube-apiserver module of Kubernetes at start up of the Kubernetes Controller Plane (see OpenID Connect Tokens) . This means you must have admin access to the Kubernetes start up itself or the Kubernetes Provider must be able to add your personal IdP for your Kubernetes Cluster. In external managed Kubernetes Cluster this is not generally guaranteed.
Our project: An self-hosted SSO authenticator for Kubernetes
Our customer used one of these managed Kubernetes Clusters which did not provide access to the startup process of Kubernetes and the provider was not able to add the Identity Provider of our customer to the startup process. Nevertheless, they wanted, that all developer in Kubernetes are authenticated via the SSO IdP of the company to simplify and to secure the development process.
We developed a management platform which allows
- the management of the managed Kubernetes Cluster itself,
- the access of the Kubernetes Cluster with an SSO authentication process,
- it shall be a smooth as possible for the Kubernetes developer,
- it shall be usable with kubectl, HELM and LENS the Kubernetes IDE nad
- a daily rotation of the tokens generated to access the Kubernetes Cluster.
Except the input of the name and password, the developer shall do nothing more with a request via kubectl or HELM. No coping of files or adding token to config files. A simplified description of the process you find here:
For that platform we developed in less than four weeks a MVP web application with FLASK and Appbuilder, a Rapid Application Development Framework (RAD) based on Python. This application together with the IdP are organizing the SSO authentication process to provide the needed token to access a Kubernetes Cluster by the user. Additionally, we developed a Kubernetes plugin for requesting and starting the authentication and access process to Kubernetes by the developer. This plugin is easily addable to the device of the developer and immediately usable.
Additoonal management function
In most of the scenarios there are more than one Kubernetes Cluster. We added additional functions so that newly created or removed clusters are handled by the application. We provided a separated de-/registration process so new or removed clusters can be used by the developer without any hassle.
