📌 Work ID Configuration

Control Core supports optional cryptographic workload identity (Work ID). When enabled, policies can authorize based on verified workload identity in addition to user attributes.

📌 When to Use

Service-to-service authorization: Require mTLS with verified workload identity for internal APIs
Zero-trust architecture: Verify workload identity, not just network location
Compliance: Meet requirements for cryptographic attestation (SOC 2, PCI DSS, HIPAA, etc.)

📌 Prerequisites

Control Plane and Bouncer deployed
Work ID supported in your deployment (Docker Compose or Helm)

📌 Enabling Work ID

1. Control Plane

Set these on the Control Plane:

Setting	Description	Example
Work ID enabled	Enable workload identity	`true`
Trust domain	Organizational identity boundary	`controlcore.yourcompany.com`
Work ID server port	Port for identity service	`8081`

Restart the Control Plane. The Work ID server starts automatically.

2. Generate Join Token

Generate a join token from the Control Plane. The exact command is provided in your deployment package. The token is valid for a short period.

3. Bouncer Configuration

Set these on each bouncer:

Setting	Description
Work ID enabled	Enable workload identity
Work ID server address	Control Plane host
Work ID server port	Typically 8081
Trust domain	Same as Control Plane
Join token	Token from step 2

Restart the bouncers. Each bouncer will attest and obtain workload identity.

4. Automatic Registration (Optional)

After bouncers attest, configure the Control Plane for automatic workload registration when bouncers register. Refer to your deployment package for the specific setting.

📌 Using Workload Identity in Policies

When Work ID is enabled, policies receive a workload identity attribute. Use it to require verified identity for sensitive endpoints or to restrict access to trusted bouncers.

Example Policy

package controlcore.my_policy

import rego.v1

default allow := true

# Require verified workload identity for internal endpoints
allow := false if {
  startswith(input.resource.path, "/internal")
  not input.workload.spiffe_id
}

# Allow only trusted bouncers
allow := true if {
  input.workload.spiffe_id
  startswith(input.workload.spiffe_id, "spiffe://your-trust-domain.example/bouncer/")
}

Checking for Workload Identity

has_workload_identity if {
  input.workload.spiffe_id
  startswith(input.workload.spiffe_id, "spiffe://")
}

The workload identity format follows the standard URI pattern for your trust domain.

📌 Default Behavior

When Work ID is disabled (default):

Work ID server does not run
input.workload is not present in policies
All existing policies continue to work unchanged
Full backward compatibility

🛠️ Troubleshooting

Bouncer not attesting: Ensure the join token is set and has not expired. Generate a new token if needed.

No workload identity in policies: Verify Work ID is enabled on both Control Plane and Bouncer, and that the bouncer has successfully attested.

Connection failed: Check network connectivity from bouncer to Control Plane on the Work ID port.

Policy Guidelines - Policy language reference
Bouncer Deployment - Bouncer setup
Cryptographic Workload Identity - Security and compliance overview
Security Best Practices - General security guidance