11.4 Conjur Secrets Manager & Cloud-Native DevOps Workflows

11.4 Conjur Secrets Manager & Cloud-Native DevOps Workflows

Quick Answer: Conjur Secrets Manager (CyberArk Secrets Manager) is an enterprise secrets management solution purpose-built for DevOps pipelines, microservices, and container platforms (Kubernetes, OpenShift). It resolves the 'Secret Zero' challenge in containers through native Kubernetes Authentication (authn-k8s), which cryptographically validates Kubernetes Service Account tokens without pre-shared secrets. Conjur policies are managed as Policy-as-Code (YAML) in GitOps workflows. To unify enterprise PAM with DevOps velocity, the Vault-Conjur Synchronizer automatically replicates selected privileged accounts from Digital Vault Safes to Conjur branches in real time.

---

Conjur Secrets Manager in Cloud-Native & DevOps Ecosystems

Traditional Privileged Access Management (PAM) architectures were designed around static enterprise infrastructure: bare-metal servers, domain controllers, and human administrators. Modern cloud-native environments present fundamentally different operational dynamics:

• Ephemeral Workloads: Containers and microservices scale dynamically and terminate within minutes or seconds.
• High-Velocity Scale: Distributed applications execute tens of thousands of automated transactions per second, requiring lightweight, low-latency secret retrieval.
• Infrastructure as Code (IaC): Environments are continuously provisioned using Terraform and Ansible, which require programmatic access to cloud API keys and certificates.
• CI/CD Pipelines: Automated workflows (Jenkins, GitLab CI, GitHub Actions) require temporary credentials to build and deploy applications.

Conjur Secrets Manager provides an API-first platform securing non-human identities across multi-cloud and container environments while enforcing role-based access control (RBAC).

High-Availability Conjur Topology

• Conjur Leader (Master): The primary node handling policy evaluation, database writes, variable creation, and audit logging, paired with Standby nodes for automated failover.
• Conjur Followers: Horizontally scalable, read-only replicas deployed close to workloads (inside Kubernetes clusters or cloud VPCs). Followers handle client authentication and secret retrieval locally, offloading the Leader and providing localized sub-millisecond response times.

---

Native Kubernetes Workload Authentication (authn-k8s)

Securing container machine identities introduces the "Secret Zero" dilemma: for an ephemeral pod to authenticate to a vault, it historically required an initial bootstrap secret (API key or certificate) embedded in the image or ConfigMap, creating a security risk.

Conjur resolves Secret Zero through the Conjur Kubernetes Authenticator (authn-k8s), leveraging native platform identity primitives:

1. Pod Startup: When Kubernetes launches an application pod, it mounts a cryptographically signed Service Account Token (JWT) into the pod at /var/run/secrets/kubernetes.io/serviceaccount/token.
2. Authentication Request: The pod transmits an authentication request containing its Service Account JWT to the in-cluster Conjur Follower.
3. Cryptographic Validation: The Follower contacts the Kubernetes API server using the TokenReview API, which verifies the token signature and returns authenticated attributes (namespace, service account, pod name).
4. Policy Evaluation: Conjur validates pod metadata against declared policy and issues a short-lived, ephemeral access token (valid for 8 minutes).
5. Secret Retrieval: The pod uses this token to retrieve secrets over HTTPS from the local Follower.

Because authentication relies on native Kubernetes service account attestation, zero static secrets reside in container images or filesystems.

---

Secrets Consumption Patterns: Sidecar Injector vs. Secretless Broker

CyberArk provides two architectural patterns for consuming Conjur secrets in Kubernetes:

1. Sidecar Injector / Secrets Provider for Kubernetes

The CyberArk Secrets Provider for Kubernetes runs as an init container or sidecar inside the application pod:

• It authenticates via authn-k8s, fetches required secrets from Conjur, and writes them to an in-memory shared volume (emptyDir with medium: Memory).
• The application mounts the volume and reads secrets as files, or the provider synchronizes secrets directly into native Kubernetes Secret objects.
• Use Case: Applications expecting credentials in configuration files or environment variables.

2. Kubernetes Secretless Broker Pattern

The Secretless Broker is an advanced zero-trust pattern that completely abstracts secrets from application code:

• The Secretless Broker runs as a sidecar container alongside the application.
• The application connects to localhost on the database port (e.g., localhost:5432 for PostgreSQL) with no password provided.
• The Secretless Broker intercepts the connection locally, authenticates to Conjur, retrieves database credentials, injects them directly into the native protocol handshake (PostgreSQL, MySQL, MSSQL, HTTP), and proxies the connection to the remote database.
• Security Advantage: Application code and memory never see, hold, or touch the secret, eliminating exposure in crash dumps, logs, or application vulnerabilities.

---

Policy as Code & Declarative Security Governance

Conjur manages security policies, host identities, variable paths, and access permissions using Policy as Code written in declarative YAML files:

- !policy
  id: production/billing
  body:
    - !variable db-password
    - !layer webapp-tier
    - !host
      id: k8s-billing-app
      annotations:
        authn-k8s/namespace: production
        authn-k8s/service-account: billing-sa
    - !grant
      role: !layer webapp-tier
      member: !host k8s-billing-app
    - !permit
      role: !layer webapp-tier
      privileges: [read, execute]
      resource: !variable db-password

GitOps Integration

Policies are stored in Git repositories, code-reviewed, and deployed via CI/CD pipelines using the Conjur CLI (conjur policy load -b root -f policy.yml). This ensures complete auditability and repeatable provisioning.

---

Vault-Conjur Synchronizer: Unifying PAM & DevOps

The CyberArk Vault-Conjur Synchronizer bridges enterprise PAM governance and cloud-native DevOps:

• PAM Governance: Privileged accounts are managed and rotated by the Central Policy Manager (CPM) in the Digital Vault.
• DevOps Velocity: Cloud-native microservices consume secrets dynamically from Conjur.

How Synchronization Operates

1. Safe Selection: Administrators assign the Synchronizer identity (ConjurSync) to designated Safes.
2. Variable Mapping: The Synchronizer queries the Vault over TCP 1858 and maps accounts into Conjur variable trees: vault/<SafeName>/<ObjectName>/password.
3. Real-Time Replication: When CPM rotates an account in the Vault, the Synchronizer pushes the updated secret to the Conjur Leader over HTTPS port 443, which replicates it to all Followers within seconds.
4. Unified Value: Central security teams retain full compliance in the Vault while microservices consume up-to-date credentials from Conjur.

---

Conjur Secrets Manager vs. AAM Credential Provider (CP/CCP)