vCluster Platform Configuration
The vCluster Platform config allows you to modify vCluster Platform's behaviour and enable or disable certain features, such as SSO login, custom branding, or auditing.
Changing vCluster Platform Config
vCluster Platform config can be applied directly via helm values or through the vCluster Platform UI in Admin
> Config
. Using helm values allows you to declaratively deploy vCluster Platform.
When using helm you can apply the vCluster Platform config via a vcluster.yaml
file. This also makes it possible to deploy vCluster Platform through GitOps solutions such as ArgoCD. An example vCluster Platform vcluster.yaml
could look like this:
config:
loftHost: my-vcluster-host.com
audit:
enabled: true
auth:
github:
clientId: $CLIENT_ID
clientSecret: $CLIENT_SECRET
redirectURI: https://my-vcluster-host.com/auth/github/callback
For a complete overview what helm values are possible, please take a look at the Loft github repository directly.
Changing the Loft Host variable
After setting up the platform and TLS certificates and configuring the ingress to use a custom domain, one should change the loftHost
variable shown above.
Initially, that value will be set to the URL of either the Loft Router domain or no domain in the case of air-gapped setups.
This value should be equal to the hostname specified in the ingress resource for accessing the platform.
This value of the loftHost
variable should only be the hostname that vCluster Platform is reachable at and not contain protocols (such as HTTP) or subpaths.
After changing the loftHost
, all currently connected clusters must be redeployed by running the same connection commands in the corresponding Kubernetes context.
See the instructions on connecting Clusters for more guidance.
Clusters will also have to be reconnected if the additionalCA
or insecureSkipVerify
values are changed after the initial setup.
Sensitive Information in the vCluster Platform Config
Some fields within the vCluster Platform config allow placeholders for environment variables, such as the clientId
and clientSecret
fields. This makes it possible to not expose the sensitive information directly inside the vCluster Platform values and instead mount this information into vCluster Platform through an external secret.
To load the github clientId and clientSecret through a Kubernetes secret my-secret
, use the following configuration:
envValueFrom:
CLIENT_ID:
secretKeyRef:
name: my-secret
key: client_id
CLIENT_SECRET:
secretKeyRef:
name: my-secret
key: client_secret
config:
auth:
github:
clientId: $CLIENT_ID
clientSecret: $CLIENT_SECRET
redirectURI: https://my-vcluster-platform-host.com/auth/github/callback
Then use helm to apply this configuration and update $PLATFORM_VERSION
with a valid vCluster Platform version.
helm upgrade loft vcluster-platform --install \
--repo https://charts.loft.sh/ \
--namespace vcluster-platform \
--create-namespace \
--values values.yaml \
--version $PLATFORM_VERSION
Custom HTTP Headers
vCluster Platform allows you to add custom HTTP headers to all requests that are sent to the vCluster Platform API. This can be useful if you want to add custom headers to all requests, such as X-Frame-Options
or X-XSS-Protection
.
To add custom HTTP headers, use the following configuration:
config:
auth:
customHttpHeaders:
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
Setting additional certificate authority for Platform
If you want to have all your virtual clusters managed by the vCluster Platform to use a specific certificate authority to establish the connection between the virtual cluster and the platform, you can set it as a configuration option on the vCluster Platform instead of configuring it on each individual virtual cluster. This will enable secure communication between your Virtual Clusters and the vCluster Platform. As a pre-requisite, you have to configure TLS for the vCluster Platform first.
additionalCA: "(base64 encoded CA)"
Also, if you need to import externally managed vCluster to the vCluster Platform, you can also enable a secure connection by grabbing the value from the existing vCluster Platform, you can do this by running:
helm get values --namespace [namespace where vCluster Platform is deployed] [loft helm release name] --all | grep additionalCA
Using the additionalCA
value from the above command, import the vCluster using the following vCluster CLI command:
vcluster platform add vcluster <VCLUSTER_NAME> \
--namespace=<VCLUSTER_NAMESPACE> \
--project=<PROJECT_NAME> \
--ca-data [base64 string grabbed from the command above]
Once the command succeeds, the imported vCluster pod restarts and reports Ready
.
The vCluster Platform Agent
Every connected cluster in a vCluster Platform environment, including the "main" cluster that vCluster Platform is deployed in, must have a vCluster Platform Agent deployed. This agent pod handles reconciliation of cluster scoped (as in not vCluster Platform instance wide) resources.
By default, when vCluster Platform is installed, the vCluster Platform pod will also install the vCluster Platform Agent into the
cluster you are deploying vCluster Platform into. This is usually a desirable behavior since vCluster Platform requires
the Agent to be present in all clusters. Sometimes, however, admins wish to manage the
installation of the vCluster Platform Agent themselves, either by installing it explicitly, or by installing
it via GitOps tooling. In this situation, it is possible to disable the Agent deployment by
setting the DISABLE_AGENT
environment variable to "true". This can be accomplished in the
env
section of the vCluster Platform values:
env:
DISABLE_AGENT: true
It is also possible to tell vCluster Platform not to install Agents into individual clusters -- this can be
accomplished by setting the loft.sh/cluster-ignore-agent
Annotation of the Cluster resource to
"true" for any clusters that vCluster Platform should not manage the Agent deployment on.
The vCluster Platform Agent is required for every connected cluster in a vCluster Platform deployment, this includes the cluster vCluster Platform itself is deployed into. If you are disabling the agent deployment via one of the mechanism described above, make sure you are still getting an Agent installed into every connected cluster by some other means.
If you are electing to manage the Agent installation yourself, you can install the Agent
directly using Helm. Update $PLATFORM_VERSION
with a valid vCluster Platform version.
helm upgrade vcluster-platform vcluster-platform --install \
--repo https://charts.loft.sh/ \
--namespace vcluster-platform \
--create-namespace \
--set agentOnly=true \
--version $PLATFORM_VERSION
vCluster Platform Agent Values
As with the primary vCluster Platform chart, the vCluster Platform Agent chart exposes values that can be configured by an administrator to suit their needs. As with the primary vCluster Platform deployment, the Agent chart and values can be seen in the public repository here.
If you have deployed vCluster Platform with the default behavior of not disabling the Agent deployment, you
can still provide values to influence the deployment of the Agent itself. This can be
accomplished by providing any valid Agent values in the agentValues
section of the vCluster Platform
chart values. These values are received by the vCluster Platform deployment and used when deploying the Agent
pods. Below is an example of the vCluster Platform values agentValues
section.
agentValues:
securityContext:
enabled: true
Administrators can also provide Agent values for specific clusters by setting the loft.sh/agent-values
Annotation of a specific cluster object. These values will always override any
values provided in the parent vCluster Platform chart.
Config reference
auth
required object pro
Authentication holds the information for authentication
auth
required object prooidc
required object pro
OIDC holds oidc authentication configuration
oidc
required object proissuerUrl
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 proclientId
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 proclientSecret
required string pro
ClientSecret to issue tokens from the OIDC provider
clientSecret
required string proredirectURI
required string pro
loft redirect uri. E.g. https://loft.my.domain/auth/oidc/callback
redirectURI
required string propostLogoutRedirectURI
required string pro
Loft URI to be redirected to after successful logout by OIDC Provider
postLogoutRedirectURI
required string procaFile
required string pro
Path to a PEM encoded root certificate of the provider. Optional
caFile
required string proinsecureCa
required boolean pro
Specify whether to communicate without validating SSL certificates
insecureCa
required boolean propreferredUsername
required string pro
Configurable key which contains the preferred username claims
preferredUsername
required string proloftUsernameClaim
required string pro
LoftUsernameClaim is the JWT field to use as the user's username.
loftUsernameClaim
required string prousernameClaim
required string pro
UsernameClaim is the JWT field to use as the user's id.
usernameClaim
required string proemailClaim
required string pro
EmailClaim is the JWT field to use as the user's email.
emailClaim
required string prousernamePrefix
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 progroupsClaim
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 progroups
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[] proscopes
required string[] pro
Scopes that should be sent to the server. If empty, defaults to "email" and "profile".
scopes
required string[] progetUserInfo
required boolean pro
GetUserInfo, if specified, tells the OIDCAuthenticator to try to populate the user's
information from the UserInfo.
getUserInfo
required boolean progroupsPrefix
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 protype
required string pro
Type of the OIDC to show in the UI. Only for displaying purposes
type
required string progithub
required object pro
Github holds github authentication configuration
github
required object proclientId
required string pro
ClientID holds the github client id
clientId
required string proclientSecret
required string pro
ClientID holds the github client secret
clientSecret
required string proredirectURI
required string pro
RedirectURI holds the redirect URI. Should be https://loft.domain.tld/auth/github/callback
redirectURI
required string proorgs
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[] proname
required string pro
Organization name in github (not slug, full name). Only users in this github
organization can authenticate.
name
required string proteams
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[] prohostName
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 prorootCA
required string pro
ONLY for GitHub Enterprise. Optional field.
Used to support self-signed or untrusted CA root certificates.
rootCA
required string progitlab
required object pro
Gitlab holds gitlab authentication configuration
gitlab
required object proclientId
required string pro
Gitlab client id
clientId
required string proclientSecret
required string pro
Gitlab client secret
clientSecret
required string proredirectURI
required string pro
Redirect URI
redirectURI
required string probaseURL
required string pro
BaseURL is optional, default = https://gitlab.com
baseURL
required string progroups
required string[] pro
Optional groups whitelist, communicated through the "groups" scope.
If groups
is omitted, all of the user's GitLab groups are returned.
If groups
is provided, this acts as a whitelist - only the user's GitLab groups that are in the configured groups
below will go into the groups claim. Conversely, if the user is not in any of the configured groups
, the user will not be authenticated.
groups
required string[] progroups
is omitted, all of the user's GitLab groups are returned.
If groups
is provided, this acts as a whitelist - only the user's GitLab groups that are in the configured groups
below will go into the groups claim. Conversely, if the user is not in any of the configured groups
, the user will not be authenticated.google
required object pro
Google holds google authentication configuration
google
required object proclientId
required string pro
Google client id
clientId
required string proclientSecret
required string pro
Google client secret
clientSecret
required string proredirectURI
required string pro
loft redirect uri. E.g. https://loft.my.domain/auth/google/callback
redirectURI
required string proscopes
required string[] pro
defaults to "profile" and "email"
scopes
required string[] prohostedDomains
required string[] pro
Optional list of whitelisted domains
If this field is nonempty, only users from a listed domain will be allowed to log in
hostedDomains
required string[] progroups
required string[] pro
Optional list of whitelisted groups
If this field is nonempty, only users from a listed group will be allowed to log in
groups
required string[] proserviceAccountFilePath
required string pro
Optional path to service account json
If nonempty, and groups claim is made, will use authentication from file to
check groups with the admin directory api
serviceAccountFilePath
required string proadminEmail
required string pro
Required if ServiceAccountFilePath
The email of a GSuite super user which the service account will impersonate
when listing groups
adminEmail
required string promicrosoft
required object pro
Microsoft holds microsoft authentication configuration
microsoft
required object proclientId
required string pro
Microsoft client id
clientId
required string proclientSecret
required string pro
Microsoft client secret
clientSecret
required string proredirectURI
required string pro
loft redirect uri. Usually https://loft.my.domain/auth/microsoft/callback
redirectURI
required string pro