Configuration

org_name and org_unit (and a few older tuning knobs such as pipeline_batch_size and interceptor.fd_polling_interval) are retired. A ConfigMap that still names one loads fine; Edge logs once at startup that the setting has no effect and ignores it. A misspelt key, on the other hand, is refused at load, so a typo is caught before it can disable a rule.

Store the API key in a Kubernetes Secret for better security practices.

# First, create the secret:
kubectl create secret generic auditty-secret \
  --namespace auditty \
  --from-literal=hivemind_api_key=your-api-key-here

# Then reference it in values.yaml:
secretRef:
  enabled: true
  secretName: "auditty-secret"
  apiKeyName: "hivemind_api_key"

Scenario: the platform team intercepts the whole production namespace, and lets teams opt specific workloads out.

ConfigMap (cluster-wide):

configMap:
  enable_rule_annotations: true
  rules:
    - name: "intercept-production"
      action: intercept
      scope:
        namespace: "production"
      description: "Monitor all production workloads"

Annotation (opt-out specific workload):

apiVersion: apps/v1
kind: Deployment
metadata:
  name: test-workload
  namespace: production
spec:
  template:
    metadata:
      annotations:
        auditty.ai/rule.skip-me: |-
          name: skip-test-workload
          action: skip
          description: "Exclude this workload from interception"

kubectl logs -n auditty -l app.kubernetes.io/name=auditty-edge --max-log-requests=50 | grep "Skipping log interception" | grep test-workload

Scenario: nothing is intercepted by default; only workloads that explicitly opt in are.

ConfigMap:

rules: []

Annotation (opt-in):

metadata:
  annotations:
    auditty.ai/rule.monitor-me: |-
      name: intercept-this-workload
      action: intercept
      description: "Monitor this specific workload"

Use case: Always keep error logs containing "database" or "payment".

rules:
  - name: "preserve-critical-errors"
    action: preserve
    scope:
      namespace: "production"
    match:
      any:
        - entryIncludes: "database connection failed"
        - entryIncludes: "payment processing error"
        - entryRegex: "ERROR.*timeout"
    description: "Never suppress critical errors"

Use case: Ensure warnings and everything above are always preserved in production, regardless of other rules, including a suppress rule that would otherwise match them.

rules:
  - name: "preserve-high-severity"
    action: preserve
    scope:
      namespaceIncludes: "prod"
    match:
      severity: "warning"
    description: "Never suppress warnings and above in production"

Use case: Suppress debug logs and health-check noise; both stay recoverable from the Vault.

rules:
  - name: "suppress-debug"
    action: suppress
    scope:
      namespaceIncludes: "prod"
    match:
      entryIncludes: "DEBUG"
    description: "Suppress debug logs in production"

  - name: "suppress-health-checks"
    action: suppress
    match:
      entryRegex: "GET /health.*200 OK"
    description: "Suppress successful health check logs"

Scenario: A team wants to see what a suppress rule would remove from one namespace before any line is actually replaced by a summary.

rules:
  - name: "suppress-access-logs"
    action: suppress
    scope:
      namespace: "storefront"
    match:
      entryRegex: '"GET /[^"]*" 2\d\d'
    description: "Successful requests on the storefront"

  - name: "measure-storefront"
    action: measure
    scope:
      namespace: "storefront"
    description: "Shadow mode for storefront while the rule is tuned"

Fast, case-sensitive substring matching.

match:
  entryIncludes: "connection failed"

For complex patterns. Use when entryIncludes isn't sufficient.

match:
  entryRegex: "HTTP [45][0-9]{2}"  # Matches HTTP 4xx/5xx errors

Matches if any condition is true.

match:
  any:
    - entryIncludes: "ERROR"
    - entryIncludes: "WARN"

Matches only if all conditions are true.

match:
  all:
    - entryIncludes: "database"
    - entryIncludes: "timeout"

Matches when the condition inside is false. Conditions written side by side in one match must all hold, so a not beside another condition carves an exception out of it.

match:
  entryIncludes: "health"     # health-check lines…
  not:
    entryIncludes: "failed"   # …except the ones that failed

