-
-
-
-
-
-
-
-
- Rancher docs
- -Rancher is open source software that combines everything an organization needs to adopt and run containers in production. Built on Kubernetes, Rancher makes it easy for DevOps teams to test, deploy and manage their applications.
-
-
-
-
-
- 
- 
-
-
-
-
-
-
-
-
- 
-
-
-
-
-
-
-
- 
-
-
-
-
-
-
- Featured resource
- Read about how to migrate from Rancher v1.6 Cattle to v2.x
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- -
- - 2.6 - Rancher 2.6 -
- -- -
Rancher manages all of your Kubernetes clusters everywhere, unifies them under centralized RBAC, monitors them and lets you easily deploy and manage workloads through an intuitive user interface.
- - -
-
-
-
-
- -
- - 2.5 - Rancher 2.5 -
- -- -
Rancher manages all of your Kubernetes clusters everywhere, unifies them under centralized RBAC, monitors them and lets you easily deploy and manage workloads through an intuitive user interface.
- - -
-
-
-
-
- -
- - 2.0-2.4 - Rancher 2.0-2.4 -
- -- -
Rancher manages all of your Kubernetes clusters everywhere, unifies them under centralized RBAC, monitors them and lets you easily deploy and manage workloads through an intuitive user interface.
- - -
-
-
-
-
- -
- - 1.6 - Rancher 1.6 -
- -- -
If you haven't yet migrated to Rancher 2.x, you can still find documentation for 1.6 here. This is only for legacy users of the 1.6 product.
- - -
-
-
-
-
- -
- - OS - RancherOS -
- -- -
RancherOS is the lightest, easiest way to run Docker in production. Engineered from the ground up for security and speed, it runs all system services and user workloads within Docker containers.
- - -
-
-
-
-
- -
- - RKE - Rancher Kubernetes Engine -
- -- -
Rancher Kubernetes Engine (RKE) is an extremely simple, lightning fast Kubernetes installer that works everywhere.
- - -
-
-
-
-
- -
- - K3S - K3S -
- -- -
Lightweight Kubernetes. Easy to install, half the memory, all in a binary less than 100 MB.
- - -
-
-
-
-
- -
- - RKE2 - RKE2 -
- -- -
RKE2, also known as RKE Government, is Rancher's next-generation Kubernetes distribution.
- - -
-
-
-
-
-
- -
- - Longhorn - Longhorn -
- -- -
Longhorn is a lightweight, reliable, and powerful distributed block storage system for Kubernetes.
- - -Based on the above, the following example command could be used to launch a server instance that connects to a PostgreSQL database named k3s: -``` -K3S_DATASTORE_ENDPOINT='postgres://username:password@hostname:5432/k3s' k3s server -``` - -And the following example could be used to connect to a MySQL database using client certificate authentication: -``` -K3S_DATASTORE_ENDPOINT='mysql://username:password@tcp(hostname:3306)/k3s' \ -K3S_DATASTORE_CERTFILE='/path/to/client.crt' \ -K3S_DATASTORE_KEYFILE='/path/to/client.key' \ -k3s server -``` - -### Embedded etcd for HA - -Please see [High Availability with Embedded DB]({{
-
-
-### Control 1.2.16
-Ensure that the admission control plugin `PodSecurityPolicy` is set.
-Rationale
-Setting admission control policy to `NamespaceLifecycle` ensures that objects cannot be created in non-existent namespaces, and that namespaces undergoing termination are not used for creating the new objects. This is recommended to enforce the integrity of the namespace termination process and also for the availability of the newer objects. - -This can be remediated by passing this argument as a value to the `enable-admission-plugins=` and pass that to `--kube-apiserver-arg=` argument to `k3s server`. An example can be found below. -
-
-
-### Control 1.2.22
-Ensure that the `--audit-log-path` argument is set.
-Rationale
-A Pod Security Policy is a cluster-level resource that controls the actions that a pod can perform and what it has the ability to access. The `PodSecurityPolicy` objects define a set of conditions that a pod must run with in order to be accepted into the system. Pod Security Policies are comprised of settings and strategies that control the security features a pod has access to and hence this must be used to control pod access permissions. - -This can be remediated by passing this argument as a value to the `enable-admission-plugins=` and pass that to `--kube-apiserver-arg=` argument to `k3s server`. An example can be found below. -
-
-
-### Control 1.2.23
-Ensure that the `--audit-log-maxage` argument is set to 30 or as appropriate.
-Rationale
-Auditing the Kubernetes API Server provides a security-relevant chronological set of records documenting the sequence of activities that have affected system by individual users, administrators or other components of the system. Even though currently, Kubernetes provides only basic audit capabilities, it should be enabled. You can enable it by setting an appropriate audit log path. - -This can be remediated by passing this argument as a value to the `--kube-apiserver-arg=` argument to `k3s server`. An example can be found below. -
-
-
-### Control 1.2.24
-Ensure that the `--audit-log-maxbackup` argument is set to 10 or as appropriate.
-Rationale
-Retaining logs for at least 30 days ensures that you can go back in time and investigate or correlate any events. Set your audit log retention period to 30 days or as per your business requirements. - -This can be remediated by passing this argument as a value to the `--kube-apiserver-arg=` argument to `k3s server`. An example can be found below. -
-
-
-### Control 1.2.25
-Ensure that the `--audit-log-maxsize` argument is set to 100 or as appropriate.
-Rationale
-Kubernetes automatically rotates the log files. Retaining old log files ensures that you would have sufficient log data available for carrying out any investigation or correlation. For example, if you have set file size of 100 MB and the number of old log files to keep as 10, you would approximate have 1 GB of log data that you could potentially use for your analysis. - -This can be remediated by passing this argument as a value to the `--kube-apiserver-arg=` argument to `k3s server`. An example can be found below. -
-
-
-### Control 1.2.26
-Ensure that the `--request-timeout` argument is set as appropriate.
-Rationale
-Kubernetes automatically rotates the log files. Retaining old log files ensures that you would have sufficient log data available for carrying out any investigation or correlation. If you have set file size of 100 MB and the number of old log files to keep as 10, you would approximate have 1 GB of log data that you could potentially use for your analysis. - -This can be remediated by passing this argument as a value to the `--kube-apiserver-arg=` argument to `k3s server`. An example can be found below. -
-
-
-### Control 1.2.27
-Ensure that the `--service-account-lookup` argument is set to true.
-Rationale
-Setting global request timeout allows extending the API server request timeout limit to a duration appropriate to the user's connection speed. By default, it is set to 60 seconds which might be problematic on slower connections making cluster resources inaccessible once the data volume for requests exceeds what can be transmitted in 60 seconds. But, setting this timeout limit to be too large can exhaust the API server resources making it prone to Denial-of-Service attack. Hence, it is recommended to set this limit as appropriate and change the default limit of 60 seconds only if needed. - -This can be remediated by passing this argument as a value to the `--kube-apiserver-arg=` argument to `k3s server`. An example can be found below. -
-
-
-### Control 1.2.33
-Ensure that the `--encryption-provider-config` argument is set as appropriate.
-Rationale
-If `--service-account-lookup` is not enabled, the apiserver only verifies that the authentication token is valid, and does not validate that the service account token mentioned in the request is actually present in etcd. This allows using a service account token even after the corresponding service account is deleted. This is an example of time of check to time of use security issue. - -This can be remediated by passing this argument as a value to the `--kube-apiserver-arg=` argument to `k3s server`. An example can be found below. -
-
-
-### Control 1.2.34
-Ensure that encryption providers are appropriately configured.
-Rationale
-`etcd` is a highly available key-value store used by Kubernetes deployments for persistent storage of all of its REST API objects. These objects are sensitive in nature and should be encrypted at rest to avoid any disclosures. - -Detailed steps on how to configure secrets encryption in K3s are available in [Secrets Encryption](../secrets_encryption/). -
-
-
-### Control 1.3.1
-Ensure that the `--terminated-pod-gc-threshold` argument is set as appropriate.
-Rationale
-Where `etcd` encryption is used, it is important to ensure that the appropriate set of encryption providers is used. Currently, the `aescbc`, `kms` and `secretbox` are likely to be appropriate options. - -This can be remediated by passing a valid configuration to `k3s` as outlined above. Detailed steps on how to configure secrets encryption in K3s are available in [Secrets Encryption](../secrets_encryption/). -
-
-
-### Control 3.2.1
-Ensure that a minimal audit policy is created.
-Rationale
-Garbage collection is important to ensure sufficient resource availability and avoiding degraded performance and availability. In the worst case, the system might crash or just be unusable for a long period of time. The current setting for garbage collection is 12,500 terminated pods which might be too high for your system to sustain. Based on your system resources and tests, choose an appropriate threshold value to activate garbage collection. - -This can be remediated by passing this argument as a value to the `--kube-apiserver-arg=` argument to `k3s server`. An example can be found below. -
-
-
-### Control 4.2.7
-Ensure that the `--make-iptables-util-chains` argument is set to true.
-Rationale
-Logging is an important detective control for all systems, to detect potential unauthorized access. - -This can be remediated by passing controls 1.2.22 - 1.2.25 and verifying their efficacy. -
-
-
-### Control 5.1.5
-Ensure that default service accounts are not actively used
-Rationale
-Kubelets can automatically manage the required changes to iptables based on how you choose your networking options for the pods. It is recommended to let kubelets manage the changes to iptables. This ensures that the iptables configuration remains in sync with pods networking configuration. Manually configuring iptables with dynamic pod network configuration changes might hamper the communication between pods/containers and to the outside world. You might have iptables rules too restrictive or too open. - -This can be remediated by passing this argument as a value to the `--kube-apiserver-arg=` argument to `k3s server`. An example can be found below. -
-
-
-## Control Plane Execution and Arguments
-
-Listed below are the K3s control plane components and the arguments they are given at start, by default. Commented to their right is the CIS 1.6 control that they satisfy.
-
-```bash
-kube-apiserver
- --advertise-port=6443
- --allow-privileged=true
- --anonymous-auth=false # 1.2.1
- --api-audiences=unknown
- --authorization-mode=Node,RBAC
- --bind-address=127.0.0.1
- --cert-dir=/var/lib/rancher/k3s/server/tls/temporary-certs
- --client-ca-file=/var/lib/rancher/k3s/server/tls/client-ca.crt # 1.2.31
- --enable-admission-plugins=NodeRestriction,PodSecurityPolicy # 1.2.17
- --etcd-cafile=/var/lib/rancher/k3s/server/tls/etcd/server-ca.crt # 1.2.32
- --etcd-certfile=/var/lib/rancher/k3s/server/tls/etcd/client.crt # 1.2.29
- --etcd-keyfile=/var/lib/rancher/k3s/server/tls/etcd/client.key # 1.2.29
- --etcd-servers=https://127.0.0.1:2379
- --insecure-port=0 # 1.2.19
- --kubelet-certificate-authority=/var/lib/rancher/k3s/server/tls/server-ca.crt
- --kubelet-client-certificate=/var/lib/rancher/k3s/server/tls/client-kube-apiserver.crt
- --kubelet-client-key=/var/lib/rancher/k3s/server/tls/client-kube-apiserver.key
- --profiling=false # 1.2.21
- --proxy-client-cert-file=/var/lib/rancher/k3s/server/tls/client-auth-proxy.crt
- --proxy-client-key-file=/var/lib/rancher/k3s/server/tls/client-auth-proxy.key
- --requestheader-allowed-names=system:auth-proxy
- --requestheader-client-ca-file=/var/lib/rancher/k3s/server/tls/request-header-ca.crt
- --requestheader-extra-headers-prefix=X-Remote-Extra-
- --requestheader-group-headers=X-Remote-Group
- --requestheader-username-headers=X-Remote-User
- --secure-port=6444 # 1.2.20
- --service-account-issuer=k3s
- --service-account-key-file=/var/lib/rancher/k3s/server/tls/service.key # 1.2.28
- --service-account-signing-key-file=/var/lib/rancher/k3s/server/tls/service.key
- --service-cluster-ip-range=10.43.0.0/16
- --storage-backend=etcd3
- --tls-cert-file=/var/lib/rancher/k3s/server/tls/serving-kube-apiserver.crt # 1.2.30
- --tls-private-key-file=/var/lib/rancher/k3s/server/tls/serving-kube-apiserver.key # 1.2.30
-```
-
-```bash
-kube-controller-manager
- --address=127.0.0.1
- --allocate-node-cidrs=true
- --bind-address=127.0.0.1 # 1.3.7
- --cluster-cidr=10.42.0.0/16
- --cluster-signing-cert-file=/var/lib/rancher/k3s/server/tls/client-ca.crt
- --cluster-signing-key-file=/var/lib/rancher/k3s/server/tls/client-ca.key
- --kubeconfig=/var/lib/rancher/k3s/server/cred/controller.kubeconfig
- --port=10252
- --profiling=false # 1.3.2
- --root-ca-file=/var/lib/rancher/k3s/server/tls/server-ca.crt # 1.3.5
- --secure-port=0
- --service-account-private-key-file=/var/lib/rancher/k3s/server/tls/service.key # 1.3.4
- --use-service-account-credentials=true # 1.3.3
-```
-
-```bash
-kube-scheduler
- --address=127.0.0.1
- --bind-address=127.0.0.1 # 1.4.2
- --kubeconfig=/var/lib/rancher/k3s/server/cred/scheduler.kubeconfig
- --port=10251
- --profiling=false # 1.4.1
- --secure-port=0
-```
-
-```bash
-kubelet
- --address=0.0.0.0
- --anonymous-auth=false # 4.2.1
- --authentication-token-webhook=true
- --authorization-mode=Webhook # 4.2.2
- --cgroup-driver=cgroupfs
- --client-ca-file=/var/lib/rancher/k3s/agent/client-ca.crt # 4.2.3
- --cloud-provider=external
- --cluster-dns=10.43.0.10
- --cluster-domain=cluster.local
- --cni-bin-dir=/var/lib/rancher/k3s/data/223e6420f8db0d8828a8f5ed3c44489bb8eb47aa71485404f8af8c462a29bea3/bin
- --cni-conf-dir=/var/lib/rancher/k3s/agent/etc/cni/net.d
- --container-runtime-endpoint=/run/k3s/containerd/containerd.sock
- --container-runtime=remote
- --containerd=/run/k3s/containerd/containerd.sock
- --eviction-hard=imagefs.available<5%,nodefs.available<5%
- --eviction-minimum-reclaim=imagefs.available=10%,nodefs.available=10%
- --fail-swap-on=false
- --healthz-bind-address=127.0.0.1
- --hostname-override=hostname01
- --kubeconfig=/var/lib/rancher/k3s/agent/kubelet.kubeconfig
- --kubelet-cgroups=/systemd/system.slice
- --node-labels=
- --pod-manifest-path=/var/lib/rancher/k3s/agent/pod-manifests
- --protect-kernel-defaults=true # 4.2.6
- --read-only-port=0 # 4.2.4
- --resolv-conf=/run/systemd/resolve/resolv.conf
- --runtime-cgroups=/systemd/system.slice
- --serialize-image-pulls=false
- --tls-cert-file=/var/lib/rancher/k3s/agent/serving-kubelet.crt # 4.2.10
- --tls-private-key-file=/var/lib/rancher/k3s/agent/serving-kubelet.key # 4.2.10
-```
-
-The command below is an example of how the outlined remediations can be applied to harden K3s.
-
-```bash
-k3s server \
- --protect-kernel-defaults=true \
- --secrets-encryption=true \
- --kube-apiserver-arg='audit-log-path=/var/lib/rancher/k3s/server/logs/audit.log' \
- --kube-apiserver-arg='audit-policy-file=/var/lib/rancher/k3s/server/audit.yaml' \
- --kube-apiserver-arg='audit-log-maxage=30' \
- --kube-apiserver-arg='audit-log-maxbackup=10' \
- --kube-apiserver-arg='audit-log-maxsize=100' \
- --kube-apiserver-arg='request-timeout=300s' \
- --kube-apiserver-arg='service-account-lookup=true' \
- --kube-apiserver-arg='enable-admission-plugins=NodeRestriction,PodSecurityPolicy,NamespaceLifecycle,ServiceAccount' \
- --kube-controller-manager-arg='terminated-pod-gc-threshold=10' \
- --kube-controller-manager-arg='use-service-account-credentials=true' \
- --kubelet-arg='streaming-connection-idle-timeout=5m' \
- --kubelet-arg='make-iptables-util-chains=true'
-```
-
-## Conclusion
-
-If you have followed this guide, your K3s cluster will be configured to comply with the CIS Kubernetes Benchmark. You can review the [CIS Benchmark Self-Assessment Guide](../self_assessment/) to understand the expectations of each of the benchmark's checks and how you can do the same on your cluster.
diff --git a/content/k3s/latest/en/security/secrets_encryption/_index.md b/content/k3s/latest/en/security/secrets_encryption/_index.md
deleted file mode 100644
index a7491e2fb63..00000000000
--- a/content/k3s/latest/en/security/secrets_encryption/_index.md
+++ /dev/null
@@ -1,241 +0,0 @@
----
-title: Secrets Encryption
-weight: 26
----
-
-# Secrets Encryption Config
-_Available as of v1.17.4+k3s1_
-
-K3s supports enabling secrets encryption at rest by passing the flag `--secrets-encryption` on a server; this flag will do the following automatically:
-
-- Generate an AES-CBC key
-- Generate an encryption config file with the generated key
-- Pass the config to the KubeAPI as encryption-provider-config
-
-Example of the encryption config file:
-```
-{
- "kind": "EncryptionConfiguration",
- "apiVersion": "apiserver.config.k8s.io/v1",
- "resources": [
- {
- "resources": [
- "secrets"
- ],
- "providers": [
- {
- "aescbc": {
- "keys": [
- {
- "name": "aescbckey",
- "secret": "xxxxxxxxxxxxxxxxxxx"
- }
- ]
- }
- },
- {
- "identity": {}
- }
- ]
- }
- ]
-}
-```
-
-
-## Secrets Encryption Tool
-_Available as of v1.21.8+k3s1_
-
-K3s contains a utility tool `secrets-encrypt`, which enables automatic control over the following:
-
-- Disabling/Enabling secrets encryption
-- Adding new encryption keys
-- Rotating and deleting encryption keys
-- Reencrypting secrets
-
->**Warning:** Failure to follow proper procedure for rotating encryption keys can leave your cluster permanently corrupted. Proceed with caution.
-
-### Single-Server Encryption Key Rotation
-To rotate secrets encryption keys on a single-node cluster:
-
-- Start the K3s server with the flag `--secrets-encryption`
-
->**Note:** Starting K3s without encryption and enabling it at a later time is currently *not* supported.
-
-1. Prepare
-
- ```
- k3s secrets-encrypt prepare
- ```
-
-2. Kill and restart the K3s server with same arguments
-3. Rotate
-
- ```
- k3s secrets-encrypt rotate
- ```
-
-4. Kill and restart the K3s server with same arguments
-5. Reencrypt
-
- ```
- k3s secrets-encrypt reencrypt
- ```
-
-### High-Availability Encryption Key Rotation
-The steps are the same for both embedded DB and external DB clusters.
-
-To rotate secrets encryption keys on HA setups:
-
->**Notes:**
->
-> - Starting K3s without encryption and enabling it at a later time is currently *not* supported.
->
-> - While not required, it is recommended that you pick one server node from which to run the `secrets-encrypt` commands.
-
-- Start up all three K3s servers with the `--secrets-encryption` flag. For brevity, the servers will be referred to as S1, S2, S3.
-
-1. Prepare on S1
-
- ```
- k3s secrets-encrypt prepare
- ```
-
-2. Kill and restart S1 with same arguments
-3. Once S1 is up, kill and restart the S2 and S3
-
-4. Rotate on S1
-
- ```
- k3s secrets-encrypt rotate
- ```
-
-5. Kill and restart S1 with same arguments
-6. Once S1 is up, kill and restart the S2 and S3
-
-7. Reencrypt on S1
-
- ```
- k3s secrets-encrypt reencrypt
- ```
-
-8. Kill and restart S1 with same arguments
-9. Once S1 is up, kill and restart the S2 and S3
-
-### Single-Server Secrets Encryption Disable/Enable
-After launching a server with `--secrets-encryption` flag, secrets encryption can be disabled.
-
-To disable secrets encryption on a single-node cluster:
-
-1. Disable
-
- ```
- k3s secrets-encrypt disable
- ```
-
-2. Kill and restart the K3s server with same arguments
-
-3. Reencrypt with flags
-
- ```
- k3s secrets-encrypt reencrypt --force --skip
- ```
-
-To re-enable secrets encryption on a single node cluster:
-
-1. Enable
-
- ```
- k3s secrets-encrypt enable
- ```
-
-2. Kill and restart the K3s server with same arguments
-
-3. Reencrypt with flags
-
- ```
- k3s secrets-encrypt reencrypt --force --skip
- ```
-
-### High-Availability Secrets Encryption Disable/Enable
-After launching a HA cluster with `--secrets-encryption` flags, secrets encryption can be disabled.
->**Note:** While not required, it is recommended that you pick one server node from which to run the `secrets-encrypt` commands.
-
-For brevity, the three servers used in this guide will be referred to as S1, S2, S3.
-
-To disable secrets encryption on a HA cluster:
-
-1. Disable on S1
-
- ```
- k3s secrets-encrypt disable
- ```
-
-2. Kill and restart S1 with same arguments
-3. Once S1 is up, kill and restart the S2 and S3
-
-
-4. Reencrypt with flags on S1
-
- ```
- k3s secrets-encrypt reencrypt --force --skip
- ```
-
-To re-enable secrets encryption on a HA cluster:
-
-1. Enable on S1
-
- ```
- k3s secrets-encrypt enable
- ```
-
-2. Kill and restart S1 with same arguments
-3. Once S1 is up, kill and restart the S2 and S3
-
-4. Reencrypt with flags on S1
-
- ```
- k3s secrets-encrypt reencrypt --force --skip
- ```
-
-
-### Secrets Encryption Status
-The secrets-encrypt tool includes a `status` command that displays information about the current status of secrets encryption on the node.
-
-An example of the command on a single-server node:
-```
-$ k3s secrets-encrypt status
-Encryption Status: Enabled
-Current Rotation Stage: start
-Server Encryption Hashes: All hashes match
-
-Active Key Type Name
------- -------- ----
- * AES-CBC aescbckey
-
-```
-
-Another example on HA cluster, after rotating the keys, but before restarting the servers:
-```
-$ k3s secrets-encrypt status
-Encryption Status: Enabled
-Current Rotation Stage: rotate
-Server Encryption Hashes: hash does not match between node-1 and node-2
-
-Active Key Type Name
------- -------- ----
- * AES-CBC aescbckey-2021-12-10T22:54:38Z
- AES-CBC aescbckey
-
-```
-
-Details on each section are as follows:
-
-- __Encryption Status__: Displayed whether secrets encryption is disabled or enabled on the node
-- __Current Rotation Stage__: Indicates the current rotation stage on the node.
- Stages are: `start`, `prepare`, `rotate`, `reencrypt_request`, `reencrypt_active`, `reencrypt_finished`
-- __Server Encryption Hashes__: Useful for HA clusters, this indicates whether all servers are on the same stage with their local files. This can be used to identify whether a restart of servers is required before proceeding to the next stage. In the HA example above, node-1 and node-2 have different hashes, indicating that they currently do not have the same encryption configuration. Restarting the servers will sync up their configuration.
-- __Key Table__: Summarizes information about the secrets encryption keys found on the node.
- * __Active__: The "*" indicates which, if any, of the keys are currently used for secrets encryption. An active key is used by Kubernetes to encrypt any new secrets.
- * __Key Type__: All keys using this tool are `AES-CBC` type. See more info [here.](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/#providers)
- * __Name__: Name of the encryption key.
\ No newline at end of file
diff --git a/content/k3s/latest/en/security/self_assessment/_index.md b/content/k3s/latest/en/security/self_assessment/_index.md
deleted file mode 100644
index 6471a95fb83..00000000000
--- a/content/k3s/latest/en/security/self_assessment/_index.md
+++ /dev/null
@@ -1,3078 +0,0 @@
----
-title: CIS Self Assessment Guide
-weight: 90
----
-
-### CIS Kubernetes Benchmark v1.6 - K3s with Kubernetes v1.17 to v1.21
-
-#### Overview
-
-This document is a companion to the K3s security hardening guide. The hardening guide provides prescriptive guidance for hardening a production installation of K3s, and this benchmark guide is meant to help you evaluate the level of security of the hardened cluster against each control in the CIS Kubernetes Benchmark. It is to be used by K3s operators, security teams, auditors, and decision-makers.
-
-This guide is specific to the **v1.17**, **v1.18**, **v1.19**, **v1.20** and **v1.21** release line of K3s and the **v1.6** release of the CIS Kubernetes Benchmark.
-
-For more information about each control, including detailed descriptions and remediations for failing tests, you can refer to the corresponding section of the CIS Kubernetes Benchmark v1.6. You can download the benchmark, after creating a free account, in [Center for Internet Security (CIS)](https://www.cisecurity.org/benchmark/kubernetes/).
-
-#### Testing controls methodology
-
-Each control in the CIS Kubernetes Benchmark was evaluated against a K3s cluster that was configured according to the accompanying hardening guide.
-
-Where control audits differ from the original CIS benchmark, the audit commands specific to K3s are provided for testing.
-
-These are the possible results for each control:
-
-- **Pass** - The K3s cluster under test passed the audit outlined in the benchmark.
-- **Not Applicable** - The control is not applicable to K3s because of how it is designed to operate. The remediation section will explain why this is so.
-- **Warn** - The control is manual in the CIS benchmark and it depends on the cluster's use case or some other factor that must be determined by the cluster operator. These controls have been evaluated to ensure K3s does not prevent their implementation, but no further configuration or auditing of the cluster under test has been performed.
-
-This guide makes the assumption that K3s is running as a Systemd unit. Your installation may vary and will require you to adjust the "audit" commands to fit your scenario.
-
-> NOTE: Only `automated` tests (previously called `scored`) are covered in this guide.
-
-### Controls
-
----
-
-## 1.1 Master Node Configuration Files
-### 1.1.1 Ensure that the API server pod specification file permissions are set to 644 or more restrictive (Automated)
-
-
-**Result:** Not Applicable
-
-**Remediation:**
-Run the below command (based on the file location on your system) on the
-master node.
-For example, chmod 644 /etc/kubernetes/manifests/kube-apiserver.yaml
-
-### 1.1.2 Ensure that the API server pod specification file ownership is set to root:root (Automated)
-
-
-**Result:** Not Applicable
-
-**Remediation:**
-Run the below command (based on the file location on your system) on the master node.
-For example,
-chown root:root /etc/kubernetes/manifests/kube-apiserver.yaml
-
-### 1.1.3 Ensure that the controller manager pod specification file permissions are set to 644 or more restrictive (Automated)
-
-
-**Result:** Not Applicable
-
-**Remediation:**
-Run the below command (based on the file location on your system) on the master node.
-For example,
-chmod 644 /etc/kubernetes/manifests/kube-controller-manager.yaml
-
-### 1.1.4 Ensure that the controller manager pod specification file ownership is set to root:root (Automated)
-
-
-**Result:** Not Applicable
-
-**Remediation:**
-Run the below command (based on the file location on your system) on the master node.
-For example,
-chown root:root /etc/kubernetes/manifests/kube-controller-manager.yaml
-
-### 1.1.5 Ensure that the scheduler pod specification file permissions are set to 644 or more restrictive (Automated)
-
-
-**Result:** Not Applicable
-
-**Remediation:**
-Run the below command (based on the file location on your system) on the master node.
-For example,
-chmod 644 /etc/kubernetes/manifests/kube-scheduler.yaml
-
-### 1.1.6 Ensure that the scheduler pod specification file ownership is set to root:root (Automated)
-
-
-**Result:** Not Applicable
-
-**Remediation:**
-Run the below command (based on the file location on your system) on the master node.
-For example,
-chown root:root /etc/kubernetes/manifests/kube-scheduler.yaml
-
-### 1.1.7 Ensure that the etcd pod specification file permissions are set to 644 or more restrictive (Automated)
-
-
-**Result:** Not Applicable
-
-**Remediation:**
-Run the below command (based on the file location on your system) on the master node.
-For example,
-chmod 644 /etc/kubernetes/manifests/etcd.yaml
-
-### 1.1.8 Ensure that the etcd pod specification file ownership is set to root:root (Automated)
-
-
-**Result:** Not Applicable
-
-**Remediation:**
-Run the below command (based on the file location on your system) on the master node.
-For example,
-chown root:root /etc/kubernetes/manifests/etcd.yaml
-
-### 1.1.9 Ensure that the Container Network Interface file permissions are set to 644 or more restrictive (Manual)
-
-
-**Result:** Not Applicable
-
-**Remediation:**
-Run the below command (based on the file location on your system) on the master node.
-For example,
-chmod 644 Rationale
-Kubernetes provides a `default` service account which is used by cluster workloads where no specific service account is assigned to the pod. - -Where access to the Kubernetes API from a pod is required, a specific service account should be created for that pod, and rights granted to that service account. - -The default service account should be configured such that it does not provide a service account token and does not have any explicit rights assignments. - -This can be remediated by updating the `automountServiceAccountToken` field to `false` for the `default` service account in each namespace. - -For `default` service accounts in the built-in namespaces (`kube-system`, `kube-public`, `kube-node-lease`, and `default`), K3s does not automatically do this. You can manually update this field on these service accounts to pass the control. -2048MB (rancheros-vmware.iso) -GCE | 1GB | 1280MB -AWS | 1GB | 1.7GB - -You can adjust memory requirements by custom building RancherOS, please refer to [reduce-memory-requirements]({{
-
diff --git a/content/os/v1.x/en/about/_index.md b/content/os/v1.x/en/about/_index.md deleted file mode 100644 index 8b5bf2f8525..00000000000 --- a/content/os/v1.x/en/about/_index.md +++ /dev/null @@ -1,74 +0,0 @@ ---- -title: Additional Resources -weight: 200 ---- - -## Developing - -Development is easiest done with QEMU on Linux. OS X works too, although QEMU doesn't have KVM support. If you are running Linux in a virtual machine, then we recommend you run VMWare Fusion/Workstation and enable VT-x support. Then, QEMU will have KVM support and run sufficiently fast inside your Linux VM. - -### Building - -#### Requirements: - -* bash -* make -* Docker 1.10.3+ - -``` -$ make -``` - -The build will run in Docker containers, and when the build is done, the vmlinuz, initrd, and ISO should be in `dist/artifacts`. - -If you're building a version of RancherOS used for development and not for a release, you can instead run `make dev`. This will run faster than the standard build by avoiding building the `installer.tar` and `rootfs.tar.gz` artifacts which are not needed by QEMU. - -### Testing - -Run `make integration-tests` to run the all integration tests in a container, or `./scripts/integration-tests` to run them outside a container (they use QEMU to test the OS.) - -To run just one integration test, or a group of them (using regex's like `.*Console.*`, you can set the `RUNTEST` environment variable: - -``` -$ RUNTEST=TestPreload make integration-test -``` - -### Running - -Prerequisites: QEMU, coreutils, cdrtools/genisoimage/mkisofs. -On OS X, `brew` is recommended to install those. On Linux, use your distro package manager. - -To launch RancherOS in QEMU from your dev version, you can either use `make run`, or customise the vm using `./scripts/run` and its options. You can use `--append your.kernel=params here` and `--cloud-config your-cloud-config.yml` to configure the RancherOS instance you're launching. - -You can SSH in using `./scripts/ssh`. Your SSH keys should have been populated (if you didn't provide your own cloud-config) so you won't need a password. If you don't have SSH keys, or something is wrong with your cloud-config, then the password is "`rancher`". - -If you're on OS X, you can run RancherOS using [_xhyve_](https://github.com/mist64/xhyve) instead of QEMU: just pass `--xhyve` to `./scripts/run` and `./scripts/ssh`. - -### Debugging and logging. - -You can enable extra log information in the console by setting them using `sudo ros config set`, -or as kernel boot parameters. -Enable all logging by setting `rancher.debug` true -or you can set `rancher.docker.debug`, `rancher.system_docker.debug`, `rancher.bootstrap_docker.debug`, or `rancher.log` individually. - -You will also be able to view the debug logging information by running `dmesg` as root. - -## Repositories - -All of repositories are located within our main GitHub [page](https://github.com/rancher). - -[RancherOS Repo](https://github.com/rancher/os): This repo contains the bulk of the RancherOS code. - -[RancherOS Services Repo](https://github.com/rancher/os-services): This repo is where any [system-services]({{< baseurl >}}/os/v1.x/en//system-services/) can be contributed. - -[RancherOS Images Repo](https://github.com/rancher/os-images): This repo is for the corresponding service images. - - -## Bugs - -If you find any bugs or are having any trouble, please contact us by filing an [issue](https://github.com/rancher/os/issues/new). - -If you have any updates to our documentation, please make any PRs to our [docs repo](https://github.com/rancher/docs). - -
-
diff --git a/content/os/v1.x/en/about/custom-partition-layout/_index.md b/content/os/v1.x/en/about/custom-partition-layout/_index.md deleted file mode 100644 index a1c43205ed8..00000000000 --- a/content/os/v1.x/en/about/custom-partition-layout/_index.md +++ /dev/null @@ -1,147 +0,0 @@ ---- -title: How to custom partition layout -weight: 305 ---- - -When users use the default `ros install`, ROS will automatically create one partition on the root disk. -It will be the only partition with the label RANCHER_STATE. -But sometimes users want to be able to customize the root disk partition to isolate the data. - -> The following defaults to MBR mode, GPT mode has not been tested. - -### Use RANCHER_STATE partition - -As mentioned above, the default mode is that ROS will automatically create one partition with the label RANCHER_STATE. - -In addition, we can have other partitions, e.g.: two partitions, one is RANCHER_STATE and the other is a normal partition. - -First boot a ROS instance from ISO, then manually format and partition `/dev/sda` , the reference configuration is as follows: - -``` -[root@rancher oem]# fdisk -l -Disk /dev/sda: 5 GiB, 5377622016 bytes, 10503168 sectors -Units: sectors of 1 * 512 = 512 bytes -Sector size (logical/physical): 512 bytes / 512 bytes -I/O size (minimum/optimal): 512 bytes / 512 bytes -Disklabel type: dos -Disk identifier: 0x9fff87e9 - -Device Boot Start End Sectors Size Id Type -/dev/sda1 * 2048 7503167 7501120 3.6G 83 Linux -/dev/sda2 7503872 10503167 2999296 1.4G 83 Linux - -[root@rancher oem]# blkid -/dev/sda1: LABEL="RANCHER_STATE" UUID="512f212b-3130-458e-a2d1-1d601c34d4e4" TYPE="ext4" PARTUUID="9fff87e9-01" -/dev/sda2: UUID="3828e3ac-b825-4898-9072-45da9d37c2a6" TYPE="ext4" PARTUUID="9fff87e9-02" -``` - -Then install ROS to the disk with `ros install -t noformat -d /dev/sda ...`. - -After rebooting, you can use `/dev/sda2`. For example, changing the data root of user-docker: - -``` -$ ros config set mounts '[["/dev/sda2","/mnt/s","ext4",""]]’ -$ ros config set rancher.docker.graph /mnt/s -$ reboot -``` - -> In this mode, the RANCHER_STATE partition capacity cannot exceed 3.8GiB, otherwise the bootloader may not recognize the boot disk. This is the test result on VirtualBox. - -### Use RANCHER_BOOT partition - -When you only use the RANCHER_STATE partition, the bootloader will be installed in the `/boot` directory. - -``` -$ system-docker run -it --rm -v /:/host alpine -ls /host/boot -... -``` - -If you want to use a separate boot partition, you also need to boot a ROS instance from ISO, then manually format and partition `/dev/sda`: - -``` -[root@rancher rancher]# fdisk -l -Disk /dev/sda: 5 GiB, 5377622016 bytes, 10503168 sectors -Units: sectors of 1 * 512 = 512 bytes -Sector size (logical/physical): 512 bytes / 512 bytes -I/O size (minimum/optimal): 512 bytes / 512 bytes -Disklabel type: dos -Disk identifier: 0xe32b3025 - -Device Boot Start End Sectors Size Id Type -/dev/sda1 2048 2503167 2501120 1.2G 83 Linux -/dev/sda2 2504704 7503167 4998464 2.4G 83 Linux -/dev/sda3 7503872 10503167 2999296 1.4G 83 Linux - -[root@rancher rancher]# mkfs.ext4 -L RANCHER_BOOT /dev/sda1 -[root@rancher rancher]# mkfs.ext4 -L RANCHER_STATE /dev/sda2 -[root@rancher rancher]# mkfs.ext4 /dev/sda3 - -[root@rancher rancher]# blkid -/dev/sda1: LABEL="RANCHER_BOOT" UUID="43baeac3-11f3-4eed-acfa-64daf66b26c8" TYPE="ext4" PARTUUID="e32b3025-01" -/dev/sda2: LABEL="RANCHER_STATE" UUID="16f1ecef-dbe4-42a2-87a1-611939684e0b" TYPE="ext4" PARTUUID="e32b3025-02" -/dev/sda3: UUID="9f34e161-0eee-48f9-93de-3b7c54dea437" TYPE="ext4" PARTUUID="c9b8f181-03" -``` - -Then install ROS to the disk with `ros install -t noformat -d /dev/sda ...`. - -After rebooting, you can check the boot partition: - -``` -[root@rancher rancher]# mkdir /boot -[root@rancher rancher]# mount /dev/sda1 /boot -[root@rancher rancher]# ls -ahl /boot/ -total 175388 -drwxr-xr-x 4 root root 4.0K Sep 27 03:35 . -drwxr-xr-x 1 root root 4.0K Sep 27 03:38 .. --rw-r--r-- 1 root root 24 Sep 27 03:05 append --rw-r--r-- 1 root root 128 Sep 27 03:35 global.cfg --rw-r--r-- 1 root root 96.8M Sep 27 03:05 initrd -``` - -If you are not using the first partition as a BOOT partition, you need to set BOOT flag via the fdisk tool. - -> In this mode, the RANCHER_BOOT partition capacity cannot exceed 3.8GiB, otherwise the bootloader may not recognize the boot disk. This is the test result on VirtualBox. - -### Use RANCHER_OEM partition - -If you format any partition with the label RANCHER_OEM, ROS will mount this partition to `/usr/share/ros/oem`: - -``` -[root@rancher rancher]# blkid -/dev/sda2: LABEL="RANCHER_OEM" UUID="4f438455-63a3-4d29-ac90-50adbeced412" TYPE="ext4" PARTUUID="9fff87e9-02" - -[root@rancher rancher]# df -hT | grep sda2 -/dev/sda2 ext4 1.4G 4.3M 1.3G 0% /usr/share/ros/oem -``` - -Currently, this OEM directory is hardcoded and not configurable. - -### Use RANCHER_SWAP partition - -Suppose you have a partition(`/dev/sda2`) and you want to use it as a SWAP partition: - -``` -$ mkswap -L RANCHER_SWAP /dev/sda2 - -$ blkid -/dev/sda1: LABEL="RANCHER_STATE" UUID="512f212b-3130-458e-a2d1-1d601c34d4e4" TYPE="ext4" PARTUUID="9fff87e9-01" -/dev/sda2: LABEL="RANCHER_SWAP" UUID="772b6e76-f89c-458e-931e-10902d78d3e4" TYPE="swap" PARTUUID="9fff87e9-02" -``` - -After you install ROS to the disk, you can add the `runcmd` to enable SWAP: - -``` -runcmd: -- swapon -L RANCHER_SWAP -``` - -Then check the memory information: - -``` -[root@rancher rancher]# free -m - total used free shared buffers cached -Mem: 1996 774 1221 237 20 614 --/+ buffers/cache: 139 1856 -Swap: 487 0 487 -``` diff --git a/content/os/v1.x/en/about/faqs/_index.md b/content/os/v1.x/en/about/faqs/_index.md deleted file mode 100644 index 4caf7c71a8e..00000000000 --- a/content/os/v1.x/en/about/faqs/_index.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: FAQs -weight: 301 ---- - -### What is required to run RancherOS? - -RancherOS runs on any laptop, physical, or virtual servers. - -### What are some commands? - -Command | Description ---------|------------ -`docker`| Good old Docker, use that to run stuff. -`system-docker` | The Docker instance running the system containers. Must run as root or using `sudo` -`ros` | Control and configure RancherOS - - -### How can I extend my disk size in Amazon? - -Assuming your EC2 instance with RancherOS with more disk space than what's being read, run the following command to extend the disk size. This allows RancherOS to see the disk size. - -``` -$ docker run --privileged --rm --it debian:jessie resize2fs /dev/xvda1 -``` - -`xvda1` should be the right disk for your own setup. In the future, we will be trying to create a system service that would automatically do this on boot in AWS. diff --git a/content/os/v1.x/en/about/microcode-loader/_index.md b/content/os/v1.x/en/about/microcode-loader/_index.md deleted file mode 100644 index 88fe6069d7c..00000000000 --- a/content/os/v1.x/en/about/microcode-loader/_index.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: How to update microcode -weight: 306 ---- - -Processor manufacturers release stability and security updates to the processor microcode. While microcode can be updated through the BIOS, the Linux kernel is also able to apply these updates. -These updates provide bug fixes that can be critical to the stability of your system. Without these updates, you may experience spurious crashes or unexpected system halts that can be difficult to track down. - -The microcode loader supports three loading methods: - -- Early load microcode -- Late loading -- Builtin microcode - -You can get more details from [here](https://www.kernel.org/doc/html/latest/x86/microcode.html). - -RancherOS supports `Late loading`. To update the Intel microcode, get the latest Intel microcode. An example is [here](https://downloadcenter.intel.com/download/28087/Linux-Processor-Microcode-Data-File?v=t). Then copy the data files to the firmware directory: - -``` -mkdir -p /lib/firmware/intel-ucode/ -cp -v intel-ucode/* /lib/firmware/intel-ucode/ -``` -Reload the microcode. This file does not exist if you are running RancherOS on the hypervisor. Usually, the VM does not need to update the microcode. - -``` -echo 1 > /sys/devices/system/cpu/microcode/reload -``` -Check the result: - -``` -dmesg | grep microcode -[ 13.659429] microcode: sig=0x306f2, pf=0x1, revision=0x36 -[ 13.665981] microcode: Microcode Update Driver: v2.01
- -> **Note:** The `rancher/agent` version is correlated to the Rancher server version. You will need to check the custom command to get the appropriate tag for the version to use. - -_Cloud-Config Example_ - -Here's using the command above and converting it into a cloud-config file to launch the rancher/agent in docker when RancherOS boots up. - -```yaml -#cloud-config -rancher: - services: - rancher-agent1: - image: rancher/agent:v0.8.2 - command: http://
- -> **Note:** You can not name the service `rancher-agent` as this will not allow the rancher/agent container to be launched correctly. Please read more about why [you can't name your container as `rancher-agent`]({{
- -Adding more than one host label requires joining the additional host labels with an `&` - -```yaml -#cloud-config -rancher: - services: - rancher-agent1: - image: rancher/agent:v0.8.2 - command: http://
-Security policy-Rancher Labs supports responsible disclosure, and endeavours to resolve all issues in a reasonable time frame. RancherOS is a minimal Linux distribution, built with entirely using open source components. - |
-
-Reporting process-Please submit possible security issues by emailing security@rancher.com - |
-
-Announcements-Subscribe to the Rancher announcements forum for release updates. - |
-
- -After logging back, you'll be in the Ubuntu console. - -``` -$ sudo system-docker ps -CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES -6bf33541b2dc rancher/os-ubuntuconsole:v0.5.0-rc3 "/usr/sbin/entry.sh /" About a minute ago Up About a minute -``` - -
- -> **Note:** When switching between consoles, the currently running console container is destroyed, Docker is restarted and you will be logged out. - -### Console persistence - -All consoles except the default (busybox) console are persistent. Persistent console means that the console container will remain the same and preserves changes made to its filesystem across reboots. If a container is deleted/rebuilt, state in the console will be lost except what is in the persisted directories. - -``` -/home -/opt -/var/lib/docker -/var/lib/rancher -``` - -
- -> **Note:** When using a persistent console and in the current version's console, [rolling back]({{
- -At the next reboot, RancherOS will be using the Debian console. diff --git a/content/os/v1.x/en/configuration/switching-docker-versions/_index.md b/content/os/v1.x/en/configuration/switching-docker-versions/_index.md deleted file mode 100644 index d1df6deebaf..00000000000 --- a/content/os/v1.x/en/configuration/switching-docker-versions/_index.md +++ /dev/null @@ -1,97 +0,0 @@ ---- -title: Switching Docker Versions -weight: 129 -aliases: - - /os/v1.x/en/installation/configuration/switching-docker-versions ---- - -The version of User Docker used in RancherOS can be configured using a [cloud-config]({{< baseurl >}}/os/v1.x/en/configuration/#cloud-config) file or by using the `ros engine` command. - -> **Note:** There are known issues in Docker when switching between versions. For production systems, we recommend setting the Docker engine only once [using a cloud-config](#setting-the-docker-engine-using-cloud-config). - -### Available Docker engines - -The `ros engine list` command can be used to show which Docker engines are available to switch to. This command will also provide details of which Docker engine is currently being used. - -``` -$ sudo ros engine list -disabled docker-1.10.3 -disabled docker-1.11.2 -current docker-1.12.1 -``` - -### Setting the Docker engine using cloud-config - -RancherOS supports defining which Docker engine to use through the cloud-config file. To change the Docker version from the default packaged version, you can use the following cloud-config setting and select one of the available engines. In the following example, we'll use the cloud-config file to set RancherOS to use Docker 1.10.3 for User Docker. - -```yaml -#cloud-config -rancher: - docker: - engine: docker-1.10.3 -``` - -### Changing Docker engines after RancherOS has started - -If you've already started RancherOS and want to switch Docker engines, you can change the Docker engine by using the `ros engine switch` command. In our example, we'll switch to Docker 1.11.2. - -``` -$ sudo ros engine switch docker-1.11.2 -INFO[0000] Project [os]: Starting project -INFO[0000] [0/19] [docker]: Starting -Pulling docker (rancher/os-docker:1.11.2)... -1.11.2: Pulling from rancher/os-docker -2a6bbb293656: Pull complete -Digest: sha256:ec57fb24f6d4856d737e14c81a20f303afbeef11fc896d31b4e498829f5d18b2 -Status: Downloaded newer image for rancher/os-docker:1.11.2 -INFO[0007] Recreating docker -INFO[0007] [1/19] [docker]: Started -INFO[0007] Project [os]: Project started -$ docker version -Client: - Version: 1.11.2 - API version: 1.23 - Go version: go1.5.4 - Git commit: b9f10c9 - Built: Wed Jun 1 21:20:08 2016 - OS/Arch: linux/amd64 - -Server: - Version: 1.11.2 - API version: 1.23 - Go version: go1.5.4 - Git commit: b9f10c9 - Built: Wed Jun 1 21:20:08 2016 - OS/Arch: linux/amd64 - -``` - -### Enabling Docker engines - -If you don't want to automatically switch Docker engines, you can also set which version of Docker to use after the next reboot by enabling a Docker engine. - -``` -$ sudo ros engine enable docker-1.10.3 -``` - -## Using a Custom Version of Docker - -If you're using a version of Docker that isn't available by default or a custom build of Docker then you can create a custom Docker image and service file to distribute it. - -Docker engine images are built by adding the binaries to a folder named `engine` and then adding this folder to a `FROM scratch` image. For example, the following Dockerfile will build a Docker engine image. - -``` -FROM scratch -COPY engine /engine -``` - -Once the image is built a [system service]({{< baseurl >}}/os/v1.x/en/system-services/) configuration file must be created. An [example file](https://github.com/rancher/os-services/blob/master/d/docker-18.06.3-ce.yml) can be found in the rancher/os-services repo. Change the `image` field to point to the Docker engine image you've built. - -All of the previously mentioned methods of switching Docker engines are now available. For example, if your service file is located at `https://myservicefile` then the following cloud-config file could be used to use your custom Docker engine. - -```yaml -#cloud-config -rancher: - docker: - engine: https://myservicefile -``` diff --git a/content/os/v1.x/en/configuration/sysctl/_index.md b/content/os/v1.x/en/configuration/sysctl/_index.md deleted file mode 100644 index 1a8d6722d63..00000000000 --- a/content/os/v1.x/en/configuration/sysctl/_index.md +++ /dev/null @@ -1,17 +0,0 @@ ---- -title: Sysctl Settings -weight: 132 -aliases: - - /os/v1.x/en/installation/configuration/sysctl ---- - -The `rancher.sysctl` cloud-config key can be used to control sysctl parameters. This works in a manner similar to `/etc/sysctl.conf` for other Linux distros. - -``` -#cloud-config -rancher: - sysctl: - net.ipv4.conf.default.rp_filter: 1 -``` - -You can either add these settings to your `cloud-init.yml`, or use `sudo ros config merge -i somefile.yml` to merge settings into your existing system. diff --git a/content/os/v1.x/en/configuration/users/_index.md b/content/os/v1.x/en/configuration/users/_index.md deleted file mode 100644 index 4612c1cce2a..00000000000 --- a/content/os/v1.x/en/configuration/users/_index.md +++ /dev/null @@ -1,13 +0,0 @@ ---- -title: Users -weight: 130 -aliases: - - /os/v1.x/en/installation/configuration/users ---- - -Currently, we don't support adding other users besides `rancher`. - -You _can_ add users in the console container, but these users will only exist as long as the console container exists. It only makes sense to add users in a [persistent consoles]({{
- -> **Note:** The `:` must be in front of the version tag in order for the ECS image to be tagged correctly. - -### Amazon ECS enabled AMIs - -Latest Release: [v1.5.6](https://github.com/rancher/os/releases/tag/v1.5.6) - -Region | Type | AMI ----|--- | --- -eu-north-1 | HVM - ECS enabled | [ami-0539b842146882049](https://eu-north-1.console.aws.amazon.com/ec2/home?region=eu-north-1#launchInstanceWizard:ami=ami-0539b842146882049) -ap-south-1 | HVM - ECS enabled | [ami-0d3b8d8f26c689b4f](https://ap-south-1.console.aws.amazon.com/ec2/home?region=ap-south-1#launchInstanceWizard:ami=ami-0d3b8d8f26c689b4f) -eu-west-3 | HVM - ECS enabled | [ami-0fea51d2e82d132a0](https://eu-west-3.console.aws.amazon.com/ec2/home?region=eu-west-3#launchInstanceWizard:ami=ami-0fea51d2e82d132a0) -eu-west-2 | HVM - ECS enabled | [ami-00c3a19135715c851](https://eu-west-2.console.aws.amazon.com/ec2/home?region=eu-west-2#launchInstanceWizard:ami=ami-00c3a19135715c851) -eu-west-1 | HVM - ECS enabled | [ami-012c49dfd6efe2b69](https://eu-west-1.console.aws.amazon.com/ec2/home?region=eu-west-1#launchInstanceWizard:ami=ami-012c49dfd6efe2b69) -ap-northeast-2 | HVM - ECS enabled | [ami-02c46f0bcf41b4979](https://ap-northeast-2.console.aws.amazon.com/ec2/home?region=ap-northeast-2#launchInstanceWizard:ami=ami-02c46f0bcf41b4979) -ap-northeast-1 | HVM - ECS enabled | [ami-0354daa9f30fe60e6](https://ap-northeast-1.console.aws.amazon.com/ec2/home?region=ap-northeast-1#launchInstanceWizard:ami=ami-0354daa9f30fe60e6) -sa-east-1 | HVM - ECS enabled | [ami-00856c117fa05835f](https://sa-east-1.console.aws.amazon.com/ec2/home?region=sa-east-1#launchInstanceWizard:ami=ami-00856c117fa05835f) -ca-central-1 | HVM - ECS enabled | [ami-0b0cb5188439bf169](https://ca-central-1.console.aws.amazon.com/ec2/home?region=ca-central-1#launchInstanceWizard:ami=ami-0b0cb5188439bf169) -ap-southeast-1 | HVM - ECS enabled | [ami-0d8a0ed617d75bacc](https://ap-southeast-1.console.aws.amazon.com/ec2/home?region=ap-southeast-1#launchInstanceWizard:ami=ami-0d8a0ed617d75bacc) -ap-southeast-2 | HVM - ECS enabled | [ami-029cebde25901dcc9](https://ap-southeast-2.console.aws.amazon.com/ec2/home?region=ap-southeast-2#launchInstanceWizard:ami=ami-029cebde25901dcc9) -eu-central-1 | HVM - ECS enabled | [ami-0d513a54a3e67e38e](https://eu-central-1.console.aws.amazon.com/ec2/home?region=eu-central-1#launchInstanceWizard:ami=ami-0d513a54a3e67e38e) -us-east-1 | HVM - ECS enabled | [ami-0f5cc7a532c3171c3](https://us-east-1.console.aws.amazon.com/ec2/home?region=us-east-1#launchInstanceWizard:ami=ami-0f5cc7a532c3171c3) -us-east-2 | HVM - ECS enabled | [ami-030615e199666fd4b](https://us-east-2.console.aws.amazon.com/ec2/home?region=us-east-2#launchInstanceWizard:ami=ami-030615e199666fd4b) -us-west-1 | HVM - ECS enabled | [ami-0b530a841750e3315](https://us-west-1.console.aws.amazon.com/ec2/home?region=us-west-1#launchInstanceWizard:ami=ami-0b530a841750e3315) -us-west-2 | HVM - ECS enabled | [ami-0f1e06359f24f6480](https://us-west-2.console.aws.amazon.com/ec2/home?region=us-west-2#launchInstanceWizard:ami=ami-0f1e06359f24f6480) diff --git a/content/os/v1.x/en/installation/boot-process/built-in-system-services/_index.md b/content/os/v1.x/en/installation/boot-process/built-in-system-services/_index.md deleted file mode 100644 index d49a8ac4b5a..00000000000 --- a/content/os/v1.x/en/installation/boot-process/built-in-system-services/_index.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: Built-in System Services -weight: 150 ---- - -To launch RancherOS, we have built-in system services. They are defined in the [Docker Compose](https://docs.docker.com/compose/compose-file/) format, and can be found in the default system config file, `/usr/share/ros/os-config.yml`. You can [add your own system services]({{< baseurl >}}/os/v1.x/en/system-services/) or override services in the cloud-config. - -### preload-user-images - -Read more about [image preloading]({{
- -After logging back, you'll be in the Ubuntu console. - -``` -$ sudo system-docker ps -CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES -6bf33541b2dc rancher/os-ubuntuconsole:v0.5.0-rc3 "/usr/sbin/entry.sh /" About a minute ago Up About a minute -``` - -
- -> **Note:** When switching between consoles, the currently running console container is destroyed, Docker is restarted and you will be logged out. - -### Console persistence - -All consoles except the default (busybox) console are persistent. Persistent console means that the console container will remain the same and preserves changes made to its filesystem across reboots. If a container is deleted/rebuilt, state in the console will be lost except what is in the persisted directories. - -``` -/home -/opt -/var/lib/docker -/var/lib/rancher -``` - -
- -> **Note:** When using a persistent console and in the current version's console, [rolling back]({{
- -At the next reboot, RancherOS will be using the Debian console. diff --git a/content/os/v1.x/en/installation/custom-builds/custom-kernels/_index.md b/content/os/v1.x/en/installation/custom-builds/custom-kernels/_index.md deleted file mode 100644 index b3d6d35baae..00000000000 --- a/content/os/v1.x/en/installation/custom-builds/custom-kernels/_index.md +++ /dev/null @@ -1,80 +0,0 @@ ---- -title: Custom Kernels -weight: 181 ---- - -### Kernel version in RancherOS - -RancherOS basically uses the standard Linux kernel, but we maintain a kernel config ourselves. Due to various feature support and security fixes, we are constantly updating the kernel version. - -RancherOS | Kernel ---------- | ------ -<=v0.7.1 | 4.4.x -<=v1.3.0 | 4.9.x ->=v1.4.0 | 4.14.x - -### Building and Packaging a Kernel to be used in RancherOS - -We build the kernel for RancherOS at the [os-kernel repository](https://github.com/rancher/os-kernel). You can use this repository to help package your own custom kernel to be used in RancherOS. - -Create a clone of the [os-kernel](https://github.com/rancher/os-kernel) repository to your local machine using `git clone`. - -``` -$ git clone https://github.com/rancher/os-kernel.git -``` - -If you want to build kernel v4.14.53, you can refer to the following command. After the build is completed, a `./dist/kernel` directory will be created with the freshly built kernel tarball and headers. - -``` -$ git tag v4.14.53-rancher -$ KERNEL_TAG=4.14.53 make release -...snip... -./dist/kernel/extra-linux-4.14.53-rancher-x86.tar.gz -./dist/kernel/build-linux-4.14.53-rancher-x86.tar.gz -./dist/kernel/linux-4.14.53-rancher-x86.tar.gz -./dist/kernel/config -...snip... -Images ready to push: -rancher/os-extras:4.14.53-rancher -rancher/os-headers:4.14.53-rancher - ``` -For some users who need a custom kernel, the following information is very useful to you: - -1. The modules defined in `modules.list` will be packaged into the built-in modules. -2. The modules defined in `modules-extra.list` will be packaged into the extra modules. -3. You can modify `config/kernel-config` to build the kernel modules you need. -4. You can add your patches in the `patches` directory, and `os-kernel` will update these patches after downloading the kernel source. - -Now you need to either upload the `./dist/kernel/linux-4.14.53-rancher-x86.tar.gz` file to somewhere, or copy that file into your clone of the `rancher/os` repo, as `assets/kernel.tar.gz`. - -The `build-
- -You can generate a new SSH key for `cloud-config.yml` file by following this [article](https://help.github.com/articles/generating-ssh-keys/). - -Copy the public SSH key into RancherOS before installing to disk. - -Now that our `cloud-config.yml` contains our public SSH key, we can move on to installing RancherOS to disk! - -``` -$ sudo ros install -c cloud-config.yml -d /dev/sda -INFO[0000] No install type specified...defaulting to generic -Installing from rancher/os:v0.5.0 -Continue [y/N]: -``` - -For the `cloud-config.yml` file, you can also specify a remote URL, but you need to make sure you can get it: - -``` -$ sudo ros install -c https://link/to/cloud-config.yml -``` - -You will be prompted to see if you want to continue. Type **y**. - -``` -Unable to find image 'rancher/os:v0.5.0' locally -v0.5.0: Pulling from rancher/os -... -... -... -Status: Downloaded newer image for rancher/os:v0.5.0 -+ DEVICE=/dev/sda -... -... -... -+ umount /mnt/new_img -Continue with reboot [y/N]: -``` - -After installing RancherOS to disk, you will no longer be automatically logged in as the `rancher` user. You'll need to have added in SSH keys within your [cloud-config file]({{< baseurl >}}/os/v1.x/en/configuration/#cloud-config). - -#### Installing a Different Version - -By default, `ros install` uses the same installer image version as the ISO it is run from. The `-i` option specifies the particular image to install from. To keep the ISO as small as possible, the installer image is downloaded from DockerHub and used in System Docker. For example for RancherOS v0.5.0 the default installer image would be `rancher/os:v0.5.0`. - -You can use `ros os list` command to find the list of available RancherOS images/versions. - -``` -$ sudo ros os list -rancher/os:v0.4.0 remote -rancher/os:v0.4.1 remote -rancher/os:v0.4.2 remote -rancher/os:v0.4.3 remote -rancher/os:v0.4.4 remote -rancher/os:v0.4.5 remote -rancher/os:v0.5.0 remote -``` - -Alternatively, you can set the installer image to any image in System Docker to install RancherOS. This is particularly useful for machines that will not have direct access to the internet. - -#### Caching Images - -_Available as of v1.5.3_ - -Some configurations included in `cloud-config` require images to be downloaded from Docker to start. After installation, these images are downloaded automatically by RancherOS when booting. An example of these configurations are: - -- rancher.services_include -- rancher.console -- rancher.docker - -If you want to download and save these images to disk during installation, they will be cached and not need to be downloaded again upon each boot. You can cache these images by adding `-s` when using `ros install`: - -``` -$ ros install -d
- -> **Note:** System Docker proxy settings will not be applied until after a reboot. - -To add the `HTTP_PROXY`, `HTTPS_PROXY`, and `NO_PROXY` environment variables to a system service, specify each under the `environment` key for the service. - -```yaml -#cloud-config -rancher: - services: - myservice: - ... - environment: - - HTTP_PROXY - - HTTPS_PROXY - - NO_PROXY -``` diff --git a/content/os/v1.x/en/overview/_index.md b/content/os/v1.x/en/overview/_index.md deleted file mode 100644 index a2936d617c0..00000000000 --- a/content/os/v1.x/en/overview/_index.md +++ /dev/null @@ -1,49 +0,0 @@ ---- -title: Overview of RancherOS -shortTitle: RancherOS -description: RancherOS is a simplified Linux distribution built from containers, for containers. These documents describe how to install and use RancherOS. -weight: 1 ---- - -RancherOS is the smallest, easiest way to run Docker in production. Every process in RancherOS is a container managed by Docker. This includes system services such as `udev` and `syslog`. Because it only includes the services necessary to run Docker, RancherOS is significantly smaller than most traditional operating systems. By removing unnecessary libraries and services, requirements for security patches and other maintenance are also reduced. This is possible because, with Docker, users typically package all necessary libraries into their containers. - -Another way in which RancherOS is designed specifically for running Docker is that it always runs the latest version of Docker. This allows users to take advantage of the latest Docker capabilities and bug fixes. - -Like other minimalist Linux distributions, RancherOS boots incredibly quickly. Starting Docker containers is nearly instant, similar to starting any other process. This speed is ideal for organizations adopting microservices and autoscaling. - -Docker is an open-source platform designed for developers, system admins, and DevOps. It is used to build, ship, and run containers, using a simple and powerful command line interface (CLI). To get started with Docker, please visit the [Docker user guide](https://docs.docker.com/config/daemon/). - -### Hardware Requirements - -* Memory Requirements - -Platform | RAM requirement(>=v1.5.x) | RAM requirement(v1.4.x) --------- | ------------------------ | --------------------------- -Baremetal | 1GB | 1280MB -VirtualBox | 1GB | 1280MB -VMWare | 1GB | 1280MB (rancheros.iso)
2048MB (rancheros-vmware.iso) -GCE | 1GB | 1280MB -AWS | 1GB | 1.7GB - -You can adjust memory requirements by custom building RancherOS, please refer to [reduce-memory-requirements]({{
-
diff --git a/content/os/v1.x/en/quick-start-guide/_index.md b/content/os/v1.x/en/quick-start-guide/_index.md deleted file mode 100644 index cbd93c68ef4..00000000000 --- a/content/os/v1.x/en/quick-start-guide/_index.md +++ /dev/null @@ -1,131 +0,0 @@ ---- -title: Quick Start -weight: 1 ---- - -If you have a specific RanchersOS machine requirements, please check out our [guides on running RancherOS]({{< baseurl >}}/os/v1.x/en/installation/). With the rest of this guide, we'll start up a RancherOS using [Docker machine]({{< baseurl >}}/os/v1.x/en/installation/workstation//docker-machine/) and show you some of what RancherOS can do. - -### Launching RancherOS using Docker Machine - -Before moving forward, you'll need to have [Docker Machine](https://docs.docker.com/machine/) and [VirtualBox](https://www.virtualbox.org/wiki/Downloads) installed. Once you have VirtualBox and Docker Machine installed, it's just one command to get RancherOS running. - -``` -$ docker-machine create -d virtualbox \ - --virtualbox-boot2docker-url https://releases.rancher.com/os/latest/rancheros.iso \ - --virtualbox-memory 2048 \ -