Actor Security Essentials

Your TaskActor is working beautifully. It persists conversation history, fires deadline reminders, and scales across your Kubernetes cluster. Then your security team asks the questions that keep production systems trustworthy: "Is the state encrypted at rest? How do we know actor-to-actor calls are secured? Who accessed which actor and when?"

These aren't theoretical concerns. In November 2024, a misconfigured Redis instance exposed 1.1 million customer records because state wasn't encrypted and access wasn't logged. The organization had built sophisticated business logic but overlooked fundamental security controls.

Dapr provides the building blocks for zero-trust actor security, but they require configuration and verification. This lesson transforms your development-ready actors into production-hardened systems that security teams can approve.

The Actor Threat Model

Before configuring security controls, you need to understand what you're protecting against. Actors have a specific threat surface that differs from traditional microservices.

Where Sensitive Data Lives

Actor-Specific Threats

Actors introduce unique considerations beyond typical microservice security:

Identity-Based Attacks: Each actor has a unique ID (e.g., TaskActor/task-123). An attacker who learns your ID scheme can attempt to invoke arbitrary actors.

State Poisoning: Unlike stateless services, actors persist state. Compromised state affects all future interactions with that actor.

Reminder/Timer Manipulation: If an attacker can register reminders, they can trigger actor methods at will.

Placement Service Trust: The placement service routes actor calls. A compromised placement service could redirect traffic.

State Encryption Configuration

Dapr doesn't encrypt state by default. Your actor state sits in Redis (or your configured store) in plaintext. Anyone with database access can read it.

Understanding the Encryption Model

Dapr implements client-side encryption using AES in Galois/Counter Mode (GCM). This means:

• Encryption happens in the Dapr sidecar, before data reaches the state store
• The state store never sees plaintext data
• You control the encryption keys through a secrets component

Supported key sizes: 128, 192, or 256 bits. Dapr documentation recommends 128-bit keys for optimal performance with strong security.

Generating Encryption Keys

Create a 128-bit hex-encoded encryption key:

Output:

Store this key in a Kubernetes secret:

Configuring the Encrypted State Store

Update your state store component to enable encryption:

Key points:

• Encryption keys must come from a secrets component (never plaintext in YAML)
• The actorStateStore: "true" flag enables actor-specific optimizations
• Keys must be valid hex-encoded values

Key Rotation Strategy

Production systems need key rotation. Dapr supports primary and secondary keys for zero-downtime rotation.

Rotation process:

1. Generate new encryption key
2. Add new key to secrets as new-primary-key
3. Update component: new key as primary, old key as secondary
4. Restart pods to pick up new configuration
5. Dapr automatically identifies which key encrypted each state item
6. New writes use primary key; reads work with either key
7. After sufficient time, remove secondary key

Important: Data encrypted with the old key is not automatically re-encrypted. If you need full re-encryption, your application must read and write each state item.

Verifying Encryption

Check that state is actually encrypted in Redis:

Without encryption (BAD):

With encryption (GOOD):

The encrypted value includes a prefix identifying which key encrypted it, enabling the rotation strategy.

mTLS Verification

Dapr enables mTLS by default through the Sentry service. But "enabled by default" doesn't mean "working correctly." You need to verify.

Understanding Dapr's mTLS Architecture

Each sidecar gets a unique certificate from Sentry. Actor-to-actor calls (via ActorProxy) go through the sidecars with mutual TLS authentication.

Verifying Sentry is Running

Expected output:

If Sentry isn't running, mTLS is not functional.

Checking mTLS Configuration

Look for the mTLS section:

Key settings:

• enabled: true - mTLS is active
• workloadCertTTL - How long workload certificates are valid (default 24h)
• allowedClockSkew - Tolerance for time differences between nodes

Verifying Certificate Status

Check the Sentry logs for certificate operations:

Look for:

Warning signs (30 days before root certificate expiration):

Certificate Rotation

Dapr self-signed certificates are valid for one year. Before expiration, rotate them:

Critical: Always sign new certificates with the same private root key to avoid service disruption.

API Token Authentication

For additional defense-in-depth, configure API token authentication for actor invocations.

Configuring API Tokens

Create a token secret:

Update your deployment annotations:

Client Configuration

Clients must include the token in requests:

Audit Logging Implementation

Security teams need to know: Who accessed which actor? When? What method did they call? What changed?

Structured Audit Log Format

Implement audit logging in your actor methods:

Output (JSON log line):

SIEM Integration Considerations

For security monitoring tools (Splunk, Elastic SIEM, Azure Sentinel):

Security-Sensitive Operations

Certain operations warrant enhanced logging:

Security Checklist for Production Actors

Before deploying actors to production, verify:

Security is Non-Negotiable

Production actor deployments without security controls create real business risk:

• Unencrypted state: One database breach exposes all customer data
• Missing mTLS: Network attackers can intercept actor communications
• No audit logs: Security incidents become undetectable and uninvestigable

These aren't theoretical concerns. Implement security controls before your first production deployment, not after an incident.

Reflect on Your Skill

Test your dapr-deployment skill with security scenarios:

Prompt 1: "Using my dapr-deployment skill, configure state encryption for my TaskActor with key rotation support."

Evaluate whether your skill:

• Generates valid component YAML with secretKeyRef (not plaintext keys)
• Includes both primary and secondary encryption key configuration
• Explains the rotation process correctly

Prompt 2: "How do I verify mTLS is working for actor-to-actor communication in my Kubernetes cluster?"

Evaluate whether your skill:

• Provides specific kubectl commands for verification
• Explains what to look for in Sentry logs
• Mentions certificate expiration monitoring

Prompt 3: "Generate audit logging code for my TaskActor that's suitable for SIEM integration."

Evaluate whether your skill:

• Produces JSON-structured logs (not plain text)
• Includes standard fields for SIEM parsing
• Logs security-relevant context (actor ID, method, timestamp)

Try With AI

Setup: Have your TaskActor implementation and Kubernetes cluster ready.

Prompt 1: Threat Model Analysis

What you're learning: How to apply security thinking systematically to actor deployments, identifying threats before they become incidents.

Prompt 2: Encryption Configuration

What you're learning: The complete workflow from key generation through verification, not just isolated configuration snippets.

Prompt 3: Production Security Audit

What you're learning: How to conduct security reviews of actor configurations, identifying gaps between development-ready and production-ready deployments.

Safety reminder: Never commit encryption keys, API tokens, or certificates to version control. Use Kubernetes secrets, external secrets management (Vault, AWS Secrets Manager), or sealed secrets for all sensitive configuration.

Sources:

• Dapr State Encryption Documentation
• Dapr mTLS Setup Guide
• Dapr Security Concepts
• Zero Trust Security with Dapr - Diagrid Blog