Rancher Helm Chart Options

This page is a configuration reference for the Rancher Helm chart.

For help choosing a Helm chart version, refer to this page.

For information on enabling experimental features, refer to this page.

Common Options

Advanced Options

Bootstrap Password

When Rancher starts for the first time, a password is randomly generated for the first admin user. When the admin first logs in to Rancher, the UI shows commands that can be used to retrieve the bootstrap password. The admin needs to run those commands and log in with the bootstrap password. Then Rancher gives the admin an opportunity to reset the password.

If you want to use a specific bootstrap password instead of a randomly generated one, provide the password.

--set bootstrapPassword="rancher"

The password, whether provided or generated, will be stored in a Kubernetes secret. After Rancher is installed, the UI will show instructions for how to retrieve the password using kubectl:

kubectl get secret --namespace cattle-system bootstrap-secret -o go-template='{{ .data.bootstrapPassword|base64decode}}{{ "\n" }}'

API Audit Log

Enabling the API Audit Log.

You can collect this log as you would any container log. Enable logging for the System Project on the Rancher server cluster.

--set auditLog.level=1

By default enabling Audit Logging will create a sidecar container in the Rancher pod. This container (rancher-audit-log) will stream the log to stdout. You can collect this log as you would any container log. When using the sidecar as the audit log destination, the hostPath, maxAge, maxBackups, and maxSize options do not apply. It’s advised to use your OS or Docker daemon’s log rotation features to control disk space use. Enable logging for the Rancher server cluster or System Project.

Set the auditLog.destination to hostPath to forward logs to volume shared with the host system instead of streaming to a sidecar container. When setting the destination to hostPath you may want to adjust the other auditLog parameters for log rotation.

Setting Extra Environment Variables

You can set extra environment variables for Rancher server using extraEnv. This list is passed to the Rancher deployment in its YAML format. It is embedded under env for the Rancher container. Refer to the Kubernetes documentation for setting container environment variables, extraEnv can use any of the keys referenced in Define Environment Variables for a Container.

Consider an example that uses the name and value keys:

--set 'extraEnv[0].name=CATTLE_TLS_MIN_VERSION'
--set 'extraEnv[0].value=1.0'

If passing sensitive data as the value for an environment variable, such as proxy authentication credentials, it is strongly recommended that a secret reference is used. This will prevent sensitive data from being exposed in Helm or the Rancher deployment.

Consider an example that uses the name, valueFrom.secretKeyRef.name, and valueFrom.secretKeyRef.key keys. See example in HTTP Proxy

TLS Settings

When you install Rancher inside of a Kubernetes cluster, TLS is offloaded at the cluster’s ingress controller. The possible TLS settings depend on the used ingress controller.

See TLS settings for more information and options.

Import local Cluster

By default Rancher server will detect and import the local cluster it’s running on. User with access to the local cluster will essentially have “root” access to all the clusters managed by Rancher server.

caution

If you turn addLocal off, most Rancher v2.5 features won’t work, including the EKS provisioner.

If this is a concern in your environment you can set this option to “false” on your initial install.

This option is only effective on the initial Rancher install. See Issue 16522 for more information.

--set addLocal="false"

Customizing your Ingress

To customize or use a different ingress with Rancher server you can set your own Ingress annotations.

Example on setting a custom certificate issuer:

--set ingress.extraAnnotations.'cert-manager\.io/cluster-issuer'=issuer-name

Example on setting a static proxy header with ingress.configurationSnippet. This value is parsed like a template so variables can be used.

--set ingress.configurationSnippet='more_set_input_headers X-Forwarded-Host {{ .Values.hostname }};'

HTTP Proxy

Rancher requires internet access for some functionality (Helm charts). Use proxy to set your proxy server or use extraEnv to set the HTTPS_PROXY environment variable to point to your proxy server.

Add your IP exceptions to the noProxy chart value as a comma separated list. Make sure you add the following values:

• Pod cluster IP range (default: 10.42.0.0/16).
• Service cluster IP range (default: 10.43.0.0/16).
• Internal cluster domains (default: .svc,.cluster.local).
• Any worker cluster controlplane nodes. Rancher supports CIDR notation ranges in this list.

When not including sensitive data, the proxy or extraEnv chart options can be used. When using extraEnv the noProxy Helm option is ignored. Therefore, the NO_PROXY environment variable must also be set with extraEnv.

The following is an example of setting proxy using the extraEnv chart option:

--set proxy="http://<proxy_url:proxy_port>/"

Example of setting proxy using the extraEnv chart option:

--set extraEnv[1].name=HTTPS_PROXY
--set extraEnv[1].value="http://<proxy_url>:<proxy_port>/"
--set extraEnv[2].name=NO_PROXY
--set extraEnv[2].value="127.0.0.0/8\,10.0.0.0/8\,172.16.0.0/12\,192.168.0.0/16\,.svc\,.cluster.local"

