Platform configuration
This document explains how to configure the platform, including its operational settings and features such as SSO login, custom branding, and auditing.
Understand platform configuration​
The platform is configured through the vcluster-platform
Helm chart, which comes from the loft-sh/loft repository. The default configuration values can be found in the chart's values.yaml file.
Types of platform configuration​
The platform's values.yaml
file contains multiple configuration sections:
- Installation settings - Control how the platform is deployed
- Top-level fields in the
vcluster-platform
chart'svalues.yaml
- Located in the platform Helm chart (loft-sh/loft)
- Examples:
replicaCount
,resources
,ingress
,persistence
, etc. - These configure Kubernetes deployment aspects like resources and replicas
- Top-level fields in the
- Operational settings - Control how the platform functions after deployment
- These are grouped under the
config:
section of thevcluster-platform
chart - Located in the platform Helm chart (loft-sh/loft)
- Examples:
config.auth
,config.audit
,config.loftHost
- Can also be managed through the UI in Admin > Config
- These are grouped under the
- Agent settings - Control how the platform agent operates in connected clusters
- Set through the top-level
agentValues:
section of thevcluster-platform
chart - Located in the platform Helm chart (loft-sh/loft)
- Can be overridden per-cluster with annotations
- Set through the top-level
Difference between values.yaml and config section​
When configuring the platform, it's important to understand the difference between the main values.yaml
settings and the config
section inside it:
- values.yaml (installation settings) - Controls how the platform itself is installed
- Affects the Kubernetes resources created during installation
- Examples: replica count, resource limits, persistence settings, ingress configuration
- These options are typically set once during deployment
- Not accessible through the UI after installation
- Requires a Helm upgrade to change after initial deployment
- config section - Controls what the platform does after installation
- Located in the
vcluster-platform
chart'svalues.yaml
as theconfig:
key - Defined in loft-sh/loft/chart/values.yaml
- Stores settings in a dedicated Kubernetes resource that persists across platform upgrades
- Contains settings that the platform reads and applies at runtime
- Affects the platform's behavior, features, and integrations
- Examples: authentication options, audit settings, UI customization
- Can be changed any time through the UI in Admin > Config
- Changes are detected and applied without requiring a restart or redeployment
- Located in the
Common configuration tasks​
For common tasks, here's which part to configure:
Task | Configuration location | Example |
---|---|---|
Setting admin credentials | admin: section (top-level) | admin.username , admin.password |
Configuring replicas for HA | replicaCount: (top-level) | replicaCount: 2 |
Setting up ingress | ingress: section (top-level) | ingress.enabled: true |
Configuring auth providers | config.auth: section | config.auth.github |
Setting custom domain | config: section | config.loftHost |
Resource limits | resources: section (top-level) | resources.limits.memory |
Platform configuration example​
Here's an example of a platform values.yaml
file showing all these configuration sections:
# Installation settings (top-level)
replicaCount: 2
resources:
requests:
memory: 512Mi
cpu: 400m
# Admin user settings (top-level)
admin:
create: true
username: my-admin-user
password: my-secure-password
# Ingress configuration (top-level)
ingress:
enabled: true
host: platform.example.com
# Agent settings (top-level)
agentValues:
resources:
requests:
memory: 256Mi
# Operational settings (inside config section)
config:
loftHost: platform.example.com
audit:
enabled: true
auth:
github:
clientId: $CLIENT_ID
Apply configuration​
The platform configuration can be applied in two ways:
- Through
helm
values when installing or upgrading the platform - Through the UI in Admin > Config after installation (operational settings only)
Using helm
values allows you to manage configuration declaratively and enables deployment through GitOps solutions such as ArgoCD.
Here's an example of applying platform configuration with helm
:
RELEASE_NAME=vcluster-platform
RELEASE_NAMESPACE=vcluster-platform
PLATFORM_VERSION='' # Set this to a specific version or leave empty for latest
helm upgrade $RELEASE_NAME vcluster-platform \
--install \
--repo https://charts.loft.sh/ \
--namespace $RELEASE_NAMESPACE \
--create-namespace \
--values values.yaml \
${PLATFORM_VERSION:+--version $PLATFORM_VERSION}
Set a custom domain​
A critical configuration setting is the loftHost
variable, which defines the domain where users access the platform.
When to set this value​
Set the loftHost
value after:
- Installing the platform
- Configuring TLS certificates
- Setting up ingress with a custom domain
What to set​
The loftHost
value should be:
- The same hostname specified in your ingress resource
- Only the hostname (e.g.,
platform.example.com
) - Not contain protocols (e.g., no
https://
) - Not contain subpaths (e.g., no
/platform
)
config:
loftHost: platform.example.com
After changing the domain​
After updating the loftHost
value, you must reconnect all clusters to the platform by running the same connection commands in each Kubernetes context. See connecting clusters for detailed instructions.
Clusters must also be reconnected if you change the additionalCA
or insecureSkipVerify
values after the initial setup.
Manage sensitive information​
Many configuration options require sensitive information such as API keys or tokens. Rather than storing these directly in your values.yaml
file, you can use environment variable placeholders.
Use secret references​
To securely provide sensitive information, store it in a Kubernetes secret and reference it in your configuration:
# Secret references
envValueFrom:
CLIENT_ID:
secretKeyRef:
name: github-auth-secret
key: client_id
CLIENT_SECRET:
secretKeyRef:
name: github-auth-secret
key: client_secret
# Platform configuration
config:
auth:
github:
clientId: $CLIENT_ID
clientSecret: $CLIENT_SECRET
redirectURI: https://my-platform.example.com/auth/github/callback
Custom HTTP headers​
You can configure the platform to add custom HTTP headers to all API responses. This is useful for security-related headers or when integrating with specific environments.
config:
auth:
customHttpHeaders:
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
Content-Security-Policy: default-src 'self'
Certificate management​
Use a custom certificate authority​
If you want all virtual clusters to trust a specific certificate authority when communicating with the platform, you can configure it centrally rather than in each individual virtual cluster.
Before setting a custom certificate authority, you must configure TLS for the platform.
# Base64-encoded CA certificate - top-level setting, not inside config:
additionalCA: "(base64 encoded CA)"
Import existing virtual clusters with certificate validation​
When importing externally managed virtual clusters, you can enable secure communication by using the same certificate authority:
- Get the current certificate authority from your platform:
helm get values --namespace $RELEASE_NAMESPACE $RELEASE_NAME --all | grep additionalCA
- Import the virtual cluster with certificate validation:
vcluster platform add vcluster <VCLUSTER_NAME> \
--namespace=<VCLUSTER_NAMESPACE> \
--project=<PROJECT_NAME> \
--ca-data <BASE64_CA_VALUE>
The imported virtual cluster restarts and report Ready
once it establishes a secure connection to the platform.
The platform agent​
What is the platform agent?​
The platform agent is a component that runs in each connected Kubernetes cluster. It handles:
- Cluster resource management
- Communication with the platform
- Reconciliation of cluster-scoped resources
Every cluster connected to the platform, including the cluster where the platform itself runs, must have the platform agent installed.
Default agent deployment​
By default, the platform automatically installs the agent in:
- The cluster where the platform is deployed
- Any new clusters connected to the platform
Disable automatic agent deployment​
In some environments, particularly those using GitOps tools, you might want to manage agent deployment manually. There are two ways to disable automatic agent deployment:
- Platform-wide - Disable for all clusters:
# Not inside config: section - this is a top-level setting
env:
DISABLE_AGENT: true
- Per-cluster - Disable for specific clusters by setting the
loft.sh/cluster-ignore-agent
annotation totrue
on the Cluster resource.
Even if you disable automatic deployment, the platform agent is still required in every connected cluster. You must deploy it manually or through GitOps tools.
Manual agent installation​
To manually install the platform agent:
RELEASE_NAME=vcluster-platform
RELEASE_NAMESPACE=vcluster-platform
PLATFORM_VERSION='' # Set this to a specific version or leave empty for latest
helm upgrade $RELEASE_NAME vcluster-platform \
--install \
--repo https://charts.loft.sh/ \
--namespace $RELEASE_NAMESPACE \
--create-namespace \
--set agentOnly=true \
${PLATFORM_VERSION:+--version $PLATFORM_VERSION}
Agent configuration​
Understand agent values​
The platform agent uses its own set of configuration values, which can be specified in several ways:
- Default behavior: By default, the agent inherits values from the platform configuration
- Global agent values: The
agentValues:
section in the platformvalues.yaml
specifies default values for all agents - Cluster-specific values: The
loft.sh/agent-values
annotation on a Cluster resource overrides global values for that specific cluster
When the platform upgrades an agent, it uses the values from the agentValues
section (or from the cluster annotation if present).
Configure the agent through the platform​
To customize the agent configuration when it's deployed by the platform, use the agentValues
section in your platform configuration:
# Agent-specific configuration - top-level setting, not in config: section
agentValues:
# Configure security context for the agent
securityContext:
enabled: true
# Set resource limits for the agent
resources:
limits:
cpu: 500m
memory: 512Mi
requests:
cpu: 100m
memory: 128Mi
Cluster-specific agent configuration​
To apply different configuration to the agent in specific clusters, set the loft.sh/agent-values
annotation on the Cluster resource. These values override any settings from the platform's agentValues
.
Configuration reference​
For a complete reference of all platform configuration options under the config:
section, see below:
auth
required object pro​
Authentication holds the information for authentication
auth
required object pro​oidc
required object pro​
OIDC holds oidc authentication configuration
oidc
required object pro​issuerUrl
required string pro​
IssuerURL is the URL the provider signs ID Tokens as. This will be the "iss"
field of all tokens produced by the provider and is used for configuration
discovery.
The URL is usually the provider's URL without a path, for example
"https://accounts.google.com" or "https://login.salesforce.com".
The provider must implement configuration discovery.
See: https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfig
issuerUrl
required string pro​clientId
required string pro​
ClientID the JWT must be issued for, the "sub" field. This plugin only trusts a single
client to ensure the plugin can be used with public providers.
The plugin supports the "authorized party" OpenID Connect claim, which allows
specialized providers to issue tokens to a client for a different client.
See: https://openid.net/specs/openid-connect-core-1_0.html#IDToken
clientId
required string pro​clientSecret
required string pro​
ClientSecret to issue tokens from the OIDC provider
clientSecret
required string pro​redirectURI
required string pro​
loft redirect uri. E.g. https://loft.my.domain/auth/oidc/callback
redirectURI
required string pro​postLogoutRedirectURI
required string pro​
Loft URI to be redirected to after successful logout by OIDC Provider
postLogoutRedirectURI
required string pro​caFile
required string pro​
Path to a PEM encoded root certificate of the provider. Optional
caFile
required string pro​insecureCa
required boolean pro​
Specify whether to communicate without validating SSL certificates
insecureCa
required boolean pro​preferredUsername
required string pro​
Configurable key which contains the preferred username claims
preferredUsername
required string pro​loftUsernameClaim
required string pro​
LoftUsernameClaim is the JWT field to use as the user's username.
loftUsernameClaim
required string pro​usernameClaim
required string pro​
UsernameClaim is the JWT field to use as the user's id.
usernameClaim
required string pro​emailClaim
required string pro​
EmailClaim is the JWT field to use as the user's email.
emailClaim
required string pro​usernamePrefix
required string pro​
UsernamePrefix, if specified, causes claims mapping to username to be prefix with
the provided value. A value "oidc:" would result in usernames like "oidc:john".
usernamePrefix
required string pro​groupsClaim
required string pro​
GroupsClaim, if specified, causes the OIDCAuthenticator to try to populate the user's
groups with an ID Token field. If the GroupsClaim field is present in an ID Token the value
must be a string or list of strings.
groupsClaim
required string pro​groups
required string[] pro​
If required groups is non empty, access is denied if the user is not part of at least one
of the specified groups.
groups
required string[] pro​scopes
required string[] pro​
Scopes that should be sent to the server. If empty, defaults to "email" and "profile".
scopes
required string[] pro​getUserInfo
required boolean pro​
GetUserInfo, if specified, tells the OIDCAuthenticator to try to populate the user's
information from the UserInfo.
getUserInfo
required boolean pro​groupsPrefix
required string pro​
GroupsPrefix, if specified, causes claims mapping to group names to be prefixed with the
value. A value "oidc:" would result in groups like "oidc:engineering" and "oidc:marketing".
groupsPrefix
required string pro​type
required string pro​
Type of the OIDC to show in the UI. Only for displaying purposes
type
required string pro​github
required object pro​
Github holds github authentication configuration
github
required object pro​clientId
required string pro​
ClientID holds the github client id
clientId
required string pro​clientSecret
required string pro​
ClientID holds the github client secret
clientSecret
required string pro​redirectURI
required string pro​
RedirectURI holds the redirect URI. Should be https://loft.domain.tld/auth/github/callback
redirectURI
required string pro​orgs
required object[] pro​
Loft queries the following organizations for group information.
Group claims are formatted as "(org):(team)".
For example if a user is part of the "engineering" team of the "coreos"
org, the group claim would include "coreos:engineering".
If orgs are specified in the config then user MUST be a member of at least one of the specified orgs to
authenticate with loft.
orgs
required object[] pro​name
required string pro​
Organization name in github (not slug, full name). Only users in this github
organization can authenticate.
name
required string pro​teams
required string[] pro​
Names of teams in a github organization. A user will be able to
authenticate if they are members of at least one of these teams. Users
in the organization can authenticate if this field is omitted from the
config file.
teams
required string[] pro​hostName
required string pro​
Required ONLY for GitHub Enterprise.
This is the Hostname of the GitHub Enterprise account listed on the
management console. Ensure this domain is routable on your network.
hostName
required string pro​rootCA
required string pro​
ONLY for GitHub Enterprise. Optional field.
Used to support self-signed or untrusted CA root certificates.
rootCA
required string pro​gitlab
required object pro​
Gitlab holds gitlab authentication configuration
gitlab
required object pro​