Deploying in K8s with non-native Auth Servers

December 5, 2025 ยท View on GitHub

AIS uses JWT to validate requests, as described in the AIS auth validation documentation.

These tokens can be generated by the AIS AuthN service or by other 3rd party issuers.

In this doc we'll demonstrate how to deploy a local K8s cluster with Keycloak, AIS operator, and AIStore.

Deploy Keycloak

Keycloak is a full-featured, open source, CNCF incubating project with a wide range of installation options and environments. We provide a basic set of instructions and automation for setting up the prerequisites and installing a simple keycloak deployment. This also includes a development AIS realm with a basic cluster admin user.

Follow the instructions linked here to get started with Keycloak.

Create Namespaces for AIS

Our charts do this automatically, but this is needed before creating additional resources below:

kubectl create ns ais
kubectl create ns ais-operator-system
kubectl label namespace ais ais-trust=true
kubectl label namespace ais-operator-system ais-trust=true

Create an Admin Secret

The AIS operator must be able to request an admin token for controlling the AIS cluster. Apply this manifest to create this secret with provided AIS admin credentials for the development realm. Here we do it with envsubst to template the values

export SU_NAME="ais-admin"
export SU_PASS="12345"
envsubst < ../auth/keycloak/manifests/admin-secret.template.yaml | kubectl apply -f -

Trust Manager

The above deployment installs trust-manager but we still need to make a trust bundle for the issuer's self-signed certificate.

Apply the trust-bundle manifest to create ConfigMaps with a CA certificate the operator and AIS can use to verify.

kubectl apply -f ../auth/keycloak/manifests/trust-bundle.yaml

Deploy Operator

Deploy the operator with the keycloak environment values to use the K8s ConfigMaps and Secret created above:

helmfile sync -f ../helm/operator/helmfile.yaml -e keycloak

This config has two custom options for this deployment. In this case, both are the same because we're using a common Issuer and trust bundle for both AIS and Keycloak certificates:

  • authCAConfigmapName: aistore.nvidia.com -- Defines the ConfigMap with the trust bundle for the Keycloak CA, used when requesting an admin token for the operator
  • aisCAConfigmapName: aistore.nvidia.com -- Defines the ConfigMap with the trust bundle for AIStore, used when the operator makes API calls to the AIS cluster

Deploy AIS

First, label nodes where AIS targets should be deployed: ../helm/ais/scripts/label-nodes.sh ais --all

Deploy the AIS cluster with the keycloak environment values.

helmfile sync -f ../helm/ais/helmfile.yaml -e keycloak

This defines the following in the AIS spec:

  • Issuers the AIS cluster allows (local Keycloak deployment)
  • ConfigMap for loading the issuer's CA certificate (trust bundle of the certificate issuer)
  • Login info the AIS operator should use to provision a token for admin access to this cluster.