Attribute redaction

Overview

Attribute redaction is a security feature in Defakto that allows you to control which workload attributes are sent by the Agent to the Signer when a workload requests an SVID. By default, the Agent sends all attributes it is configured to collect.

When attribute redaction is configured, only the attributes that match a specific allowlist are sent.

Why attribute redaction?

During workload attestation, Defakto collects various attributes about the workload from different sources (e.g., Kubernetes pod metadata, process information, custom attestors). While these attributes are valuable for identity composition and authorization decisions, you may want to limit which attributes are provided to the Signer:

• Minimize information exposure: Reduce the amount of potentially sensitive operational data sent to Defakto components, where they are routinely stored or logged.
• Compliance requirements: Meet data minimization or information disclosure policies.
• Security hardening: Limit routine transmission of infrastructure details that could aid attackers.
• Performance optimization: Exclude unnecessary attributes from the system.

How it works

Attribute redaction uses an allow-list policy approach:

1. During workload attestation, Defakto collects all available attributes from configured attestors
2. The attribute redactor evaluates each attribute against configured filter patterns
3. Only attributes matching at least one filter in the allow-list are included in the SVID
4. All other attributes are redacted (removed)
5. Redacted attribute names are logged for audit and troubleshooting purposes

Important: If no attribute redaction policy is configured, all attributes are allowed by default.

Configuration

Redaction is easiest to enable using the agent or server Helm charts, by adding a redaction configuration to values.yaml:

Agent Helm chart

agent:
  allowedAttributes:
    - kubernetes.pod.namespace
    - kubernetes.pod.name
    - kubernetes.pod.label.'example.org/foo'

Server Helm chart

trustDomainDeployment:
  allowedAttributes:
    - kubernetes.pod.namespace
    - kubernetes.pod.name
    - kubernetes.pod.label.'example.org/foo'

Non-Kubernetes agent

Outside of Kubernetes, redaction is enabled by can also be passing allowed attributes to the agent as arguments:

spirl-agent --allowed-attributes=kubernetes.pod.namespace \
            --allowed-attributes=kubernetes.pod.name

Syntax

Filters operate on attribute names, with some basic wildcard support.

Attribute names

Attribute names are hierarchical, separated by dots (.). For example:

• kubernetes.pod.name
• kubernetes.pod.namespace
• linux.user.id

Wildcard characters

Filters support two wildcard characters:

• * — Matches zero or more characters within a segment
• ? — Matches exactly one character

Special characters in attribute names

For attribute names containing special characters or requiring literal wildcards, use quotes:

# Basic quoted key
kubernetes.pod.label.'app.kubernetes.io/name'

Examples

Filter Pattern	Matches	Does Not Match
kubernetes.pod.namespace	kubernetes.pod.namespace	kubernetes.pod.name kubernetes.container.name
kubernetes.pod.label.'app.kubernetes.io/name'	kubernetes.pod.label.'app.kubernetes.io/name'	kubernetes.pod.namespace kubernetes.pod.name kubernetes.container.name
kubernetes.pod.*	kubernetes.pod.name kubernetes.pod.namespace	kubernetes.container.name kubernetes.container.image.id kubernetes.pod.label.'app.kubernetes.io/name'
kubernetes.*.*	kubernetes.pod.name kubernetes.pod.namespace kubernetes.container.name	kubernetes.container.image.id kubernetes.pod.label.'app.kubernetes.io/name'
kubernetes.*.*	kubernetes.pod.name kubernetes.pod.namespace kubernetes.container.name	kubernetes.container.image.id kubernetes.pod.label.'app.kubernetes.io/name'
kubernetes.*.*.*	kubernetes.container.image.id kubernetes.pod.label.'app.kubernetes.io/name'	kubernetes.pod.name kubernetes.pod.namespace kubernetes.container.name
*.*.*	kubernetes.pod.name linux.user.id	kubernetes.container.image.id kubernetes.pod.label.'app.kubernetes.io/name'

Example configurations

Example 1: Allow only the Kubernetes namespace

This configuration allows only the Kubernetes namespace attribute, redacting all other attributes:

agent:
  allowedAttributes:
    - kubernetes.pod.namespace

Result: Only kubernetes.pod.namespace are available for inclusion in SVIDs, depending on the SPIFFE ID path template, X.509-SVID customization or JWT-SVID customization. All other attributes (pod name, labels, annotations, service account, etc.) are redacted.

