CyberArk AAM, CCP & Conjur — Killing Hardcoded Secrets in Apps & DevOps

B1 · The wrong answer almost everyone gives first

In an interview, the question lands: "A password is hardcoded in your app. How do you fix it?"
The reflex answer — "move it to an environment variable" or "put it in a Kubernetes Secret" — feels right and is wrong. An env var still sits in the Deployment YAML that gets committed to Git. A Kubernetes Secret is base64, not encryption; anyone with kubectl get secret reads it in cleartext. You haven't removed the secret — you've just moved where it leaks from.

The real answer: the app should hold no secret at all. It proves who it is — its server IP, its OS user, its binary hash, or its Kubernetes ServiceAccount token — and a vault hands it the secret just-in-time, then logs who asked. That is what CyberArk AAM, CCP and Conjur do. Hold that thought; we'll prove it end-to-end.

💡 The debit-card-PIN analogy (why a secret in code is a disaster)

Hardcoding a database password in your code is like writing your ATM PIN on your debit card in permanent marker. Every colleague who borrows the card, every shoulder-surfer who glances at your screen, the office boy who tidies your desk — all of them now know your PIN. And you cannot change it without re-printing the card (re-deploying every app).

CyberArk replaces the written PIN with a fingerprint reader. Your identity — the app server's IP plus binary hash, or a Kubernetes pod's ServiceAccount token — is cryptographically unique and never written down anywhere. The vault opens only for the right finger. Even if someone watches the whole authentication ceremony, they can't replay it, because the token Conjur issues expires in minutes. That is the entire mental model for this lesson.

4 terms you'll see all lesson — tap to flip

① The hardcoded-secret problem — and what "vaulted" really means

Secrets get hardcoded because it's the path of least resistance. A developer copies a working local config to production, forgets to strip the password, and the line spring.datasource.password=S3cur3DB!Pass rides along into Git. Now the secret lives in four places at once: the running config, the repo, every developer's clone, and the CI/CD logs that printed it.

"Vaulted" means the password is stored once in a CyberArk Safe, rotated automatically by CPM, and handed to the app at runtime over an authenticated channel. The before/after below is the whole point of this lesson.

② CP vs CCP — local agent or agentless REST?

CyberArk gives you two ways to fetch a Vault secret into a traditional app. The Credential Provider (CP) is a local agent you install on each app server. It talks straight to the Vault on TCP 1858 and keeps an encrypted local cache. The Central Credential Provider (CCP) is agentless: you install it once on a Windows IIS box, and apps call its REST service — AIMWebService — over HTTPS.

③ Application authentication — proving identity without a stored secret

Here's the part that confuses people: if the app holds no password, how does CyberArk know it's the real app and not an attacker on the same network? The answer is that CP and CCP validate who is calling at every single request, across four dimensions. You combine at least two.

1. Allowed Machines — the caller's IP, hostname or CIDR must match a stored list. 2. OS User — the process owner (e.g. app_runner) must match. 3. Hash — CP computes the SHA hash of the application binary at runtime and compares it to the stored hash, so a tampered executable is refused. 4. Certificate Thumbprint — for CCP, the caller presents a client TLS cert validated against a stored thumbprint. CP additionally supports Path-based checks on Windows.

Here's the actual CCP REST call Rohan's app makes — with client-certificate auth, the recommended pairing with Allowed Machines:

curl --cert /etc/ssl/app-client.pem \
     --key  /etc/ssl/app-client.key \
     --cacert /etc/ssl/cyberark-ccp-ca.pem \
  "https://10.0.5.20/AIMWebService/api/Accounts?AppID=finedge-txn-service&Safe=FinEdge-Prod-DB&Object=postgres-prod-account"

{
  "Content": "S3cur3DB!Pass2025",
  "UserName": "app_db_user",
  "Address": "10.2.1.55",
  "Database": "transactions_prod",
  "PasswordChangeInProcess": "false"
}

