No Wildcard ACLs in Production

Production ACLs must not grant `*` principal or `*` resource pattern.

Rationale

A wildcard principal (`User:*`) on a production topic is a credential bypass. A wildcard resource (`Topic:*`) on an `Allow` grant is cluster-wide access. Both patterns are almost always misconfigs copied from dev.

Pattern

principal != "User:*" AND resource.pattern != "*"

Examples

User:orders-svc on Topic:prod.orders.* Read

User:* on Topic:prod.orders.placed.v1 Read

User:dev on Topic:* Allow

Parameters

Name	Default	Description
`env_prefix`	`"prod."`	Topic name prefix considered production.

Implementation

Drop this YAML into Conduktor Console as a ResourcePolicy, then link it from an ApplicationInstance, Application, or KafkaCluster.

Conduktor ResourcePolicy

# Conduktor self-service ResourcePolicy
# Schema: https://docs.conduktor.io/platform/reference/resource-reference/self-service/#resourcepolicy
# Conduktor exposes ACL surfaces through ApplicationGroup (which carries
# permissions handed to a ServiceAccount).
---
apiVersion: self-serve/v1
kind: ResourcePolicy
metadata:
  name: no-wildcard-acl-prod
spec:
  targetKind: ApplicationGroup
  description: ApplicationGroups touching prod.* resources cannot use wildcard LITERAL resource patterns
  rules:
    - condition: 'spec.permissions.all(p, !(p.name.startsWith("prod.") || p.name == "*") || (p.patternType != "LITERAL" || p.name != "*"))'
      errorMessage: "Wildcard LITERAL resource is not allowed on production resources"

Related policies

Try Conduktor Console

Enforce policies like this across your team — central audit history, pre-commit guardrails, ApplicationInstance bindings. 5-min Docker install.

Get Started →