Kasten K10 by Veeam is a data management platform, purpose-built for Kubernetes. It provides enterprise operations teams an easy-to-use, scalable and secure system for backup/restore, disaster recovery and application mobility of Kubernetes applications. This article shows how Kasten delivers on the “easy-to-use” and “secure” aspects of the product by enabling OpenID connect (OIDC) based authentication with well-known providers such as Okta, Google, Dex, Keycloak and Ping ID to name a few.
Enterprises who have already deployed apps in Kubernetes environments with OIDC based authentication find it useful to deploy Kasten K10 using familiar authentication workflows. Enterprises that are new to OIDC will also find it easy to adopt. In either case, they find the ability to use fine-grained role-based access control appealing when deploying apps such as Kasten K10 with OIDC.
In this post, we’ll cover:
- OpenID connect (OIDC)
- The Authorization Code Flow
- A tutorial for setting up an OIDC provider using an Okta dev account and for setting up K10 with OIDC
OpenID Connect (OIDC)
OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.
The Authorization Code Flow
This diagram below shows the sequence of events when a user accesses Kasten K10’s dashboard. Entities involved in the flow include the browser, Kasten K10’s authentication service and the OIDC provider.
- Every request from the browser reaches Kasten K10’s authentication service. The first request from the browser will arrive without a cookie containing a token in it. The service considers the user as unauthenticated and redirects it to the OIDC provider.
- Kasten K10’s auth service invokes the provider’s /authorize endpoint. The callback URL for Kasten K10’s auth service is https://example.com/k10/auth-svc/v0/oidc/redirect. This is included in the /authorize HTTP request.
- The OIDC provider compares Kasten K10’s callback URL with the one registered with the OIDC provider. Only when they match, the OIDC provider proceeds with the flow and presents a login window.
- If the callback in the request and the callback registered at the provider do not match, the OIDC provider will redirect back to Kasten K10’s auth service with an error indicating that the redirect URL did not match.
- Assuming that they do match, Kasten K10’s auth service uses the “code” returned by the provider while making a request for a JSON Web Token (JWT).
- The OIDC provider then responds with a JWT to Kasten K10’s auth service.
- Kasten K10’s auth service then requests for verification of the token. If verification succeeds, it redirects the user to Kasten K10’s dashboard.
- Subsequent requests from the browser reach Kasten K10’s authentication service with the token in the request. Since this token is valid, the authentication service will not redirect to the OIDC provider anymore. This will continue to happen until the token expires.
Set up the OIDC Provider
This tutorial will require the creation of an Okta developer account. Follow the instructions at Okta Developer for creating an account.
After logging into the developer account and navigating to the “Applications” section, you will see a page like the one below. Click on “Create App Integration.”
Next, select the sign-in method as OIDC – OpenID Connect and the application type as “Web Application” and click “Next.”
The next page will show application settings with default values.
- Set a name for this Application.
- Set the “Sign-in redirect URIs” to http://127.0.0.1:8080/k10/auth-svc/v0/oidc/redirect
- Make sure that the “Authorization code” check box has been enabled.
- In the Assignments section, choose “Allow everyone in your organization to access” for the Controlled Access configuration.
- Click “Save” to create the Application.
After the application has been created, write down the “Client ID” and “Client secret.” These will be used while installing Kasten K10 in the next section.
Set up Kasten K10 with OIDC
Tools that are used in this section include:
- kubectl — Kubernetes client
- Helm v3
To install using Helm, you can find documentation on Kasten K10. Please see the pre-requisite tools that are mentioned above before starting this tutorial.
We use Kasten’s K10 Helm chart to install Kasten K10 on a Kubernetes cluster using Helm v3.
Add K10’s helm repository using the command below:
helm repo add kasten https://charts.kasten.io/
helm repo update
Create a namespace to deploy the Kasten K10 application there:
kubectl create namespace kasten-io
Install Kasten K10 in the kasten-io namespace using the command below.
You will need to change the following fields:
- The provider URL should point to your Okta developer account’s URL – https://<your account>.okta.com/oauth2/default
- The client ID and client secret noted down in the previous section about setting up Okta.
- The remaining fields can be left unchanged.
helm install k10 kasten/k10 --namespace=kasten-io \
--set auth.oidcAuth.enabled=true \
--set auth.oidcAuth.providerURL="https://dev-270657.okta.com/oauth2/default" \
--set auth.oidcAuth.redirectURL="http://127.0.0.1:8080" \
--set auth.oidcAuth.scopes="profile email" \
--set auth.oidcAuth.prompt="select_account" \
--set auth.oidcAuth.clientID="0oa64t6tmtpMTOkZH5d7" \
--set auth.oidcAuth.clientSecret="RCXC9yLY0nrmNOZMmvuJn4Geo6Ld8vnkaHe5ee0f" \
Helm install will create multiple deployments and services, and you can validate the install with the following command:
kubectl get pods -n kasten-io — watch
Once the pods are in running condition, you can access the Kasten K10 dashboard at http://127.0.0.1:8080/k10/#/ after running the following command:
kubectl --namespace kasten-io port-forward service/gateway 8080:8000
When visiting the dashboard for the first time, you will be redirected to the Okta login page like the one seen below.
After logging in successfully with Okta, you will be redirected to the Kasten K10 dashboard as shown below.
On the top right corner, when you click on the username, you will see the whole username and the permissions for this user, which may be “unrestricted” for an admin user or set to “limited access” for non-admin users.
Role Based Access Control (RBAC)
Notice that the username in this tutorial has unrestricted admin access to Kasten K10. These were the commands used to enable administrator access for “firstname.lastname@example.org”
kubectl create clusterrolebinding prod-user-crb --clusterrole=k10-admin --email@example.com
kubectl create rolebinding prod-user-rb --role=k10-ns-admin --firstname.lastname@example.org --namespace=kasten-io
In this tutorial, we covered the steps for setting up an Okta account for OIDC and installation of Kasten K10 with OIDC based authentication.
Since the OIDC Authorization code flow follows a well-known standard, Kasten K10’s OIDC integration works with any OIDC provider.
Onkar Bhat is an Engineering Manager at Kasten by Veeam. His focus has been in the areas of Authentication, Role-based Access Control (RBAC), APIs, Monitoring and Multi-cluster management for the purpose of cloud native data protection. He has previously worked in the areas of data protection, networking and security at Big Switch Networks, NetApp and Cisco Systems. Onkar received his MS in Information Networking from Carnegie Mellon University.