Talos enforces per-workload, identity-aware, default-deny egress policy in the Linux kernel. No sidecar. No proxy hop. No added latency on legitimate traffic. Finally, a clean answer to "prove what each workload is allowed to reach, and prove it is enforced."
# one agent per node, enforcing in-kernel $ talos demo Talos egress enforcement - LIVE (eBPF cgroup/connect4) policy: allow api.stripe.com, rds.internal (default-deny) connect api.stripe.com:443 ALLOW connect rds.internal:5432 ALLOW connect s3.us-east-1.vpce:443 ALLOW connect 185.220.101.44:443 DENY <- C2 beacon blocked connect 1.1.1.1:853 (DoH) DENY <- evasion blocked OK allowed traffic flowed, exfil paths blocked in-kernel.
Firewalls, WAFs, and security groups all watch traffic coming in. Almost nothing watches what leaves. A single compromised container can exfiltrate data or beacon to command-and-control infrastructure over ordinary, well-formed outbound HTTPS, and most environments would never see it.
compromised pod ├─ outbound 443 → attacker-cdn.example exfil ├─ outbound 443 → 185.220.101.44 C2 beacon └─ DNS-over-HTTPS → 1.1.1.1:853 policy evasion looks like normal HTTPS. Nobody is watching.
Talos runs as a single agent per node (a DaemonSet on EKS, a per-instance daemon on ECS). It compiles your declarative policy into eBPF allow-maps and attaches at the cgroup connect hook, so the verdict on every outbound connection happens in-kernel, bound to the workload, not a fragile IP.
EgressPolicy (YAML / CRD, default-deny)
│ compile
▼
per-workload allow-maps (LPM-trie CIDRs + exact-IP + resolved FQDNs), keyed by cgroup
│ sync
▼
[ talos agent ] ── attach ──► cgroup/connect4 ── allow(1) / deny(0 → EPERM)
▲ │
│ ringbuf ▼
audit log + anomaly + Prometheus every outbound connect() decided in-kernel
Write an EgressPolicy per workload: allow by FQDN, IP/CIDR, or AWS VPC endpoint. Or let baseline learning draft it for you.
The control plane compiles policy into per-workload eBPF filter maps and pushes them to node agents.
In-kernel allow/deny at the connect hook. Legitimate traffic is untouched: no proxy, no latency.
Every attempt is logged with identity and matched rule, streamed live, and scored for anomalies.
An identity-aware policy engine, a behavioral anomaly layer, deep observability, and a compliance surface auditors can actually read.
Policy binds to the workload (pod or task), not an IP. It survives IP churn and autoscaling automatically.
Everything not explicitly allowed is denied. The compliance story depends on this being the standard mode, not an opt-in.
Allow by hostname with live DNS resolution tracking, so CDN and load-balanced SaaS endpoints do not break IP-only rules.
Recognizes traffic to S3, DynamoDB, and other VPC endpoints distinctly from generic internet egress.
Dev, staging, and prod policy tiers so you are not hand-writing the same rules three times.
"Allow this destination for 4 hours" with automatic expiry and a full audit trail for incident response.
Observe a workload's normal egress, then suggest a tightened policy. No hand-writing allow-lists for 200 services on day one.
Flag new destinations inside allowed ranges, abnormal volume or frequency, and DNS tunneling or DoH evasion.
Cross-reference destinations against known C2 and malware infrastructure in real time, and alert regardless of policy match.
A plain allow-list firewall cannot see a workload that starts misbehaving toward destinations it is technically allowed to reach. Talos baselines normal behavior and scores deviation.
# anomaly stream ANOMALY payments new-dest-in-cidr 10.4.9.7 first seen, allowed range, 0 prior ANOMALY billing volume-spike s3.vpce 4.2GB/5m baseline 40MB/5m ANOMALY web dns-tunneling 87 TXT queries/min to a.evil.example ALERT → PagerDuty + Slack + SIEM
# every connection, allowed and denied { "time": "2026-08-05T14:03:11Z", "workload": "payments", "dest": "185.220.101.44", "port": 443, "allowed": false, "rule": "default-deny" } # live deny-stream, Prometheus, SIEM export GET /api/v1/events?deny=1
Security teams get a live view of exactly what is being blocked and allowed, per workload, with the policy that matched. Wire it into the tools you already run.
Talos maps directly to the controls your compliance team already reports against, so they get evidence instead of raw logs to translate.
| Requirement | What auditors ask | How Talos answers it |
|---|---|---|
| PCI-DSS egress filtering | Restrict outbound traffic to only what is necessary | Per-workload default-deny allow-lists, enforced in-kernel, with pre-built PCI-DSS report templates |
| HIPAA technical safeguards | Control transmission of ePHI to external systems | Identity-aware destination control and full connection audit mapped to HIPAA safeguard language |
| SOC 2 change control | Who changed what policy, when, approved by whom | Full audit trail of policy changes with author / approver separation of duties |
| Incident retrospectives | What was workload X allowed to reach on date Y | Point-in-time policy reconstruction for any workload and date |
| Separation of duties | Distinct authors, approvers, and read-only auditors | Built-in RBAC: policy authors vs approvers vs read-only audit viewers |
Security groups and sidecar proxies each solve part of the problem. Talos gives you per-workload identity, in-kernel enforcement, and behavioral detection together.
| Capability | Talos | Security groups / NACLs | Sidecar proxy mesh |
|---|---|---|---|
| Per-workload identity (survives IP churn) | Yes | No, subnet-shared | Partial |
| Default-deny egress by workload | Yes | Impractical | Yes, with overhead |
| Added latency on allowed traffic | None (in-kernel) | None | Proxy hop per request |
| FQDN policy with DNS tracking | Yes | No | Varies |
| Behavioral anomaly detection | Yes | No | No |
| Threat-intel correlation | Yes | No | No |
| Compliance reports & audit trail | Built-in | Roll your own | Partial |
| Operational footprint | 1 agent / node | None | 1 sidecar / pod |
One agent per node. Start on EKS with a Helm chart, or on ECS as a per-instance daemon. No per-connection sidecar to inject.
# one agent per node as a DaemonSet helm repo add talos https://charts.talos-egress.dev helm install talos talos/talos \ --set image.tag=marketplace \ --set cgroupPath=/sys/fs/cgroup # apply a per-workload policy kubectl apply -f payments-egress.yaml
# register the agent as an ECS daemon (EC2 launch type)
aws ecs register-task-definition \
--cli-input-json file://deploy/ecs/taskdef.json
aws ecs create-service --launch-type EC2 \
--scheduling-strategy DAEMON \
--task-definition talos-egress
apiVersion: egress.talos.dev/v1alpha1 kind: EgressPolicy metadata: {name: payments} spec: workload: payments defaultAction: deny allow: - cidr: 10.0.0.0/16 # RDS subnet, any port name: rds-subnet - fqdn: api.stripe.com # HTTPS only ports: [443] - awsEndpoint: s3 # S3 via VPC endpoint
Not per node, so many small pods per node never penalize you. Start free, upgrade when you need anomaly detection, threat intel, and multi-cluster.
All tiers ship as a single AWS Marketplace container. Open-core: the enforcement engine is Apache-2.0.
No. Allow and deny decisions happen in-kernel at the cgroup connect hook. There is no proxy hop for legitimate traffic, which is exactly why latency-sensitive fintech and healthcare teams can run it on every outbound call.
A mesh puts a proxy next to every pod and adds a hop per request. Talos runs one agent per node and enforces in the kernel, so there is no per-pod sidecar and no added latency. It also adds behavioral anomaly detection and threat-intel correlation that a plain proxy allow-list does not have.
Policy binds to the workload's cgroup identity, not an IP, so it survives IP churn and autoscaling. FQDN rules use live DNS resolution tracking, so CDN and load-balanced SaaS endpoints do not break the way IP-only allow-lists do.
No. Baseline learning mode observes a workload's normal egress for a window you choose, then suggests a tightened policy you can review and apply. It is the fastest way to onboard a large fleet.
Yes. EKS is native via Kubernetes CRDs and a DaemonSet. ECS runs the agent as a per-instance daemon with task-role-tag based identity mapping. Both ship from the same AWS Marketplace container.
Talos is open-core. The enforcement engine and agent are Apache-2.0. The enterprise layer (advanced anomaly detection, threat intel, SIEM export, compliance report templates, RBAC, and fleet federation) is commercially licensed.
Stand up default-deny egress on one cluster today, then let Talos show you every connection it blocks.