Deckhouse Security
We use proven Open Source tools and best DevSecOps practices to increase the security of the cluster and the applications deployed in it. The platform implements advanced authentication and authorization mechanisms, secure component interaction, encryption, auditing, and other crucial functionality.
CIS Benchmarks
Deckhouse meets CIS Kubernetes Benchmark recommendations*. Security measures are implemented both at the component and platform level. For example, you can restrict network access to only the necessary interfaces, prohibit anonymous access, use certificates, set permissions for files and directories. Automatic tests are run in all Deckhouse clusters to ensure compliance with CIS Benchmarks. Reports with the results are then listed in the Grafana dashboard.
* CIS Kubernetes Benchmark is a set of guidelines for creating a reliable security environment for Kubernetes-based software.
SELinux
Security-Enhanced Linux (SELinux)* is a standard for securing Linux distributions. You can forcefully activate the SELinux mode in distributions that are used with Deckhouse.
* SELinux defines access policies for applications, processes and files.
PCI SSC
Deckhouse meets most of the PCI Security Standards Council (PCI SSC)* recommendations. The platform is well protected against threats common to payment systems that use container technology. We use the Container and Container Orchestration Tools Guide to assess Deckhouse's security.
* PCI SSC is a global forum that helps develop, apply, and improve security standards to protect payment systems.
Tools and best practices
- Deckhouse provides sophisticated security out-of-the-box.
- A federated authentication provider with the ability to connect any external directory service. Manage an up-to-date user directory using the tools you're accustomed to.
- Role-based end-to-end authorization that extends the standard RBAC capabilities. Flexible centralized access management. Seven predefined roles as well as the option to create new ones.
- Advanced Cilium-based network policies.
- Kubernetes event auditing to keep track of cluster operations and analyze errors.
- Security policies based on Pod Security Standards with three predefined restriction levels and the option to extend them.
- A recommended set of operating policies and best practices for running your applications with an option to extend them.
- A module for searching security threats with a set of built-in rules and the option to extend them.
- Centralized management of TLS certificates: validity monitoring, issuing and reissuing, as well as issuing self-signed certificates.
- Scanning of container images for vulnerabilities on a daily basis and providing a report.
Building components
- Docker images for all platform components can only be pulled from the Deckhouse repository.
- Only the necessary binaries from the original image files created by the software authors are used.
- All dependencies related to the original images as well as the SHA digest of the image are strictly pre-defined. The resulting image is built based on the base image made specifically for Deckhouse.
- In the vast majority of cases, we use Alpine (the most secure Linux distribution) to build the base image.
- Deckhouse and Kubernetes components are updated on a regular basis.
- We carefully select our software. We only use solutions that have been proven to be reliable based on our own experience and that of the Open Source community.
- Most of the checks are performed automatically by linters. Among other things, these checks ensure that the Dockerfile configuration is correct and prohibit the use of third-party images.
- The CI builds are scanned for CVEs every day; the scan report is sent to the developers. All the Sn level (and more critical) vulnerabilities are addressed within 3 hours, while those of Sn-Sk levels are dealt with within 24 hours.
Configuring components and their interaction
- Each component runs with a minimal set of privileges in Kubernetes that is sufficient for its operation (the "minimum RBAC" policy).
- Components never have root privileges. Exceptions are explicitly defined in the permission list.
- The root file system is read-only (except for a small number of specific directories).
- Local ports of all Deckhouse components are secured with TLS encryption and authentication.
- Linters check that RBAC rights are explicitly and unambiguously defined in a specific file of each Deckhouse module. This ensures a single point of control.
- The naming scheme for Service Accounts, roles, rolebindings, etc. is enforced, which protects against human errors.
- Authentication between cluster components is carried out in two ways: via TLS or bearer tokens. Authorization is performed via Kubernetes mechanisms (SubjectAccessReview).
Roadmap
We are continuously working to improve Deckhouse security. Please refer to the roadmap to see when new features will be added and existing ones will be enhanced.