To meet the speed, reliability, and security requirements of the modern world, enterprise development teams must change their tools, methods, and application delivery practices. Gone are the long, drawn-out waterfall-based SDLCs that produce monolithic, hard-to-change applications. They have been replaced by new methods that rely on portable, scalable, lightweight, and reusable containers that package code, libraries, configuration files, and all other dependencies – enabling software to run reliably in multiple environments. By abstracting the underlying host infrastructure from the application platform, containers allow DevOps teams to easily compile applications to run in dev, prod, staging, or test environments – saving time and resources, and accelerating release cycles.
To manage and orchestrate containers that are deployed across multiple machines, teams use Kubernetes – an open source engine that offers services for scheduling and deploying containers, and scaling them based on utilization. Docker is perhaps the most widely used tool for placing software into containers. A number of public repositories, such as Docker Hub, exist to facilitate the sharing of containers between teams.
For authentication, Kubernetes requires PKI certificates – both to run the cluster (thus enabling communication between container functions) and to encrypt the traffic passing within the application that runs inside the container. (For details on which certificates are required by a cluster, click here.)
If you use kubeadm – a tool for creating Kubernetes clusters, the required certificates are generated automatically. Security-conscious teams also have the option of generating their own certificates and configuring them for user accounts.
Security challenges in containerized environments
Container security can get complicated, mostly because containers themselves are more complex than traditional deployment environments. Most organizations run multiple container images, with multiple instances of each image – inadvertently creating a single point of failure: when one container environment is compromised, all applications within each instance are at risk.
While generating certificates, security teams often don’t follow standard practices – some certificates are acquired from public CAs, while others are generated in-house. This lack of uniformity can put the PKI infrastructure at risk, especially given the lack of communication between security engineers, developers, and other IT teams.
What’s more, certificate renewals and application updates are not synchronized, creating potential security vulnerabilities. If application updates are typically released on a bi-weekly or monthly cycle, certificates are renewed annually – a disconnect which can result in serious problems for organizations. When legacy applications are no longer updated, but are still in use, security teams still need to remember to renew their certificates, which can be problematic – given that most organizations still store their certificates in spreadsheets or homegrown applications, without a consistent process for managing their inventory and monitoring for expiry dates.
Organizations need an efficient and reliable mechanism for deploying certificates and keys for applications hosted in a container infrastructure.
The solution? Automation.
AppViewX CERT+ offers enterprise-grade certificate lifecycle automation
The AppViewX CERT+ platform helps enterprises discover and manage certificates, and automate the entire lifecycle of their internal and external PKI in multi-cloud and containerized environments. Automated end-to-end Certificate Lifecycle Management (CLM) is quickly replacing manual processes through integration with a number of key native certificate management tools.
Issuing certificates to cert-manager based on policy configured on AppViewX
cert-manager is an OpenShift and Kubernetes certificate management controller tool. It acts as an ACME client and can be used for certificate enrollment and management functions. AppViewX CLM offers an ACME server implementation, which can issue certificates to the ACME client, based on enrollment requests from the client.
Managing secrets and protecting sensitive data with HashiCorp Vault
HashiCorp Vault secures and controls access to tokens, passwords, certificates, and keys for protecting sensitive data in a dynamic infrastructure. Vault applies a dynamic secret approach to public key certificates, acting as a signing intermediary to generate short-lived certificates. This allows certificates to be generated on-demand and rotated automatically.
Organizations can set up their own internal root CA or intermediate CAs to sign certificates issued via Vault. It uses a PKI secret engine to store certificates, keys, and CSRs. AppViewX has configuration properties to act as a RA between the Vault (to route the certificate signing request calls) and the CA, using precise policy definitions. Container certificate requirements are managed in a more secure fashion, compared to hosting the CA internally.
Certificate Management on ISTIO
A service mesh is a dedicated infrastructure layer that helps control how parts of an application (services that perform different functions) interact and share information. It is designed to route requests for data between services to improve communication and optimize application performance. The best-known open source service mesh platform is Istio – it manages authentication, authorization, and encryption of service communication, allowing organizations to secure service-to-service communication at the network and application layers. Within Istio’s control panel is a certificate generation component, called Citadel.
With Istio, there are two types of certificate requirements:
– mTLS encryption & authentication – control and data plane object encryption
– Encrypt the Ingress traffic – to access the application from outside.
AppViewX offers an Istio-CERT+ plugin, which can be set up as a part of Istio mesh configuration on Kubernetes.
– Istio-CERT is a modified Citadel plugin that is available as a control pane function
– It functions using a modification to the call that istiod makes from the in-house CA, without affecting the way that a mesh requests certificates
– AppViewX adds value by selecting the CA and policy through which the certificate needs to be issued
When using an Istio mesh with the Istio-CERT+ plugin, all control pane and data plane functions get encrypted with AppViewX (Registration Authority) issued certificates, providing the mTLS encryption required to secure communication within the mesh.
Each time a new application service gets spun off on a data plane, a new certificate requests from Istio agent on a service mesh is routed to the istiod function within the control pane. Istio-CERT recognizes this request and forwards it to AppViewX, which in turn issues a certificate to the proxy within the application mesh.
The certificates are stored with the proxy (Envoy), where they can be read to access the application. AppViewX is also able to support the encryption of the Envoy proxy through Symmetric Key Encryption, or by providing a Vault within it.
As organizations of all types and sizes switch to component-based application delivery, they need to be mindful of potential security risks. The main advantages of the container infrastructure: scalability and ease of deployment, can become its greatest vulnerabilities if encrypted communication is not properly orchestrated and managed. Most vendors who offer certificate management solutions do not have the ability to support certificate lifecycles within containers. Increasingly, security-conscious enterprises are choosing AppViewX for its ability to provide certificate automation and orchestration capabilities through seamless integration with the tools and processes used by DevOps teams to deploy and run cloud-native, container-based applications.