mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-25 12:38:05 +00:00
Restructure v2.6 security docs
Signed-off-by: Guilherme Macedo <guilherme.macedo@suse.com>
This commit is contained in:
@@ -0,0 +1,6 @@
|
||||
---
|
||||
title: CIS Scans
|
||||
weight: 17
|
||||
---
|
||||
|
||||
The CIS scans documentation is now part of the [Security > CIS Scans]({{<baseurl>}}/rancher/v2.6/en/security/cis-scans) section.
|
||||
@@ -20,25 +20,25 @@ weight: 20
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
Security is at the heart of all Rancher features. From integrating with all the popular authentication tools and services, to an enterprise grade [RBAC capability,]({{<baseurl>}}/rancher/v2.6/en/admin-settings/rbac) Rancher makes your Kubernetes clusters even more secure.
|
||||
Security is at the heart of all Rancher features. From integrating with all the popular authentication tools and services, to an enterprise grade [RBAC capability]({{<baseurl>}}/rancher/v2.6/en/admin-settings/rbac), Rancher makes your Kubernetes clusters even more secure.
|
||||
|
||||
On this page, we provide security-related documentation along with resources to help you secure your Rancher installation and your downstream Kubernetes clusters:
|
||||
On this page, we provide security related documentation along with resources to help you secure your Rancher installation and your downstream Kubernetes clusters:
|
||||
|
||||
- [Running a CIS security scan on a Kubernetes cluster](#running-a-cis-security-scan-on-a-kubernetes-cluster)
|
||||
- [SELinux RPM](#selinux-rpm)
|
||||
- [Guide to hardening Rancher installations](#rancher-hardening-guide)
|
||||
- [The CIS Benchmark and self-assessment](#the-cis-benchmark-and-self-assessment)
|
||||
- [Third-party penetration test reports](#third-party-penetration-test-reports)
|
||||
- [Rancher CVEs and resolutions](#rancher-cves-and-resolutions)
|
||||
- [Rancher Security Advisories and CVEs](#rancher-security-advisories-and-cves)
|
||||
- [Kubernetes Security Best Practices](#kubernetes-security-best-practices)
|
||||
|
||||
### Running a CIS Security Scan on a Kubernetes Cluster
|
||||
|
||||
Rancher leverages [kube-bench](https://github.com/aquasecurity/kube-bench) to run a security scan to check whether Kubernetes is deployed according to security best practices as defined in the CIS (Center for Internet Security) Kubernetes Benchmark.
|
||||
Rancher leverages [kube-bench](https://github.com/aquasecurity/kube-bench) to run a security scan to check whether Kubernetes is deployed according to security best practices as defined in the [CIS](https://www.cisecurity.org/cis-benchmarks/) (Center for Internet Security) Kubernetes Benchmark.
|
||||
|
||||
The CIS Kubernetes Benchmark is a reference document that can be used to establish a secure configuration baseline for Kubernetes.
|
||||
|
||||
The Center for Internet Security (CIS) is a 501(c\)(3) non-profit organization, formed in October 2000, with a mission to "identify, develop, validate, promote, and sustain best practice solutions for cyber defense and build and lead communities to enable an environment of trust in cyberspace."
|
||||
The Center for Internet Security (CIS) is a 501(c\)(3) non-profit organization, formed in October 2000, with a mission to "identify, develop, validate, promote, and sustain best practice solutions for cyber defense and build and lead communities to enable an environment of trust in cyberspace".
|
||||
|
||||
CIS Benchmarks are best practices for the secure configuration of a target system. CIS Benchmarks are developed through the generous volunteer efforts of subject matter experts, technology vendors, public and private community members, and the CIS Benchmark Development team.
|
||||
|
||||
@@ -46,13 +46,13 @@ The Benchmark provides recommendations of two types: Automated and Manual. We ru
|
||||
|
||||
When Rancher runs a CIS security scan on a cluster, it generates a report showing the results of each test, including a summary with the number of passed, skipped and failed tests. The report also includes remediation steps for any failed tests.
|
||||
|
||||
For details, refer to the section on [security scans.]({{<baseurl>}}/rancher/v2.6/en/cis-scans)
|
||||
For details, refer to the section on [security scans.]({{<baseurl>}}/rancher/v2.6/en/security/cis-scans/)
|
||||
|
||||
### SELinux RPM
|
||||
|
||||
[Security-Enhanced Linux (SELinux)](https://en.wikipedia.org/wiki/Security-Enhanced_Linux) is a security enhancement to Linux. After being historically used by government agencies, SELinux is now industry standard and is enabled by default on CentOS 7 and 8.
|
||||
|
||||
We provide two RPMs (Red Hat packages) that enable Rancher products to function properly on SELinux-enforcing hosts: `rancher-selinux` and `rke2-selinux`. For details, see [this page.]({{<baseurl>}}/rancher/v2.6/en/security/selinux)
|
||||
We provide two RPMs (Red Hat packages) that enable Rancher products to function properly on SELinux-enforcing hosts: `rancher-selinux` and `rke2-selinux`. For details, see [this page]({{<baseurl>}}/rancher/v2.6/en/security/selinux).
|
||||
|
||||
### Rancher Hardening Guide
|
||||
|
||||
@@ -78,13 +78,13 @@ Rancher periodically hires third parties to perform security audits and penetrat
|
||||
|
||||
Results:
|
||||
|
||||
- [Cure53 Pen Test - 7/2019](https://releases.rancher.com/documents/security/pen-tests/2019/RAN-01-cure53-report.final.pdf)
|
||||
- [Untamed Theory Pen Test- 3/2019](https://releases.rancher.com/documents/security/pen-tests/2019/UntamedTheory-Rancher_SecurityAssessment-20190712_v5.pdf)
|
||||
- [Cure53 Pen Test - July 2019](https://releases.rancher.com/documents/security/pen-tests/2019/RAN-01-cure53-report.final.pdf)
|
||||
- [Untamed Theory Pen Test- March 2019](https://releases.rancher.com/documents/security/pen-tests/2019/UntamedTheory-Rancher_SecurityAssessment-20190712_v5.pdf)
|
||||
|
||||
### Rancher CVEs and Resolutions
|
||||
### Rancher Security Advisories and CVEs
|
||||
|
||||
Rancher is committed to informing the community of security issues in our products. For the list of CVEs (Common Vulnerabilities and Exposures) for issues we have resolved, refer to [this page.](./cve)
|
||||
|
||||
### Kubernetes Security Best Practices
|
||||
|
||||
For recommendations on securing your Kubernetes cluster, refer to the [Best Practices](./best-practices) guide.
|
||||
For recommendations on securing your Kubernetes cluster, refer to the [Kubernetes Security Best Practices](./best-practices) guide.
|
||||
|
||||
@@ -1,13 +1,32 @@
|
||||
---
|
||||
title: Security Best Practices
|
||||
title: Kubernetes Security Best Practices
|
||||
weight: 5
|
||||
---
|
||||
|
||||
### Restricting cloud metadata API access
|
||||
|
||||
Cloud providers such as AWS, Azure, or GCP often expose metadata services locally to instances. By default, this endpoint is accessible by pods running on a cloud instance, including pods in hosted Kubernetes providers such as EKS, AKS or GKE, and can contain cloud credentials for that node, provisioning data such as kubelet credentials, or other sensitive data. To mitigate this risk when running on a cloud platform, follow the [Kubernetes security recommendations](https://kubernetes.io/docs/tasks/administer-cluster/securing-a-cluster/#restricting-cloud-metadata-api-access): limit permissions given to instance credentials, use network policies to restrict pod access to the metadata API, and avoid using provisioning data to deliver secrets.
|
||||
Cloud providers such as AWS, Azure, DigitalOcean or GCP often expose metadata services locally to instances. By default, this endpoint is accessible by pods running on a cloud instance, including pods in hosted Kubernetes providers such as EKS, AKS, DigitalOcean Kubernetes or GKE, and can contain cloud credentials for that node, provisioning data such as kubelet credentials, or other sensitive data. To mitigate this risk when running on a cloud platform, follow the [Kubernetes security recommendations](https://kubernetes.io/docs/tasks/administer-cluster/securing-a-cluster/#restricting-cloud-metadata-api-access): limit permissions given to instance credentials, use network policies to restrict pod access to the metadata API, and avoid using provisioning data to deliver secrets.
|
||||
|
||||
Below is an example of a global network policy (`GlobalNetworkPolicy`) using Calico to restrict access to cloud metadata API.
|
||||
Below is an example of a network policy for Kubernetes to restrict access to cloud metadata API, but allowing access to everything else `0.0.0.0/0`.
|
||||
|
||||
```
|
||||
apiVersion: networking.k8s.io/v1
|
||||
kind: NetworkPolicy
|
||||
metadata:
|
||||
name: allow-all-egress-except-metadata-api
|
||||
spec:
|
||||
podSelector: {}
|
||||
policyTypes:
|
||||
- Egress
|
||||
egress:
|
||||
- to:
|
||||
- ipBlock:
|
||||
cidr: 0.0.0.0/0
|
||||
except:
|
||||
- 169.254.169.254/32
|
||||
```
|
||||
|
||||
A similar global network policy (`GlobalNetworkPolicy`) can be created using Calico.
|
||||
|
||||
```
|
||||
apiVersion: projectcalico.org/v3
|
||||
@@ -27,7 +46,10 @@ spec:
|
||||
nets:
|
||||
- 0.0.0.0/0
|
||||
```
|
||||
A similar policy can be created with Canal and Weave. For the list of approved CNI (Container Network Interface) providers in Rancher, please consult this [list]({{<baseurl>}}/rancher/v2.6/en/faq/networking/cni-providers).
|
||||
|
||||
Identical policies can be created with Canal and Weave. For the list of approved CNI (Container Network Interface) providers in Rancher, please consult this [list]({{<baseurl>}}/rancher/v2.6/en/faq/networking/cni-providers).
|
||||
|
||||
The provided policies are just examples and must be tailored to your security needs and environment, since they may conflict with other network policies in place in your cluster.
|
||||
|
||||
Removing unnecessary packages and using reduced base images is also a good defense in depth strategy to reduce the attack surface against possible abuses of the cloud metadata API. As well as following the principle of least privilege and using instances profiles and roles with the least amount of required permissions for the services to fully function.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user