Matches logs at this severity level and above. Severity is auto-detected from all major log formats (JSON, logfmt, brackets, Python, Java, PHP, Ruby, Rust, and more), read from the first line of a multi-line entry. A line on stderr with no recognisable level counts as error, so severity: "error" also matches plain stderr output.

match:
  severity: "warning"  # Matches warning, error, critical, fatal, etc.

Severity hierarchy (lowest to highest):

trace/debug → info → notice → warning → error → critical → fatal/panic → alert → emergency

Setting severity: "warning" matches warning, error, critical, fatal, panic, alert, and emergency. Setting severity: "error" matches error, critical, fatal, panic, alert, and emergency. Common shorthands (warn, err, crit, emerg) are also recognized.

Matches logs from a specific container output stream. Accepts "stdout" or "stderr".

match:
  stream: "stderr"  # Match logs written to stderr

1. Annotation rules require both enable_rule_annotations: true and edgeApi.enabled: true. Check both:

kubectl get configmap auditty-config -n auditty -o yaml | grep -E "enable_rule_annotations|enabled"

2. Verify RBAC permissions. This is granted to the Edge API service account, not the DaemonSet:

kubectl auth can-i get deployments --as=system:serviceaccount:auditty:auditty-edge-api

3. Check Edge logs for errors:

kubectl logs -n auditty -l app.kubernetes.io/name=auditty-edge --max-log-requests=50 --tail=50 | grep -i annotation

Every container a rule tells Edge to leave alone gets one INFO line from the Edge pod on its node, the first time Edge sees the container running and again only if a different rule takes over or it was intercepted in between (Edge 1.7.5+):

Skipping log interception  {"namespace": "production", "workload": "test-workload", "rule": "skip-test-workload", "rule_source": "annotation"}

• rule is the name in your rule; rule_source says where it was written: annotation (on the pod or its owner), config (the ConfigMap) or fleet (the Fleet Rules page)
• These lines are INFO. Edge 1.7.5 logs at info by default; an install that set log_level: warn in its ConfigMap (the default before 1.7.5) must raise it to info to see them; it hot-reloads, no restart
• No line and no Started log interception for the workload means no rule selected it at all: check the namespace scope of your intercept rule, not the skip
• A skip added to a running workload takes effect within about a minute, no restart or rollout needed (Edge 1.7.5+): you will see Stopped log interception with reason: rule_change, then Skipping log interception. Before 1.7.5 annotations were read only when Edge first saw the container, so a new pod that logged before Edge had its annotations was intercepted under the node’s rules until its next restart
• Started log interception for a workload you meant to skip means the skip rule did not reach Edge: see "Annotations Not Working?" above

• The line at the top of every Auditty page says where the fleet stands: nothing while every node is live, Shadow mode once every node measures, Shadow mode on N of M when only some nodes do, Entering shadow mode · a of b nodes or Going live · n of m nodes still measuring while nodes switch, and Shadow mode switched on · no node has applied it once the switch has been on for ten minutes without a node confirming it. Each node applies the switch within seconds and reports it within two minutes
• A node that stays live after the switch is either not following fleet rules (remote_rules.enabled: false, or no way to reach Auditty; the Connected Fleet card lists it as not consuming) or older than Edge 1.7.6, which rejects a rule set with a measure action and keeps the rules it had; the card shows the rejection as the node’s last error
• A node that stays in shadow mode after Go live has shadow_mode: true in its own ConfigMap, or a ConfigMap rule with action: measure that selects the workload. A local rule named measure also vetoes the fleet switch on that node; the Fleet Rules page shows it as overridden locally
• Started observing logs in shadow mode; nothing is suppressed in the Edge pod’s log names the rule and rule_source when a measure rule decided, and carries neither when the node’s own shadow_mode: true did, so the source of an unexpected shadow mode is one kubectl logs away

• Ensure entryIncludes string is exact (case-sensitive)
• Test regex patterns with online tools before deploying
• Check scope matches the namespace/workload correctly
• Remember: annotations only affect the workload they're attached to