Illumina Innovates with Rancher and Kubernetes
Click here to download a PDF version of this document
This document provides prescriptive guidance for hardening a production installation of Rancher v2.1.x. It outlines the configurations and controls required to address Kubernetes benchmark controls from the Center for Information Security (CIS).
For more detail on how a hardened cluster scores against the official CIS benchmark, refer to the CIS Benchmark Rancher Self-Assessment Guide - Rancher v2.1.x.
The following profile definitions agree with the CIS benchmarks for Kubernetes.
A profile is a set of configurations that provide a certain amount of hardening. Generally, the more hardened an environment is, the more it affects performance.
Items in this profile intend to:
Items in this profile extend the “Level 1” profile and exhibit one or more of the following characteristics:
Profile Applicability
Description
Configure sysctl settings to match what the kubelet would set if allowed.
Rationale
We recommend that users launch the kubelet with the --protect-kernel-defaults option. The settings that the kubelet initially attempts to change can be set manually.
--protect-kernel-defaults
This supports the following control:
Audit
vm.overcommit_memory = 1
sysctl vm.overcommit_memory
kernel.panic = 10
sysctl kernel.panic
kernel.panic_on_oops = 1
sysctl kernel.panic_on_oops
Remediation
/etc/sysctl.conf
vm.overcommit_memory=1 kernel.panic=10 kernel.panic_on_oops=1
sysctl -p
Create a Kubernetes encryption configuration file on each of the RKE nodes that will be provisioned with the controlplane role:
controlplane
This configuration file will ensure that the Rancher RKE cluster encrypts secrets at rest, which Kubernetes does not do by default.
This supports the following controls:
--experimental-encryption-provider-config
aescbc
On the control plane hosts for the Rancher HA cluster run:
stat /etc/kubernetes/encryption.yaml
Ensure that:
0600
root:root
apiVersion: v1 kind: EncryptionConfig resources: - resources: - secrets providers: - aescbc: keys: - name: key1 secret: <32-byte base64 encoded string> - identity: {}
Where aescbc is the key type, and secret is populated with a 32-byte base64 encoded string.
secret
head -c 32 /dev/urandom | base64 -i - touch /etc/kubernetes/encryption.yaml
chown root:root /etc/kubernetes/encryption.yaml chmod 0600 /etc/kubernetes/encryption.yaml
Where secret is the 32-byte base64-encoded string generated in the first step.
Place the configuration file for Kubernetes audit logging on each of the control plane nodes in the cluster.
The Kubernetes API has audit logging capability that is the best way to track actions in the cluster.
--audit-log-path
--audit-log-maxage
--audit-log-maxbackup
--audit-log-maxsize
AdvancedAuditing
On each control plane node, run:
stat /etc/kubernetes/audit.yaml
apiVersion: audit.k8s.io/v1beta1 kind: Policy rules: - level: Metadata
On nodes with the controlplane role:
touch /etc/kubernetes/audit.yaml
chown root:root /etc/kubernetes/audit.yaml chmod 0600 /etc/kubernetes/audit.yaml
Place the configuration file for Kubernetes event limit configuration on each of the control plane nodes in the cluster.
Set up the EventRateLimit admission control plugin to prevent clients from overwhelming the API server. The settings below are intended as an initial value and may need to be adjusted for larger clusters.
EventRateLimit
On nodes with the controlplane role run:
stat /etc/kubernetes/admission.yaml stat /etc/kubernetes/event.yaml
For each file, ensure that:
For admission.yaml ensure that the file contains:
admission.yaml
apiVersion: apiserver.k8s.io/v1alpha1 kind: AdmissionConfiguration plugins: - name: EventRateLimit path: /etc/kubernetes/event.yaml
For event.yaml ensure that the file contains:
event.yaml
apiVersion: eventratelimit.admission.k8s.io/v1alpha1 kind: Configuration limits: - type: Server qps: 500 burst: 5000
touch /etc/kubernetes/admission.yaml touch /etc/kubernetes/event.yaml
chown root:root /etc/kubernetes/admission.yaml chown root:root /etc/kubernetes/event.yaml chmod 0600 /etc/kubernetes/admission.yaml chmod 0600 /etc/kubernetes/event.yaml
(See Appendix A. for full RKE cluster.yml example)
cluster.yml
Ensure Kubelet options are configured to match CIS controls.
To pass the following controls in the CIS benchmark, ensure the appropriate flags are passed to the Kubelet.
--streaming-connection-idle-timeout
--make-iptables-util-chains
--event-qps
Inspect the Kubelet containers on all hosts and verify that they are running with the following options:
--streaming-connection-idle-timeout=<duration greater than 0>
--protect-kernel-defaults=false
--make-iptables-util-chains=false
--event-qps=0
services
services: kubelet: extra_args: streaming-connection-idle-timeout: "<duration>" protect-kernel-defaults: "true" make-iptables-util-chains: "true" event-qps: "0"
Where <duration> is in a form like 1800s.
<duration>
1800s
rke up --config cluster.yml
Ensure the RKE configuration is set to deploy the kube-api service with the options required for controls.
kube-api
To pass the following controls for the kube-api server ensure RKE configuration passes the appropriate options.
--anonymous-auth
--profiling argument
--repair-malformed-updates
AlwaysPullImages
DenyEscalatingExec
NamespaceLifecycle
--service-account-lookup
PodSecurityPolicy
false
kube-apiserver
docker inspect kube-apiserver
--anonymous-auth=false --profiling=false --repair-malformed-updates=false --service-account-lookup=true --enable-admission-plugins= "ServiceAccount,NamespaceLifecycle,LimitRanger,PersistentVolumeLabel,DefaultStorageClass,ResourceQuota,DefaultTolerationSeconds,AlwaysPullImages,DenyEscalatingExec,NodeRestriction,EventRateLimit,PodSecurityPolicy" --experimental-encryption-provider-config=/etc/kubernetes/encryption.yaml --admission-control-config-file=/etc/kubernetes/admission.yaml --audit-log-path=/var/log/kube-audit/audit-log.json --audit-log-maxage=5 --audit-log-maxbackup=5 --audit-log-maxsize=100 --audit-log-format=json --audit-policy-file=/etc/kubernetes/audit.yaml
volume
/var/log/kube-audit:/var/log/kube-audit
services: kube-api: pod_security_policy: true extra_args: anonymous-auth: "false" profiling: "false" repair-malformed-updates: "false" service-account-lookup: "true" enable-admission-plugins: "ServiceAccount,NamespaceLifecycle,LimitRanger,PersistentVolumeLabel,DefaultStorageClass,ResourceQuota,DefaultTolerationSeconds,AlwaysPullImages,DenyEscalatingExec,NodeRestriction,EventRateLimit,PodSecurityPolicy" experimental-encryption-provider-config: /etc/kubernetes/encryption.yaml admission-control-config-file: "/etc/kubernetes/admission.yaml" audit-log-path: "/var/log/kube-audit/audit-log.json" audit-log-maxage: "5" audit-log-maxbackup: "5" audit-log-maxsize: "100" audit-log-format: "json" audit-policy-file: /etc/kubernetes/audit.yaml extra_binds: - "/var/log/kube-audit:/var/log/kube-audit"
Set the appropriate options for the Kubernetes scheduling service.
To address the following controls on the CIS benchmark, the command line options should be set on the Kubernetes scheduler.
--profiling
--address
127.0.0.1
kube-scheduler
docker inspect kube-scheduler
command
--profiling=false --address=127.0.0.1
services: … scheduler: extra_args: profiling: "false" address: "127.0.0.1"
Set the appropriate arguments on the Kubernetes controller manager.
To address the following controls the options need to be passed to the Kubernetes controller manager.
--terminated-pod-gc-threshold
kube-controller-manager
docker inspect kube-controller-manager
--terminated-pod-gc-threshold=1000 --profiling=false --address=127.0.0.1
services: kube-controller: extra_args: profiling: "false" address: "127.0.0.1" terminated-pod-gc-threshold: "1000"
Configure a restrictive PodSecurityPolicy (PSP) as the default and create role bindings for system level services to use the less restrictive default PSP.
To address the following controls, a restrictive default PSP needs to be applied as the default. Role bindings need to be in place to allow system services to still function.
allowPrivilegeEscalation
cattle-system
kubectl get ns |grep cattle
kubectl get role default-psp-role -n ingress-nginx kubectl get role default-psp-role -n cattle-system kubectl get clusterrole psp:restricted
kubectl get rolebinding -n ingress-nginx default-psp-rolebinding kubectl get rolebinding -n cattle-system default-psp-rolebinding kubectl get clusterrolebinding psp:restricted
kubectl get psp restricted
addons: | apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: default-psp-role namespace: ingress-nginx rules: - apiGroups: - extensions resourceNames: - default-psp resources: - podsecuritypolicies verbs: - use --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: default-psp-rolebinding namespace: ingress-nginx roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: default-psp-role subjects: - apiGroup: rbac.authorization.k8s.io kind: Group name: system:serviceaccounts - apiGroup: rbac.authorization.k8s.io kind: Group name: system:authenticated --- apiVersion: v1 kind: Namespace metadata: name: cattle-system --- apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: default-psp-role namespace: cattle-system rules: - apiGroups: - extensions resourceNames: - default-psp resources: - podsecuritypolicies verbs: - use --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: default-psp-rolebinding namespace: cattle-system roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: default-psp-role subjects: - apiGroup: rbac.authorization.k8s.io kind: Group name: system:serviceaccounts - apiGroup: rbac.authorization.k8s.io kind: Group name: system:authenticated --- apiVersion: extensions/v1beta1 kind: PodSecurityPolicy metadata: name: restricted spec: requiredDropCapabilities: - NET_RAW privileged: false allowPrivilegeEscalation: false defaultAllowPrivilegeEscalation: false fsGroup: rule: RunAsAny runAsUser: rule: MustRunAsNonRoot seLinux: rule: RunAsAny supplementalGroups: rule: RunAsAny volumes: - emptyDir - secret - persistentVolumeClaim - downwardAPI - configMap - projected --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: psp:restricted rules: - apiGroups: - extensions resourceNames: - restricted resources: - podsecuritypolicies verbs: - use --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: psp:restricted roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: psp:restricted subjects: - apiGroup: rbac.authorization.k8s.io kind: Group name: system:serviceaccounts - apiGroup: rbac.authorization.k8s.io kind: Group name: system:authenticated
When deploying Rancher, disable the local cluster option on the Rancher Server.
NOTE: This requires Rancher v2.1.2 or above.
Having access to the local cluster from the Rancher UI is convenient for troubleshooting and debugging; however, if the local cluster is enabled in the Rancher UI, a user has access to all elements of the system, including the Rancher management server itself. Disabling the local cluster is a defense in depth measure and removes the possible attack vector from the Rancher UI and API.
--add-local=false
kubectl get deployment rancher -n cattle-system -o yaml |grep 'add-local'
local
--set addLocal="false"
Enable Rancher’s built-in audit logging capability.
Tracking down what actions were performed by users in Rancher can provide insight during post mortems, and if monitored proactively can be used to quickly detect malicious actions.
kubectl get deployment rancher -n cattle-system -o yaml | grep auditLog
Verify that the log is going to the appropriate destination, as set by auditLog.destination
auditLog.destination
sidecar
List pods:
kubectl get pods -n cattle-system
Tail logs:
kubectl logs <pod> -n cattle-system -c rancher-audit-log
hostPath
auditlog.hostPath
Upgrade the Rancher server installation using Helm, and configure the audit log settings. The instructions for doing so can be found in the reference section below.
The local admin password should be changed from the default.
The default admin password is common across all Rancher installations and should be changed immediately upon startup.
Attempt to login into the UI with the following credentials: - Username: admin - Password: admin
The login attempt must not succeed.
Change the password from admin to a password that meets the recommended password standards for your organization.
admin
When running Rancher in a production environment, configure an identity provider for authentication.
Rancher supports several authentication backends that are common in enterprises. It is recommended to tie Rancher into an external authentication system to simplify user and group access in the Rancher cluster. Doing so assures that access control follows the organization’s change management process for user accounts.
Configure the appropriate authentication provider for your Rancher installation according to the documentation found at the link in the reference section below.
Restrict administrator access to only those responsible for managing and operating the Rancher server.
The admin privilege level gives the user the highest level of access to the Rancher server and all attached clusters. This privilege should only be granted to a few people who are responsible for the availability and support of Rancher and the clusters that it manages.
The following script uses the Rancher API to show users with administrator privileges:
#!/bin/bash for i in $(curl -sk -u 'token-<id>:<secret>' https://<RANCHER_URL>/v3/users|jq -r .data[].links.globalRoleBindings); do curl -sk -u 'token-<id>:<secret>' $i| jq '.data[] | "\(.userId) \(.globalRoleId)"' done
The admin role should only be assigned to users that require administrative privileges. Any role that is not admin or user should be audited in the RBAC section of the UI to ensure that the privileges adhere to policies for global access.
user
The Rancher server permits customization of the default global permissions. We recommend that auditors also review the policies of any custom global roles.
Remove the admin role from any user that does not require administrative privileges.
Ensure that node drivers that are not needed or approved are not active in the Rancher console.
Node drivers are used to provision compute nodes in various cloud providers and local IaaS infrastructure. For convenience, popular cloud providers are enabled by default. If the organization does not intend to use these or does not allow users to provision resources in certain providers, the drivers should be disabled. This will prevent users from using Rancher resources to provision the nodes.
If a disallowed node driver is active, visit the Node Drivers page under Global and disable it.
nodes: - address: 18.191.190.205 internal_address: 172.31.24.213 user: ubuntu role: [ "controlplane", "etcd", "worker" ] - address: 18.191.190.203 internal_address: 172.31.24.203 user: ubuntu role: [ "controlplane", "etcd", "worker" ] - address: 18.191.190.10 internal_address: 172.31.24.244 user: ubuntu role: [ "controlplane", "etcd", "worker" ] services: kubelet: extra_args: streaming-connection-idle-timeout: "1800s" protect-kernel-defaults: "true" make-iptables-util-chains: "true" event-qps: "0" kube-api: pod_security_policy: true extra_args: anonymous-auth: "false" profiling: "false" repair-malformed-updates: "false" service-account-lookup: "true" enable-admission-plugins: "ServiceAccount,NamespaceLifecycle,LimitRanger,PersistentVolumeLabel,DefaultStorageClass,ResourceQuota,DefaultTolerationSeconds,AlwaysPullImages,DenyEscalatingExec,NodeRestriction,EventRateLimit,PodSecurityPolicy" experimental-encryption-provider-config: /etc/kubernetes/encryption.yaml admission-control-config-file: "/etc/kubernetes/admission.yaml" audit-log-path: "/var/log/kube-audit/audit-log.json" audit-log-maxage: "5" audit-log-maxbackup: "5" audit-log-maxsize: "100" audit-log-format: "json" audit-policy-file: /etc/kubernetes/audit.yaml extra_binds: - "/var/log/kube-audit:/var/log/kube-audit" scheduler: extra_args: profiling: "false" address: "127.0.0.1" kube-controller: extra_args: profiling: "false" address: "127.0.0.1" terminated-pod-gc-threshold: "1000" addons: | apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: default-psp-role namespace: ingress-nginx rules: - apiGroups: - extensions resourceNames: - default-psp resources: - podsecuritypolicies verbs: - use --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: default-psp-rolebinding namespace: ingress-nginx roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: default-psp-role subjects: - apiGroup: rbac.authorization.k8s.io kind: Group name: system:serviceaccounts - apiGroup: rbac.authorization.k8s.io kind: Group name: system:authenticated --- apiVersion: v1 kind: Namespace metadata: name: cattle-system --- apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: default-psp-role namespace: cattle-system rules: - apiGroups: - extensions resourceNames: - default-psp resources: - podsecuritypolicies verbs: - use --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: default-psp-rolebinding namespace: cattle-system roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: default-psp-role subjects: - apiGroup: rbac.authorization.k8s.io kind: Group name: system:serviceaccounts - apiGroup: rbac.authorization.k8s.io kind: Group name: system:authenticated --- apiVersion: extensions/v1beta1 kind: PodSecurityPolicy metadata: name: restricted spec: requiredDropCapabilities: - NET_RAW privileged: false allowPrivilegeEscalation: false defaultAllowPrivilegeEscalation: false fsGroup: rule: RunAsAny runAsUser: rule: MustRunAsNonRoot seLinux: rule: RunAsAny supplementalGroups: rule: RunAsAny volumes: - emptyDir - secret - persistentVolumeClaim - downwardAPI - configMap - projected --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: psp:restricted rules: - apiGroups: - extensions resourceNames: - restricted resources: - podsecuritypolicies verbs: - use --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: psp:restricted roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: psp:restricted subjects: - apiGroup: rbac.authorization.k8s.io kind: Group name: system:serviceaccounts - apiGroup: rbac.authorization.k8s.io kind: Group name: system:authenticated