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 interaction of components, encryption, auditing and other crucial functionality.
Deckhouse meets CIS Kubernetes Benchmark recommendations*. Security measures are implemented both at the component level and at the platform level. For example, you can restrict network access to the necessary interfaces only, prohibit anonymous access, use certificates, set permissions for files and directories.
* CIS Kubernetes Benchmark is a set of guidelines for creating a reliable security environment for Kubernetes-based software.
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.
Deckhouse provides a set of solutions for secure authentication, authorization, network policy management, ordering TLS certificates, and more.
Federated Authentication Provider
- Deckhouse provides a pre-installed federated authentication provider based on Dex (Identity Provider, IdP).
- It is integrated with Kubernetes and all service components.
- It can be integrated with the application if it supports OIDC.
- The oauth2-proxy operator facilitates convenient interaction with the Ingress controller.
- You can create users directly in the cluster or connect users of external authentication systems: GitHub, GitLab, OIDC, LDAP.
- Deckhouse provides a simplified and more user-friendly version of RBAC in Kubernetes. It has seven ready-made roles that are suitable for any use-cases. This reduces the chance of error and makes it easier to configure authorization policies.
- If necessary, you can increase the number of roles using the standard Kubernetes RBAC tools.
- The network policy management module. A simple and reliable system with rules that are independent of the type of installation and the CNI used.
- Kubernetes event auditing to account for cluster operations and error analysis.
- The cert-manager module. This module can order third-party TLS certificates and issue self-signed ones. It keeps certificates up to date and automatically reissues them.
- Integration with HashiCorp Vault
- Integration with OpenPolicyAgent
- 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.
How it works
- We carefully choose the software. We 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 linters. For 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 used. All the Sn level (and more severe) vulnerabilities are handled within three hours, while Sn-Sk level vulnerabilities are handled within 24 hours.
An example of Dockerfile for the kube-dns module*
# Based on https://github.com/coredns/coredns/blob/master/Dockerfile ARG BASE_ALPINE FROM coredns/coredns:1.6.9@sha256:40ee1b708e20e3a6b8e04ccd8b6b3dd8fd25343eab27c37154946f232649ae21 as artifact FROM $BASE_ALPINE COPY --from=artifact /coredns /coredns ENTRYPOINT [ "/coredns" ]
* The module installs CoreDNS components for managing DNS in the Kubernetes cluster.
Configuring components and their interaction
- Each component runs with a minimal set of privileges in Kubernetes that is sufficient for its operation ("minimum RBAC").
- 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.
- Additional authentication and authorization requests to the Kubernetes API are cached and do not affect performance.
- Linters check that RBAC rights are defined in a specific file of each Deckhouse module explicitly and unambiguously. This provides a single point of control.
- Service Account, role, rolebinding, etc., names are strictly regulated, thus protecting against human error.
- Authentication between cluster components is carried out in two ways: via TLS or bearer tokens. Authorization is performed via Kubernetes mechanisms (SubjectAccessReview).
Example: suppose you use Prometheus for monitoring the cluster. It collects data from all components. Each component has a port for connecting the monitoring service. Prometheus uses an individual SSL certificate to connect to this port.
Upon receiving a request from Prometheus, the component authenticates it by checking if the Prometheus certificate is signed by the Kubernetes Certificate Authority. Then it performs authorization by requesting SubjectAccessReview. This mechanism ensures that only Prometheus can connect to the monitoring ports.