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.
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.
- 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).
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.