④ Conjur — secrets for Kubernetes, CI/CD and policy-as-code

Traditional app servers are handled by CP and CCP. But a Kubernetes microservice has no fixed server to install an agent on, and its "identity" is a pod that may live for 90 seconds. Conjur (now branded Secrets Manager) is built exactly for this. Authorization is policy-as-code in Git, and a workload authenticates with its machine identity, not a password.

The magic is the Kubernetes authenticator (authn-k8s). The pod proves identity with no stored secret at all. Press Play to watch it.

Policy-as-code — the secret is separate from the rule

In Conjur, the authorization rules live in YAML you commit to Git, and the secret value is set separately. A reviewer can read the policy without ever seeing the password. Priya defines each microservice as a !host, the secret as a !variable, and grants read with !permit:

# db-policy.yml
# - !policy
#   id: prod-db
#   body:
#   - !variable password
#   - !host payment-service
#   - !permit
#     role: !host payment-service
#     privilege: [ read, execute ]
#     resource: !variable password

conjur policy load -b root -f db-policy.yml
conjur variable set -i prod-db/password -v 'S3cur3DB!Pass2025'
conjur variable get -i prod-db/password

Loaded policy 'root'
(no output — secret stored)
S3cur3DB!Pass2025

On the Kubernetes side, you add the Secrets Provider as an init container and describe everything in pod annotations. Push-to-File mode keeps the secret in tmpfs, out of etcd:

metadata:
  annotations:
    conjur.org/authn-identity: host/prod/payment-service
    conjur.org/container-mode: init
    conjur.org/secrets-destination: file
    conjur.org/conjur-secrets.payment: |
      - DB_PASSWORD: prod-db/password
      - RAZORPAY_KEY: payments/razorpay-api-key
    conjur.org/secret-file-path.payment: /run/secrets/app-secrets
spec:
  serviceAccountName: payment-service-sa
  volumes:
  - name: conjur-secrets
    emptyDir:
      medium: Memory   # tmpfs — never lands on disk

# init container writes /run/secrets/app-secrets:
# DB_PASSWORD: S3cur3DB!Pass2025
# RAZORPAY_KEY: rzp_live_xxxxxxxxxxxx
# main container reads the file; no K8s Secret object; nothing in etcd

Conjur in the pipeline — Summon, Jenkins, Terraform

The same engine secures CI/CD. CyberArk's Summon tool reads a secrets.yml that maps env-var names to Conjur paths, fetches the values at runtime, and injects them into a subprocess. Your Terraform run gets real AWS keys without any secret file on disk.

# secrets.yml (safe to commit — no values, only paths)
# AWS_ACCESS_KEY_ID:     !var aws/prod/access-key-id
# AWS_SECRET_ACCESS_KEY: !var aws/prod/secret-access-key
# TF_VAR_db_password:    !var database/prod/master-password

export CONJUR_APPLIANCE_URL=https://conjur.internal.corp
export CONJUR_AUTHN_LOGIN=host/terraform/frontend-01
summon -f secrets.yml terraform apply -auto-approve

# Summon fetches from Conjur at runtime and injects as env vars (never echoed):
#   AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, TF_VAR_db_password
Apply complete! Resources: 3 added, 0 changed, 0 destroyed.
# Values are gone from memory when Terraform exits; never written to any file

A Bangalore startup asks: "15 Spring Boot microservices on Kubernetes — CCP or Conjur?" CCP is IIS-centric and would force every pod to present a client certificate, which is painful to manage at scale. For greenfield K8s, Conjur is the architecturally correct choice: it understands pod identity via the ServiceAccount JWT, runs as an init container with no app code change, enables policy-as-code in Git, rotates secrets without restarting pods, and keeps secrets out of etcd. CCP still earns its place for the legacy monolith app servers not yet containerized.

The 5 mistakes that get juniors burned in production