Kubernetes Sidecar Architecture

The illustration shows an example of a Kubernetes architecture implementation.

In studying the diagram, it would be easy to mistakenly conclude that the Kubernetes Secrets Manager is being used to store the pods’ secrets, which is not the case. The action of Kubernetes Secrets Manager here is to distribute TLS certificates to secure the connection between the VP-DV broker and sidecar agent, in cases where this is desirable. In most cases this would be unnecessary since the user cluster will typically be secured already.

If secrets were to be stored in Kubernetes Secrets Manager, they would be universally available in the cluster, contrary to the goal. Instead, with the VP-DV broker and the volume mount sharing depicted in the diagram, each pod sees only its own secrets, and secrets remain available as long as the pods are healthy.

The sidecar Kubernetes integration to Verify Privilege DevOps Vault consists of several images available from Docker. These illustrate how to build containers incorporating Verify Privilege DevOps Vault functionality. To obtain these images, at your Docker command line, use docker pull commands for each image:

docker pull thycotic/dsv-k8s-controller:latest
docker pull thycotic/dsv-k8s-client:latest

Kubernetes helps coordinate containerized applications across a cluster of machines. Verify Privilege DevOps Vault (VP-DV) integrates with any existing Kubernetes application deployment. This article, with reference to the example YAML code, explains how you would use the provided client and broker YAML to implement the VP-DV application with your cluster.