EDB Postgres for Kubernetes brings the PostgreSQL and EDB Postgres Advanced databases to Kubernetes and OpenShift, inheriting all the security related infrastructure. This article provides an overview of the 4C security model adopted by the Kubernetes Community.
EDB Postgres for Kubernetes is an operator for Kubernetes and OpenShift environments, distributed by EDB, that implements the primary/standby architecture using native streaming replication. It works with both PostgreSQL and EDB Postgres Advanced.
Our choice was to develop an operator that could integrate with Kubernetes itself, coexist in its ecosystem, and directly interact with the Kubernetes API.
It was a conscious decision, based on several factors, including the thorough evaluation of the security infrastructure that Kubernetes provides—on top of which we were supposed to build our Operator. We know that security compliance is not a checklist result; rather, it is a continuous journey. And, we were extremely pleased and relieved to see the level of care and attention that Kubernetes developers placed on security, providing users and developers with a rich set of features and options to control access to resources.
Overview
Kubernetes has been designed with security in mind, through a multi-layered model approach known as “4C”, inspired by the Defense in Depth (DiD) model. The 4C security model for Cloud Native computing with containers is organized in four layers:
- Cloud
- Cluster
- Container
- Code
Each layer is shielded by the surrounding layer and provides its own capabilities and features for security, as illustrated below:
The Cloud layer
The Cloud layer is the most external one—and as such, it is the most critical of all. Given that Kubernetes is a distributed system that is made up of several applications running on Linux machines, administrators must take the same security measures as any other system.
Obviously, such measures change whether you are managing your own Kubernetes clusters or you are running Kubernetes on a third-party cloud provider such as AWS, Azure, or Google, each with its own set of recommendations and best practices.
Security at Cloud level is critical, but given its complexity and variability, further discussion is beyond the scope of this article (refer to the Kubernetes documentation). If you have been given access to a Kubernetes cluster, this should have already been properly assessed by the Kubernetes and infrastructure administrators for you.
The Cluster layer
The second layer is represented by the Cluster level, which implies that all Kubernetes components that form both the control plane and the worker nodes are protected, starting from the most critical one: the kube-api-server. The Cluster level also contemplates securing applications, commonly known as workloads in Kubernetes.
It is at this level that you can really appreciate the attention, the quality, the width, and the depth that Kubernetes creators and developers have dedicated to security design.
For example, starting with Kubernetes’ components, they all natively use encrypted communications and require TLS certificates for authenticating with each other.
The main interface of Kubernetes, the kube-api-server, is by default only accessible via HTTPS and can be protected by authentication—which can also be delegated to external identity providers (including OpenID Connect). Authorization to the API server is normally implemented with flexible Role Based Access Control (RBAC) rules, which can also be extended and customized. This means that SSH access is not required to administer a Kubernetes cluster and the applications (workloads) that run in it.
Kubernetes also provides administrators and users with several native techniques and resources to control and harden the cluster and the applications that run in it, such as pod networks, network policies, namespaces (similar to logical subclusters), pod security policies, security contexts, and so on. We will discuss more these concepts in the section below about immutable application containers.
It is important to know that our EDB Postgres for Kubernetes operator has been designed to cooperate directly with the Kubernetes API and the control plane through the implementation of admission, mutation, and conversion webhooks. It relies on a service account to authenticate itself with the API server and on a security context to run as an unprivileged user. Also, each Postgres cluster that is deployed with the operator has its own service account to constantly communicate with the API server and provide information about the status.
The Container layer
The next inner security level is the Container. Container images can be scanned for known vulnerabilities and exposures. For example, our images on Quay.io are continuously scanned and rebuilt once a day in case of new images of RedHat UBI, the base image used by our Cloud Native software. Container images can be built following the immutable application container paradigm, and therefore have a single PID 1 entrypoint process that does not require root privileges (more in the next section).
Also, container images enable stricter version control and more effective patch management, as containers are not updated; they are just replaced. We know how important it is to regularly keep systems updated from a security perspective and thanks to Kubernetes’ deployments this can be done with no downtime through rolling updates and declarative configuration, bringing relevant benefits to the business in terms of change management control and compliance.
The Code layer
Finally, security is the developer’s responsibility: the innermost level and the last “C” letter is represented by the Code. Kubernetes is the natural outlet of Dev(Sec)Ops cultural principles and dogmas like “You build it, you own it” and “Shift left on security.”
In this area, it is important that organizations rely on CI/CD pipeline integrations, static code analysis, security scanning, and automated testing in general. When building the operator, EDB has followed consolidated Lean/DevOps principles, practices, and capabilities like version control, trunk-based development, continuous delivery branch, peer review, test automation, and code scanning—to name a few.
Final thoughts
Security cannot be an activity performed by a separate department or team (even though they can certainly act as enablers throughout an organization). Security is everyone’s responsibility, and as a result, we are called to continuously update our knowledge and technical skills.
A good start is represented by completing a certification path in both Kubernetes Administration (CKA) and Security (CKS, which is relatively new).
If you want to know more about how our operator addresses security, please read the EDB Postgres for Kubernetes “Security” section in the documentation. Feel free to try the operator, test it and directly assess its security level.
Stay tuned for more articles about EDB Postgres for Kubernetes and security in the upcoming weeks!