How to install Sveltos dashboard
Video
To learn more about the Sveltos Dashboard, check out the Sveltos Dashboard Introduction Youtube Video and Features and Debugging with Sveltos. If you find this valuable, we would be thrilled if you shared it! 😊
Introduction to Sveltos Dashboard
The Sveltos Dashboard is not part of the generic Sveltos installation. It is a manifest file that will get deployed on top. If you have not installed Sveltos, check out the documentation here.
Manifest Installation
To deploy the Sveltos Dashboard, run the below command using the kubectl utility.
$ kubectl apply -f https://raw.githubusercontent.com/projectsveltos/sveltos/main/manifest/dashboard-manifest.yaml
Helm Installation
$ helm install sveltos-dashboard projectsveltos/sveltos-dashboard -n projectsveltos
$ helm list -n projectsveltos
Warning
v0.38.4 is the first Sveltos release that includes the dashboard and it is compatible with Kubernetes v1.28.0 and higher.
To access the dashboard, expose the dashboard service in the projectsveltos namespace. The deployment, by default, is configured as a ClusterIP service. To expose the service externally, we can edit it to either a LoadBalancer service or use an Ingress/Gateway API.
Authentication
The Sveltos Dashboard supports two authentication methods: manual token authentication (default) and OIDC authentication. The active method is determined at deploy time by the Helm values provided.
Manual Token Authentication
To authenticate with the Sveltos Dashboard, we will utilise a serviceAccount, a ClusterRoleBinding/RoleBinding and a token.
Let's create a service account in the desired namespace.
Let's provide the service account permissions to access the managed clusters in the management cluster.
$ kubectl create clusterrolebinding <binding_name> --clusterrole <role_name> --serviceaccount <namespace>:<service_account>
| Argument | Description |
|---|---|
binding_name |
It is a descriptive name for the rolebinding. |
role_name |
It is one of the default cluster roles (or a custom cluster role) specifying permissions (i.e., which managed clusters this serviceAccount can see). |
namespace |
It is the service account's namespace. |
service_account |
It is the service account that the permissions are being associated with. |
Platform Administrator Example
$ kubectl create sa platform-admin -n default
$ kubectl create clusterrolebinding platform-admin-access --clusterrole cluster-admin --serviceaccount default:platform-admin
Create a login token for the service account with the name platform-admin in the default namespace. The token will be valid for 24 hours.1
Copy the token generated, login to the Sveltos Dashboard and submit it.
OIDC Authentication
The dashboard supports OIDC authentication using the Authorization Code Flow with PKCE (public client). When enabled, the login page will show the OIDC login option instead of the manual token form.
Setting up OIDC requires three steps: configuring the dashboard, configuring the Kubernetes API server, and setting up RBAC for your dashboard users.
1. Configure the Dashboard
OIDC is enabled by providing the following Helm values at install time:
| Helm Value | Description | Default |
|---|---|---|
auth.oidc.issuer |
Issuer URL of your OIDC provider | — |
auth.oidc.clientId |
Client ID registered with your OIDC provider | — |
auth.oidc.redirectUri |
Full redirect URI after OIDC login | <origin>/oidc-callback |
$ helm install sveltos-dashboard projectsveltos/sveltos-dashboard -n projectsveltos \
--set auth.oidc.issuer=https://k8s-oidc-domain.example.com/auth/realms/k8s-oidc \
--set auth.oidc.clientId=k8s-oidc-client \
--set auth.oidc.redirectUri=https://dashboard.example.com/oidc-callback
Make sure that the client exists, it is configured as a public client (no client secret), and the redirect URI is registered in the OIDC provider.
If auth.oidc.issuer and auth.oidc.clientId are not set, the dashboard falls back to manual token authentication.
2. Configure the Kubernetes API Server
The Kubernetes API server must be configured to accept and validate OIDC tokens. The required and optional flags are documented here.
Here is an example of configuring OIDC in a k3d cluster, for demo/test purposes:
k3d cluster create oidc-test --k3s-arg "--kube-apiserver-arg=oidc-issuer-url=https://k8s-oidc-domain.example.com/auth/realms/k8s-oidc@server:*" --k3s-arg "--kube-apiserver-arg=oidc-client-id=k8s-oidc-client@server:*" --k3s-arg "--kube-apiserver-arg=oidc-username-claim=preferred_username@server:*"
In this example, we use the --oidc-username-claim parameter to let the API server use the preferred_username claim from the OIDC token as the username.
3. Configure RBAC for OIDC Users
The API server maps the username claim from the OIDC token to RBAC subjects. The subject name may include the issuer URL to avoid name clashes, based on the API server OIDC configuration. Refer to the Kubernetes documentation for details on prefixing behaviour.
The following example grants cluster-admin to the OIDC user test:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: k8s-oidc-dashboard-admin
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: User
name: https://k8s-oidc-domain.example.com/auth/realms/k8s-oidc#test
Note that subjects.name includes the OIDC issuer URL prefix followed by the username claim value.
Note
In production, avoid granting admin level grants to the dashboard users.
4. Logging In
Once all three steps are complete, the dashboard login page will display the OIDC login option. Clicking it redirects the user to the OIDC provider. After a successful sign-in, the provider redirects back to the configured redirect URI, and the user is taken to the dashboard.
-
While the example uses cluster-admin for simplicity, the dashboard only requires read access to Sveltos CRs and Cluster API cluster instances. ↩