Consul + CyberArk WIM: External CA for the service mesh

Every service in a Consul service mesh gets a short-lived TLS certificate that proves its identity. By default, Consul runs its own certificate authority to issue those certificates. That is convenient, but it also means the trust anchor for your entire mesh lives inside Consul rather than inside the PKI your security team already operates and audits. 

Consul Enterprise already supports Vault and AWS Certificate Manager as external certificate authorities (CAs) for Connect, its service mesh. Organizations that standardize on CyberArk instead can now also use CyberArk Workload Identity Manager (WIM), formerly Venafi Firefly, as its external CA. Service mesh identities are then anchored to a CA your security team already governs, while Consul continues to do what it does best: distribute and rotate workload certificates automatically. 

The result is simple: your service mesh, your CA, one trust anchor.  

What the CyberArk WIM integration is 

CyberArk Workload Identity Manager is a distributed issuer designed for high-volume, short-lived workload certificates. Consul integrates with it through the Connect CA provider-named pan-distributed issuer. 

The division of labor is straightforward: 

• CyberArk owns the PKI hierarchy: a root CA whose private key is protected in an HSM, and one or more subordinate CAs beneath it. The root is the stable anchor every workload ultimately trusts. 

• CyberArk WIM is the issuing intermediate. A subordinate CA delegates issuance authority to it, and it signs short-lived certificates on demand. 

• Consul submits certificate signing requests (CSRs) to WIM and distributes the resulting leaf certificates — together with the full issuing chain — to every proxy, agent, server, and gateway in the mesh, renewing them automatically before they expire. 

• The CyberArk Control Plane governs issuance policy and collects audit and issuance events from WIM, so your security team retains central policy and visibility over what the mesh issues. 

Here is that same flow end to end: A workload's sidecar gets its certificate through Consul, which requests it from CyberArk WIM and hands back the signed leaf with its full issuing chain. 

When to use it 

Reach for this integration when: 

• You already standardize on CyberArk or Venafi for PKI and want service mesh identities to live under the same root of trust. 

• Your security or compliance team needs the mesh CA to be a CA they govern and audit, not Consul-internal. 

• You want short-lived certificate issuance without running and protecting a separate signing key inside Consul. 

If you have no external PKI requirement, Consul's built-in CA remains the simplest option. This integration exists specifically to put your mesh under an existing CyberArk trust hierarchy. 

Prerequisites and supported topology 

To configure the provider, you need: 

Single datacenter 

In a single datacenter, Consul servers point at one CyberArk WIM endpoint. The WIM- issuing intermediate sits beneath a subordinate CA, which in turn chains to the HSM-protected root. Consul reads the CA chain to identify your CyberArk root as the trust anchor, submits CSRs to WIM, and distributes the issued leaf certificates to every sidecar. WIM streams issuance events to the CyberArk Control Plane for policy enforcement and audit. 

The proxies trust your CyberArk root. Every leaf Consul hands them is served together with the full issuing chain, so a verifying peer that trusts only the root can still build a complete path to it. 

Multiple datacenters 

For multiple datacenters, the supported model is cluster peering, where each datacenter runs its own WIM-backed Consul CA, all subordinate to the same CyberArk root. That topology is covered in its own section below. 

What the provider does 

• Authenticates to CyberArk WIM at startup and when configuration changes. 

• Learns your CyberArk root from the CA chain and uses it as the mesh trust anchor. 

• Submits certificate signing requests to WIM and distributes the issued leaf certificates, along with the issuing chain, to mesh workloads. 

• Tracks the issuing intermediate and reacts automatically when it changes. 

Configuration 

Configure the provider in the agent's connect stanza: 

connect { enabled = true ca_provider = "pan-distributed-issuer" ca_config { address = "https://wim.example.com:8002" chain_address = "https://wim.example.com:8008" token = "<short-lived-auth-token>" policy = "mesh-issuance-policy" tls_skip_verify = false } } 

The same configuration can be applied at runtime through the Connect CA configuration API: 

curl --request PUT \ --header "X-Consul-Token: <acl-token>" \ --data @- https://127.0.0.1:8500/v1/connect/ca/configuration <<'JSON' { "Provider": "pan-distributed-issuer", "Config": { "Address": "https://wim.example.com:8002", "ChainAddress": "https://wim.example.com:8008", "Token": "<short-lived-auth-token>", "Policy": "mesh-issuance-policy", "TLSSkipVerify": false } } JSON 

Configuration keys 

The auth token is intentionally short-lived. Plan to supply Consul with a freshly issued token whenever you re-apply the CA configuration and treat token rotation as a routine operational task rather than a one-time setup step. 

Authentication methods WIM supports 

The token in ca config isn't just an opaque secret — it's a JWT, and CyberArk WIM checks it against one of a small set of client authentication policies that a WIM administrator configures: 

Whichever policy your WIM administrator configures, Consul's job doesn't change: Present the token and let WIM decide whether to trust it. 

This is a separate hop from how WIM itself authenticates upstream to CyberArk Certificate Manager — that connection uses either OIDC/JWT (recommended, dynamic, Kubernetes-native) or a static username and password (for non-Kubernetes deployments). Don't confuse the two: One governs who WIM lets request certificates, the other governs how WIM itself proves its identity to the CA behind it.  

How certificates flow: roots, intermediates, leaves, and SPIFFE 

There are four layers of certificate in this model, and it helps to keep them distinct: 

Layer	Owner	Lifetime	Role
Root	CyberArk (HSM-protected key)	Long	Source：https://www.hashicorp.com/blog/consul-cyberark-wim-external-ca-for-the-service-mesh My favorites PreviousHCP Terraform is the control plane for AI-driven infrastructureNextTerraform AzureRM provider 5.0 now generally available Related posts All-in-one platform or a stack you assemble? Where do coaches and educators land? Every few days someone who teaches or coaches for a living asks a version of the same question: is the big all-in-one pl 0dev.to Discuss I Wanted to Live on Coruscant. PAT Scared Me. Now My Alexa Lives on Mute. As a kid, I wanted to live in Star Wars. Not visit. Live there. That feeling came back hard a while ago. I'd been playin 0dev.to Discuss Detect What You Can Name: PaliGemma 2 Object Detection with Transformers Detect What You Can Name: PaliGemma 2 Object Detection with Transformers TL;DR PaliGemma 2 can do prompt-driven object d 0dev.to Machine Learning When Should an LLM Router Stop Being Sticky? llm-d 1.0 Cache-Affinity Routing, Break-Even Math, and a Simulation TL;DR What shipped: llm-d 1.0 was announced on 2026-10-20 under CNCF governance, with vLLM and SGLang as supported model 0dev.to Machine Learning Understanding HackerTube: Karpathy’s Two-Hour Experiment in Better Recommendations HackerTube is a video discovery site built from YouTube links that people have shared on Hacker News over the years. And 0dev.to Machine Learning OpenAI Wants to Rename the Data Center. The Neighbours Are the Problem. OpenAI Wants to Rename the Data Center. The Neighbours Are the Problem. A renamed building draws the same power, uses th 0dev.to Machine Learning