Files
kubernetes-security-baselin…/deployments/falco
swaphb 5c1e6205a7
Kube-bench CIS scan / Scan ephemeral K3s cluster (push) Successful in 1m0s
document Falco runtime topology
2026-08-15 14:22:56 -04:00
..
2026-08-15 14:22:56 -04:00

Falco alerting secret

Falco alert delivery must use a Kubernetes Secret. Do not commit a Slack Incoming Webhook URL, Slack token, Discord webhook URL, or generated Secret manifest to this repository.

The expected Secret contract for the Git-managed Falcosidekick configuration is:

apiVersion: v1
kind: Secret
metadata:
  name: falco-alerting
  namespace: falco
type: Opaque
stringData:
  webhook-url: https://hooks.slack.com/services/REPLACE/ME

The example value is a placeholder. Create the Secret directly on the cluster with the real Slack Incoming Webhook URL:

kubectl create namespace falco --dry-run=client -o yaml | kubectl apply -f -
kubectl create secret generic falco-alerting \
  --namespace falco \
  --from-literal=webhook-url='https://hooks.slack.com/services/REPLACE/ME' \
  --dry-run=client -o yaml | kubectl apply -f -

The webhook-url key is injected into Falcosidekick as SLACK_WEBHOOKURL. Falcosidekick sends only WARNING and higher priority events to Slack through SLACK_MINIMUMPRIORITY. Lower-priority events remain available in Falco logs. The Secret is intentionally not included in the Falco Kustomization because ArgoCD must not manage or render the credential from Git.

Verify only the Secret name and key, never the value:

kubectl get secret falco-alerting -n falco \
  -o jsonpath='{.metadata.name}{" keys: "}{range $key, $value := .data}{$key}{" "}{end}{"\n"}'

Avoid printing Secret data in shared terminals or CI logs. To rotate the webhook, update the Secret in place with the creation command and restart the Falco workloads after the alerting integration is configured.

The repository verifies Falco runtime detections locally. Webhook delivery is enabled by the Git-managed Falcosidekick resources after the Secret exists, and still requires an interactive Slack or Discord credential for end-to-end testing.

For runtime alert interpretation, see docs/runtime-detection.md. The local k3d nodes share one Flatcar host kernel, so duplicate Falco notifications are possible. Separate VM nodes provide distinct kernels and are the more realistic production-style validation path.