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 interaction of components, encryption, auditing and other crucial functionality.

Tools

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.

Authorization
simplified RBAC

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

And more

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

Coming soon

  • Multitenancy
  • Integration with HashiCorp Vault
  • Integration with OpenPolicyAgent

Building components

Guidelines

  • 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

Guidelines

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

Authorization
simplified RBAC

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

We use cookies
We use cookies to enhance your experience. By continuing to visit this site you agree to our use of cookies. More info