When including sensitive data, such as proxy authentication credentials, use the extraEnv option with valueFrom.secretRef to prevent sensitive data from being exposed in Helm or the Rancher deployment.

The following is an example of using extraEnv to configure proxy. This example secret would contain the value "http://<username>:<password>@<proxy_url>:<proxy_port>/" in the secret’s "https-proxy-url" key:

--set extraEnv[1].name=HTTPS_PROXY
--set extraEnv[1].valueFrom.secretKeyRef.name=secret-name
--set extraEnv[1].valueFrom.secretKeyRef.key=https-proxy-url
--set extraEnv[2].name=NO_PROXY
--set extraEnv[2].value="127.0.0.0/8\,10.0.0.0/8\,172.16.0.0/12\,192.168.0.0/16\,.svc\,.cluster.local"

To learn more about how to configure environment variables, refer to Define Environment Variables for a Container.

Additional Trusted CAs

If you have private registries, catalogs or a proxy that intercepts certificates, you may need to add more trusted CAs to Rancher.

--set additionalTrustedCAs=true

Once the Rancher deployment is created, copy your CA certs in pem format into a file named ca-additional.pem and use kubectl to create the tls-ca-additional secret in the cattle-system namespace.

kubectl -n cattle-system create secret generic tls-ca-additional --from-file=ca-additional.pem=./ca-additional.pem

Private Registry and Air Gap Installs

For details on installing Rancher with a private registry, see the air gap installation docs.

External TLS Termination

We recommend configuring your load balancer as a Layer 4 balancer, forwarding plain 80/tcp and 443/tcp to the Rancher Management cluster nodes. The Ingress Controller on the cluster will redirect http traffic on port 80 to https on port 443.

You may terminate the SSL/TLS on a L7 load balancer external to the Rancher cluster (ingress). Use the --set tls=external option and point your load balancer at port http 80 on all of the Rancher cluster nodes. This will expose the Rancher interface on http port 80. Be aware that clients that are allowed to connect directly to the Rancher cluster will not be encrypted. If you choose to do this we recommend that you restrict direct access at the network level to just your load balancer.

note

If you are using a Private CA signed certificate, add --set privateCA=true and see Adding TLS Secrets - Using a Private CA Signed Certificate to add the CA cert for Rancher.

Your load balancer must support long lived websocket connections and will need to insert proxy headers so Rancher can route links correctly.

Configuring Ingress for External TLS when Using NGINX v0.25

In NGINX v0.25, the behavior of NGINX has changed regarding forwarding headers and external TLS termination. Therefore, in the scenario that you are using external TLS termination configuration with NGINX v0.25, you must edit the cluster.yml to enable the use-forwarded-headers option for ingress:

ingress:
  provider: nginx
  options:
    use-forwarded-headers: 'true'

Required Headers

• Host
• X-Forwarded-Proto
• X-Forwarded-Port
• X-Forwarded-For

Recommended Timeouts

• Read Timeout: 1800 seconds
• Write Timeout: 1800 seconds
• Connect Timeout: 30 seconds

Health Checks

Rancher will respond 200 to health checks on the /healthz endpoint.

Example NGINX config

This NGINX configuration is tested on NGINX 1.14.

caution

This NGINX configuration is only an example and may not suit your environment. For complete documentation, see NGINX Load Balancing - HTTP Load Balancing.

• Replace IP_NODE1, IP_NODE2 and IP_NODE3 with the IP addresses of the nodes in your cluster.
• Replace both occurrences of FQDN to the DNS name for Rancher.
• Replace /certs/fullchain.pem and /certs/privkey.pem to the location of the server certificate and the server certificate key respectively.

worker_processes 4;
worker_rlimit_nofile 40000;
events {
    worker_connections 8192;
}
http {
    upstream rancher {
        server IP_NODE_1:80;
        server IP_NODE_2:80;
        server IP_NODE_3:80;
    }
    map $http_upgrade $connection_upgrade {
        default Upgrade;
        ''      close;
    }
    server {
        listen 443 ssl http2;
        server_name FQDN;
        ssl_certificate /certs/fullchain.pem;
        ssl_certificate_key /certs/privkey.pem;
        location / {
            proxy_set_header Host $host;
            proxy_set_header X-Forwarded-Proto $scheme;
            proxy_set_header X-Forwarded-Port $server_port;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_pass http://rancher;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection $connection_upgrade;
            # This allows the ability for the execute shell window to remain open for up to 15 minutes. Without this parameter, the default is 1 minute and will automatically close.
            proxy_read_timeout 900s;
            proxy_buffering off;
        }
    }
    server {
        listen 80;
        server_name FQDN;
        return 301 https://$server_name$request_uri;
    }
}