Why Kubernetes?
Kubernetes is an orchestration tool that runs containerized workloads in the Cloud. It is a great choice when working towards a manageable and cost-effective digital and data transformation: Kubernetes offers a well-structured solution that is easy to scale, maintain, and invoice with strong business models.
The open-source paradigm proves it is also attractive in data management, when offered as a service.
A good way to leverage this is to use PostgreSQL, an ACID (a relational database term that refers to Atomicity, Consistency, Isolation, and Durability) relational database, on Kubernetes.
What is Cloud Native PostgreSQL?
Cloud Native PostgreSQL is an operator for Kubernetes and OpenShift environments, distributed by EnterpriseDB, that implements the primary/standby architecture using native streaming replication. The program works with both PostgreSQL and EDB Postgres Advanced.
Cloud Native Postgres brings the PostgreSQL and EDB Postgres Advanced databases to Kubernetes and OpenShift, inheriting the related security infrastructure.
Hopla! Software chose an operator that could integrate with Kubernetes, coexist in its ecosystem, and interact directly with the Kubernetes API.
Cloud Native PostgreSQL is written in Go Language, like Kubernetes, and implements a Primary/Standby architecture on both PostgreSQL 10+ and EnterpriseDB Postgres Advanced 10+.
Container images are hosted on Quay.io. Widely available, Cloud Native PostgreSQL follows the EDB Limited Use License.
What makes Cloud Native PostgreSQL unique
This choice stands on an important 3-word concept: Immutable Application Containers. Let’s take a look at a specific project.
Declarative configuration
Cloud Native PostgreSQL consists of a Kubernetes manifest that can be downloaded from the documentation for the operator. The manifest is a YAML file used to create, modify and delete Kubernetes resources such as pods, deployments, services or ingresses. It is common practice to define manifests in the form of .yaml files and send them to the Kubernetes API Server.
EDB’s Kubernetes offering uses a declarative configuration approach to deploying software rather than an imperative one. By focusing on a DevOps mindset, the challenge becomes defining the desired state of the PostgreSQL cluster rather than a list of steps or changes to be executed in sequence.
Application vs System containers
Another important aspect of EnterpriseDB (EDB)’s offering is that it builds immutable application containers with a minimal operating system, to produce the smallest and lightest images possible. Container image builds are directly integrated into the Continuous Delivery pipeline from the commit phase to publishing on Quay.io.
An application container is designed to run a single main entry point process such as PostgreSQL. This differs from a system container, in which multiple services are running at the same time (e.g., PostgreSQL, SSH, Syslog, and so on). System containers are similar to traditional virtual machines or physical servers, but they tend not to fit well in Kubernetes on the whole.
As a result, EnterpriseDB’s application containers do not require the root user to run or access the storage, reducing the risk of exploits and privilege escalation incidents. This allows the implementation of important Pod Security Policies (PSP) in the system, such as a non-privileged mode for containers and volume access via security contexts.
Immutability
Immutable application containers are shipped with a given version of the stack and cannot be updated using ‘yum update’ or ‘apt upgrade’, for example. An update means a new container image; in Kubernetes terms, PostgreSQL is an application, and every PostgreSQL minor release has its own immutable container image.
Kubernetes has been designed to work with immutable application containers and perform deployments and/or updates of such applications in a rolling fashion without downtime. Persistent volumes allow reuse of the same PGDATA files.
A declarative approach and immutable application containers means that the Cloud Native PostgreSQL product can only work with Kubernetes and, most importantly, in Kubernetes.
This is an important difference between the Hopla! Software used and the currently available open source options. In order to manage high availability and automated fail-over, Hopla! Software does not use tools that have been designed for virtual machine or bare metal deployments, such as Patroni, Stolon, or repmgr.
Hopla! Software has decided to rely on Kubernetes alone – one reason for this is Kubernetes’ security model.
The 4C Security Model in Kubernetes
Let’s review the 4C security model adopted by the Kubernetes Community.
This conscious decision was based on several factors, including a thorough evaluation of the security infrastructure that Kubernetes provides.
Security compliance is not a checklist result, but rather a continuous journey, so the Hopla! Software team 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.
Kubernetes has been designed with security in mind, adopting 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:
Let’s take a closer look at each of the four layers.
The Cloud layer
The Cloud layer is the outermost layer, and as such, the most critical of all. Given that Kubernetes is a distributed system made up of several applications running on Linux machines, administrators must adopt the same security measures as any other system.
Obviously, such measures vary, depending on whether an administrator is managing a proprietary Kubernetes cluster or Kubernetes is being run on a third-party Cloud provider such as Amazon Web Services, Azure, or Google, each with its own set of recommendations and best practices.
Security at Cloud level is critical, but given the complexity and variability of the subject, further discussion is beyond the scope of this article (refer to the Kubernetes documentation for additional information).
If access to a Kubernetes cluster has been granted, this should already have been properly assessed by Kubernetes and infrastructure administrators.
The Cluster layer
The Cluster level forms the second layer, meaning that all the Kubernetes components in both the control plane and the worker nodes are protected, starting with the most critical: the kube-api-server. The Cluster level also includes securing applications, commonly known as workloads in Kubernetes.
It is at this level that the attention, quality, breadth and depth that Kubernetes’ creators and developers have dedicated to security design can really be appreciated.
To start with Kubernetes’ components, for example: all are native users of encrypted communications and require TLS certificates for authentication between each other.
Kubernetes’ main interface, 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 of the API server is normally implemented with flexible Role Based Access Control (RBAC) rules, which can also be extended and customized. This means that Secure Shell (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 within it, such as pod networks, network policies, namespaces (similar to logical subclusters), pod security policies, security contexts, and so on.
These concepts will be discussed in more depth in the section on immutable application containers below.
It is important to know that the Cloud Native PostgreSQL operator used by Hopla! Software has been designed to cooperate directly with the Kubernetes API and the control plane through the implementation of admission, mutation, and conversion webhooks.
The operator relies on a service account to authenticate itself with the API server and on a security context to run as an unprivileged user.
Each Postgres cluster that is deployed with the operator also has its own service account to constantly communicate with the API server and provide status information.
The Container layer
The next inner security level is the Container level. Container images can be scanned for known vulnerabilities and exposures. For example, images on Quay.io are continuously scanned and rebuilt once a day in case new images arise from RedHat UBI, the base image used by the company’s 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 detail on this will be found in the next section).
Container images also enable stricter version control and more effective patch management, as containers are not updated but just replaced.
It is important to regularly update systems from a security perspective and thanks to Kubernetes’ deployments this can be done with no downtime, through rolling updates and declarative configuration, bringing real benefits to the business in terms of change management control and compliance.
The Code layer
At the end of the day, security is the developer’s responsibility: the innermost level and the last ‘C’ represents Code. Kubernetes is a natural outlet for Dev(Sec)Ops cultural principles and maxims like “You build it, you own it” and “Shift left on security.”
In this arena, it is important that organizations rely on Continuous Integration/Continuous Delivery (CI/CD) pipeline integrations, static code analysis, security scanning, and automated testing in general.
When building the operator, EnterpriseDB (EDB) has followed consolidated Lean/DevOps principles, practices, and capabilities such as version control, trunk-based development, continuous delivery branch, peer review, test automation, and code scanning to name just a few.
Case Study: Single-sign on in the USA
KeyCloak is a single-sign on application that helps citizens to access government services. Developed and deployed with Kubernetes, the SSO applications requirements are scalability, security, and performances.
The proposed solution improves the user experience of the citizens accessing government websites and services. The app delivery is cost-effective.
EDB has provided value thanks to the speed and flexibility of Cloud Native Postgres.
Additionally, Cloud Native PostgreSQL helps create a new self-service environment to build new applications.
The Cloud Native PostgreSQL Plugin for kubectl
EnterpriseDB released Cloud Native PostgreSQL 1.1.0 at the beginning of February 2021. The DevOps team introduces new features incrementally – currently every two weeks.
One of the most useful features recently introduced is the CNP plugin for the kubectl tool. This tool expands operator’s capacity to make the management of a Cloud Native PostgreSQL (CNP) cluster on Kubernetes easier from a user perspective.
The CNP plugin for kubectl is becoming a Swiss Army knife tool for administrators who need to manage a Cloud Native PostgreSQL cluster inside Kubernetes.
One of the most important features on offer is the ability to show the status of a CNP cluster through the status subcommand, which will show a list of the cluster’s nodes and their conditions at any time.
The ‘promote’ command was introduced in the CNP plugin at the beginning of its implementation. In the next release, two more subcommands will be added: ‘status’ and ‘certificate’.
Installation is managed by a shell script that can be found here.
Ensure cURL is installed on the machine, then run the following command:
curl -sSfL \
https://github.com/EnterpriseDB/kubectl-cnp/raw/main/install.sh | \
sudo sh -s — -b /usr/local/bin
Find the full article here.
Conclusions
Hopla Technologies is a sales partner and professional service provider. EnterpriseDB (EDB) is mainly a software provider In its area of influence.
Hopla! Software acts as an EDB agent, detecting leads, working with these leads as a prospective client, selling subscriptions, providing professional services – the first and second level of support in the local language – and so on.
Hopla! Software can help companies to build strong solutions to digital transformation through open-source tools.
Data migration, moving from proprietary Database Management Systems to the open-source PostgreSQL is often a good move. Results can easily be measured according to three basic parameters: cost, flexibility, and customization ability. For more on Hopla! Software, take a look at the company’s website.