Example 2: Allow multiple specific attributes

Allow specific Kubernetes pod attributes while redacting everything else:

agent:
  allowedAttributes:
    - kubernetes.pod.namespace
    - kubernetes.pod.name
    - kubernetes.pod.service_account

Example 3: Allow all Kubernetes pod attributes

Use wildcards to allow all kubernetes.pod.* attributes:

agent:
  allowedAttributes:
    - kubernetes.pod.*

Result: Includes kubernetes.pod.namespace, kubernetes.pod.name, kubernetes.pod.uid, kubernetes.pod.service_account, and any other single-segment attributes under kubernetes.pod.*

Example 4: Allow attributes from different sources

Combine multiple filter patterns to allow attributes from different sources:

agent:
  allowedAttributes:
    - kubernetes.pod.namespace
    - kubernetes.pod.service_account
    - custom.team
    - custom.environment

Operational considerations

Monitoring redacted attributes

When attributes are redacted, Defakto logs the names of redacted attributes. Monitor these logs to:

• Verify redaction is working as expected.
• Identify attributes being collected but not used.
• Troubleshoot identity issues related to missing attributes.

Here is an example of expected log output when the agent starts up and attribute redaction is enabled:

{"level":"info","ts":1768412301.062683,"logger":"agent","msg":"Configuring attribute redaction","allowedAttributes":["kubernetes.pod.*"]}
...
{"level":"info","ts":1768412917.3720434,"logger":"agent.configUpdater","msg":"Updating configuration cache","snapshot":{"attributeRedactor":{"allowList":{"filters":[{"pattern":"kubernetes.pod.*"}]}}},"overridden":["AttributeRedactor"]}

Here is example log output for an SVID request when attribute redaction is enabled:

{"level":"info","ts":1768413010.1664147,"logger":"agent.endpoints.x509svid-source.1","msg":"Attestation finished","callerPID":2601,"attributesChanged":true,"attributes":["kubernetes:kubernetes.pod.name=\"spiffe-demo-app-78b84dfcdb-jqxvf\"","kubernetes:kubernetes.pod.namespace=\"spiffe-demo\"","kubernetes:kubernetes.pod.service_account=\"spiffe-demo-app\"","kubernetes:kubernetes.pod.uid=\"30d90bd4-f0bb-49c7-9037-cd287cb2311b\""],"redactions":["linux.group.id","linux.group.name","linux.user.id","linux.user.name","kubernetes.pod.container.spiffe-demo-app.image.id","kubernetes.pod.container.spiffe-demo-app.image.name","kubernetes.pod.label.app","kubernetes.pod.label.\"k8s.spirl.com/spiffe-csi\"","kubernetes.pod.label.pod-template-hash","kubernetes.pod.node.name"],"sentryTraceID":"8cf76a7b985e4593f9fc066e2af3d716"}

Impact on authorization

If your authorization policies for other systems rely on specific workload attributes in SVIDs, ensure those attributes are included in your allow-list. Redacting attributes used by authorization policies will cause authorization failures.

Testing configurations

1. Start permissive: Begin with broader filters (e.g., kubernetes.pod.*) and narrow as needed.
2. Test incrementally: Apply changes to a single cluster first before rolling out organization-wide.
3. Monitor logs: Watch for redacted attributes that should be included.
4. Validate authorization: Ensure dependent authorization policies continue to work.

Troubleshooting

Problem: Authorization failures after enabling redaction

Cause: Authorization policies depend on attributes that are now being redacted.

Solutions:

1. Review authorization policy requirements.
2. Add necessary attributes to the allow-list.
3. Modify authorization policies to use non-redacted attributes.

Problem: Too many attributes still included

Cause: Overly broad filter patterns (e.g., *.* or kubernetes.*.*)

Solution: Use more specific patterns matching only required attributes.

Problem: Configuration rejected with validation Error

Cause: Invalid filter syntax or empty array

Solution:

1. Check filter patterns for invalid characters.
2. Ensure at least one filter is specified.
3. Test filter patterns against attribute names you want to match.

Related configuration

Attribute redaction works in conjunction with:

• SPIFFE ID Templates: Determines which attributes are used in SPIFFE ID construction
• X.509-SVID customization: May reference attributes for certificate extensions
• JWT-SVID customization: Ensure these configurations are aligned with your attribute redaction policy.