Attribute Redaction

Attribute redaction lets you control which workload attributes the agent sends to the Trust Domain Server when a workload requests an SVID. By default, all collected attributes are sent. When redaction is configured, only attributes matching an allowlist are forwarded — all others are dropped at the agent.

Why use attribute redaction?

• Minimize exposure — Reduce the amount of operational data transmitted to Trust Domain Server infrastructure, where it may be logged.
• Compliance — Meet data minimization policies.
• Security hardening — Avoid routine transmission of infrastructure details that could aid an attacker.

How to Deploy

Update cluster configuration

Configure the AttributeRedaction section to define the allowlist:

section: AttributeRedaction
schema: v1
spec:
  policy:
    allowList:
      filters:
        - kubernetes.pod.namespace
        - kubernetes.pod.name
        - kubernetes.pod.service_account

Apply it:

spirlctl config set cluster --id <cluster-id> attribute-redaction.yaml

The configuration propagates to all agents in the cluster. Agents reload it without restart.

Verify

When attribute redaction is active, the agent logs redacted attribute names at each SVID request:

{"msg":"Attestation finished","attributes":["kubernetes:kubernetes.pod.namespace=\"production\""],"redactions":["linux.user.id","linux.group.id","kubernetes.pod.label.app"]}

Filter Syntax

Filters operate on attribute names. Attribute names are dot-separated paths (e.g., kubernetes.pod.name).

Wildcards

Character	Meaning
*	Matches zero or more characters within a segment
?	Matches exactly one character

Quoting special characters

For attribute names that contain dots or slashes within a key (e.g., Kubernetes labels), quote the segment:

- kubernetes.pod.label.'app.kubernetes.io/name'

Filter examples

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

Multiple filters use OR logic: an attribute is allowed if it matches any filter.

Example Configurations

Allow specific attributes only

section: AttributeRedaction
schema: v1
spec:
  policy:
    allowList:
      filters:
        - kubernetes.pod.namespace
        - kubernetes.pod.name
        - kubernetes.pod.service_account
        - custom.team
        - custom.environment

Allow all pod-level Kubernetes attributes

section: AttributeRedaction
schema: v1
spec:
  policy:
    allowList:
      filters:
        - kubernetes.pod.*

This includes kubernetes.pod.name, kubernetes.pod.namespace, kubernetes.pod.uid, kubernetes.pod.service_account, and other single-segment attributes under kubernetes.pod.*. It does not include kubernetes.pod.label.* or kubernetes.container.*.

Allow attributes from multiple origins

section: AttributeRedaction
schema: v1
spec:
  policy:
    allowList:
      filters:
        - kubernetes.pod.*
        - aws_iid.account.id
        - aws_iid.ec2.instance.region
        - custom.*

Security Considerations

• If no AttributeRedaction config is applied, all attributes are sent (permissive default).
• Attributes are dropped at the agent before being sent to the Trust Domain Server. Redacted attributes are never transmitted.
• Ensure attributes required by SPIFFE ID templates, X.509/JWT customization, and SVID policies are included in the allowlist — redacted attributes cannot be referenced in those configurations.

Troubleshooting

Authorization failures after enabling redaction — An attribute required by an SVID policy or SPIFFE ID template is being redacted. Check the attribute name in the redactions log field and add it to the allowlist.

Too many attributes still included — Your filters are too broad (e.g., *.*). Use more specific patterns.

Config rejected with validation error — Verify filter syntax. Ensure the policy.allowList.filters list is non-empty if the section is present.