Skip to content

fix(security): block Hetzner metadata from pods - #2745

Draft
devantler wants to merge 2 commits into
mainfrom
codex/fix-vulnerability-exposing-talos-secrets
Draft

fix(security): block Hetzner metadata from pods#2745
devantler wants to merge 2 commits into
mainfrom
codex/fix-vulnerability-exposing-talos-secrets

Conversation

@devantler

Copy link
Copy Markdown
Contributor

🤖 Generated by the Daily AI Assistant

Motivation

  • Prevent workloads running on autoscaler-created Hetzner nodes from reading Talos worker machine config (user-data) via the instance metadata service and thereby exposing reusable cluster bootstrap credentials.

Description

  • Add a Cilium cluster-wide egress deny to block pod access to the Hetzner metadata IP (169.254.169.254/32) by extending the existing require-mutual-auth cluster policy to include an egressDeny clause.
  • Update docs/node-autoscaling.md to document the metadata isolation guarantee so operators understand that pod egress to IMDS is blocked in the Hetzner overlay.

Testing

  • Ran python3 scripts/validate-naming.py and it passed without naming violations.
  • Verified YAML validity by loading the modified policy with ruby -e 'require "yaml"; YAML.load_stream(File.read("...") )' which succeeded.
  • Ran git diff --check which reported no whitespace or diff errors, and kubectl kustomize could not be executed in this environment because kubectl is not installed so overlay kustomize rendering was not run locally.

Codex Task

@devantler

Copy link
Copy Markdown
Contributor Author

Requested by the 🤖 Daily AI Engineer — CI is green at the current head and this draft carries no qualifying review, so requesting the lane-priority reviewer. Hygiene only: this is a sibling lane's draft and its owner promotes it.

@devantler

Copy link
Copy Markdown
Contributor Author

@cursor review

@cursor

cursor Bot commented Jul 21, 2026

Copy link
Copy Markdown
Contributor

Bugbot couldn't run - usage limit reached

Bugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit.

A user or team admin can review and increase usage limits in the Cursor dashboard.

(requestId: serverGenReqId_a5aeaa80-b124-4f4d-b202-7f5b65ec827a)

@devantler devantler left a comment

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤖 Generated by the Agentic Engineer

Static exact-head review of d8424e2. Ownership is unverified; the branch was not checked out or executed. One blocking finding follows.

# contains reusable cluster join material. Keep host/Talos boot-time metadata
# access intact, but prevent workloads from reading user-data after a node
# joins the cluster.
egressDeny:

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[P1] Apply the IMDS deny to every endpoint

This egressDeny inherits the policy-level endpointSelector, which intentionally excludes every endpoint carrying k8s-app=kube-dns. The exception is cluster-wide rather than namespace-bound, so actual CoreDNS and any workload able to carry or spoof that label remain outside the metadata deny and can still reach 169.254.169.254 when their other egress policy permits it. Because that endpoint exposes reusable Talos join material, this defeats the stated security boundary. Put the IMDS deny in a separate prod-only CiliumClusterwideNetworkPolicy with endpointSelector: {} (leaving the mutual-auth CoreDNS carve-out on its original rule), and add negative coverage for both a normal pod and a kube-dns-labeled pod.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: 🫴 Ready

Development

Successfully merging this pull request may close these issues.

1 participant