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.
Deckhouse Security
Main features
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
Handling images
- Docker images for all platform components can only be downloaded 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 digest of the image are strictly pre-defined. The resulting image is built based on our base image.
- In the vast majority of cases, we use the Alpine (the most secure Linux distribution) to build the base image.
- Updates of the basic images are performed seamlessly. Kubernetes gets updated automatically according to the regulations.
Choosing and testing components
- We carefully choose the softwareWe use only the solutions that have proven to be reliable based on our own and the Open Source community experience.
- Most checks are performed in an automated manner using lintersFor example, they make sure that the Dockerfile configuration is correct and prohibit the use of third-party images.
- We constantly monitor new CVEs for all the software usedAll the Sn level (and more severe) vulnerabilities are handled within three hours, while Sn-Sk level vulnerabilities are handled within 24 hours.
Configuring components and their interaction
Robust hierarchy of access privileges
- 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.
Authorization (simplified RBAC)
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).