Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add recommend usage of FQDN policies #6389

Merged
merged 1 commit into from
Jun 3, 2024
Merged

Add recommend usage of FQDN policies #6389

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 14 additions & 4 deletions docs/antrea-network-policy.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1372,17 +1372,27 @@ Note that for FQDN wildcard expressions, the `*` character can match multiple su
`*foobar.com` will match `foobar.com`, `www.foobar.com` and `test.uswest.foobar.com`).

Antrea will only program datapath rules for actual egress traffic towards these FQDNs, based
on DNS results. It will not interfere with DNS packets, unless there is a separate policy
dropping/rejecting communication between the DNS components and the Pods selected.
on DNS results. It will not tamper with DNS request/response packets, unless there is a separate
policy dropping/rejecting communication between the DNS components and the Pods selected.

Antrea respects the TTL of DNS records, expiring stale IPs that are absent in more recent
records according to their TTL. Therefore, Pods employing FQDN based policies ought to refrain
records when their TTLs expire. Therefore, Pods employing FQDN based policies ought to refrain
from caching a DNS record for a duration exceeding its TTL. Otherwise, FQDN based policies may
intermittently fail to function as intended. Typically, the Java virtual machine (JVM) caches
DNS records for a fixed period of time, controlled by `networkaddress.cache.ttl`. In this
case, it’s crucial to set the JVM’s TTL to 0 so that FQDN based policies can work properly.

Note that FQDN based policies do not work for [Service DNS names created by
Another related note is that FQDN egress peers are recommended to ONLY be used in rules with
action `Allow`, accompanied by some fallback `Drop` or `Reject` egress rules that secure
N/S connectivity for the Pods selected by the FQDN policy. There is no guarantee that Antrea
will be aware of all the IPs backing a domain name constantly, especially when the FQDN is
served by dynamic IP addresses and gets DNS records with short TTLs. Some IPs may still be
used to access the FQDN after their respective TTLs have expired in the original DNS record.
Thus, using FQDN rules with action `Drop` or `Reject` could potentially allow traffic to an
IP belonging to a denied domain, if a misbehaving client tries to connect to that domain with
a cached but expired IP, leading to a security breach.

Also note that FQDN based policies do not work for [Service DNS names created by
Kubernetes](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/#services)
(e.g. `kubernetes.default.svc` or `antrea.kube-system.svc`), except for headless
Services. The reason is that Antrea will use the information included in A or
Expand Down