jklein
589021aed1
Gitea #143. Additive, default false, so the render is byte-identical to the previous release - proven by diffing both renders against origin/main rather than asserted. Switched on it adds 15008/TCP, ztunnel's HBONE tunnel, to the rule carrying the probe port, and - inside that rule's source-restricted branch - 169.254.7.127/32, the address the kubelet's probes arrive from once the pod is in the mesh. Ambient does not bypass NetworkPolicy enforcement, so without the port a pod whose namespace has joined the mesh is unreachable. The two halves are one value because the second is the one nobody thinks of: 15008 added by hand leaves a policy that passes review and drops every probe the first time probeSources is narrowed, and a pod that never becomes Ready reads as a broken application rather than as a policy. Minor, not major: additive value, unchanged default, unchanged render.
487 lines
25 KiB
YAML
487 lines
25 KiB
YAML
# Scale the whole chart down without uninstalling it: scaleDown: true renders
|
|
# every Deployment/StatefulSet with replicas: 0 (and suspends CronJobs) and
|
|
# takes precedence over any per-workload replicas value. PVCs, Secrets and
|
|
# Services stay in place; scaleDown: false brings the workloads back up.
|
|
scaleDown: false
|
|
|
|
# The bridges RSS-Bridge offers, rendered into the ConfigMap as whitelist.txt
|
|
# and mounted at /app/whitelist.txt.
|
|
#
|
|
# A list rather than a blob of file content: the file format is one bridge name
|
|
# per line, and the application trims and filters every line before use
|
|
# (lib/Configuration.php), so nothing is lost by modelling it as YAML - while a
|
|
# hardcoded file body in the template could not be changed without editing the
|
|
# chart.
|
|
#
|
|
# The single entry "*" is RSS-Bridge's own wildcard and enables every bridge.
|
|
# It is the default here because it is exactly what the image does when no
|
|
# whitelist.txt exists at all, so a default install behaves like stock
|
|
# RSS-Bridge instead of silently serving nothing. Installations that want a
|
|
# narrower set list the bridge names explicitly:
|
|
#
|
|
# whitelist:
|
|
# - Youtube
|
|
# - Heise
|
|
#
|
|
# Changing this value rolls the pod - the deployment carries a checksum over
|
|
# the rendered ConfigMap (see rss-bridge.deployment.yaml). Without that the
|
|
# change would not reach the running container at all: the whitelist is a
|
|
# subPath mount, which the kubelet never refreshes.
|
|
whitelist:
|
|
- "*"
|
|
|
|
rssBridge:
|
|
# Replica count for this workload; 0 is allowed and scales it down.
|
|
# The chart-global scaleDown flag takes precedence.
|
|
replicas: 1
|
|
# Verified against the image, not assumed (issue #128).
|
|
#
|
|
# The image ships no USER and runs everything as root by default. It does,
|
|
# however, run fully hardened once its writable paths are provided: nginx and
|
|
# php-fpm both start, the front page renders and real bridges fetch feeds.
|
|
#
|
|
# uid/gid 33 is www-data, and it is not interchangeable: /app and every file
|
|
# in it is owned by www-data in the image, nginx.conf declares "user
|
|
# www-data" and the php-fpm pool declares "user = www-data". Both emit a
|
|
# harmless notice that those directives are ignored when the master process
|
|
# is not root, and then serve normally as uid 33.
|
|
securityContext:
|
|
pod:
|
|
runAsNonRoot: true
|
|
runAsUser: 33
|
|
runAsGroup: 33
|
|
fsGroup: 33
|
|
fsGroupChangePolicy: Always
|
|
seccompProfile:
|
|
type: RuntimeDefault
|
|
# Why this chart listens on the privileged port 80, and why that is safe.
|
|
#
|
|
# nginx is configured for port 80 inside the image. The only lever the
|
|
# entrypoint offers is HTTP_PORT, which runs a sed against
|
|
# /etc/nginx/sites-enabled/default - impossible with a read-only root
|
|
# filesystem. So the choice is port 80 or readOnlyRootFilesystem, and
|
|
# port 80 is the cheaper of the two. (The Service selects the port by
|
|
# NAME, so the number is invisible to it either way.)
|
|
#
|
|
# Kubernetes sets net.ipv4.ip_unprivileged_port_start=0 in the pod
|
|
# network namespace, so binding 80 needs no capability at all. But that
|
|
# is a runtime default, not a guarantee, and relying on it silently is
|
|
# exactly the trap the template-chart warns about - so the chart pins the
|
|
# value instead of inheriting it.
|
|
#
|
|
# Measured in k3d (k3s v1.35.5), same pod spec, only this value changed:
|
|
# sysctl 1024, capabilities.drop [ALL] -> nginx: bind() to
|
|
# 0.0.0.0:80 failed (13: Permission denied)
|
|
# sysctl 1024, plus NET_BIND_SERVICE added -> identical failure.
|
|
# Adding the capability does NOT help: for a non-root process it
|
|
# lands in the permitted set but not the effective/ambient one, so
|
|
# it buys nothing here. That is why this chart does not add it.
|
|
# sysctl 0 (this default) -> binds, HTTP 200.
|
|
#
|
|
# Note how that failure looks without probes: the entrypoint starts nginx
|
|
# in the background and then execs php-fpm, so a failed bind leaves a
|
|
# container that reports Running with no web server at all. The probes on
|
|
# /?action=health turn that silent failure into a pod that never becomes
|
|
# Ready.
|
|
sysctls:
|
|
- name: net.ipv4.ip_unprivileged_port_start
|
|
value: "0"
|
|
container:
|
|
allowPrivilegeEscalation: false
|
|
readOnlyRootFilesystem: true
|
|
runAsNonRoot: true
|
|
capabilities:
|
|
drop:
|
|
- ALL
|
|
# All three probes hit RSS-Bridge's own health action, which renders a fixed
|
|
# 49-byte JSON document without touching the file cache or any remote site.
|
|
# That keeps liveness free of external dependencies (guideline 3): a scraped
|
|
# website going down, or a cache directory that is not writable, must not
|
|
# restart the pod.
|
|
#
|
|
# Deliberately not "/": the front page enumerates every enabled bridge and
|
|
# answers with roughly 1.5 MB, which is a wasteful thing to fetch every ten
|
|
# seconds forever.
|
|
livenessProbe:
|
|
httpGet:
|
|
path: /?action=health
|
|
port: rss-bridge-port
|
|
periodSeconds: 10
|
|
timeoutSeconds: 5
|
|
failureThreshold: 3
|
|
readinessProbe:
|
|
httpGet:
|
|
path: /?action=health
|
|
port: rss-bridge-port
|
|
periodSeconds: 10
|
|
timeoutSeconds: 5
|
|
failureThreshold: 3
|
|
# The startup probe gates liveness/readiness, so those need no
|
|
# initialDelaySeconds. Startup budget = 5s * 30 = 150s, which is generous:
|
|
# the container is ready in about two seconds (nginx plus php-fpm, no
|
|
# migrations, no warm-up).
|
|
startupProbe:
|
|
httpGet:
|
|
path: /?action=health
|
|
port: rss-bridge-port
|
|
periodSeconds: 5
|
|
timeoutSeconds: 5
|
|
failureThreshold: 30
|
|
# Extra environment variables. Values are rendered through tpl; the value,
|
|
# secretKeyRef and configMapKeyRef forms are supported.
|
|
#
|
|
# RSS-Bridge maps RSSBRIDGE_<section>_<key> onto its config, so for example
|
|
# "RSSBRIDGE_system_timezone: Europe/Berlin" works here.
|
|
env: []
|
|
resources:
|
|
# Limits are optional: memory and ephemeral-storage limits default to
|
|
# limitFactor x the request, an explicitly set limit always wins, and a
|
|
# CPU limit is only set when configured explicitly under "limits".
|
|
limitFactor: 3
|
|
requests:
|
|
cpu: 0.1
|
|
# Measured with the shipped image: about 21 MiB resident at startup and
|
|
# roughly 64 MiB after serving feeds, so the 20Mi the original manifest
|
|
# requested was a third of what the workload occupies around the clock.
|
|
# (Re-measured on the 2025-08-05 image; the 2025-06-03 image came out
|
|
# marginally higher at 24 MiB / 71 MiB under the identical procedure.)
|
|
memory: 128Mi
|
|
# The previous manifest requested 2Gi of ephemeral storage - identical to
|
|
# its limit - and thereby reserved two gigabytes of node scheduling
|
|
# capacity for a workload that does not come close to using it.
|
|
#
|
|
# Everything RSS-Bridge writes was enumerated by running the image with a
|
|
# writable root filesystem, exercising every whitelisted bridge and then
|
|
# reading the container's diff layer. The only path that grows is the
|
|
# feed cache under /app/cache: 17 entries and 2.2 MB after fetching all
|
|
# five bridges, largest single entry 196 KB, and the application purges
|
|
# it on its own (FileCache enable_purge). /run and /var/lib/nginx add
|
|
# under 100 KB together.
|
|
#
|
|
# 64Mi is therefore roughly thirty times the measured footprint while
|
|
# freeing 97% of the old reservation. The limit below stays large, so
|
|
# the decoupling costs no safety margin (same shape as gotenberg, #106).
|
|
ephemeralStorage: 64Mi
|
|
limits:
|
|
# Set explicitly rather than left to limitFactor x request.
|
|
#
|
|
# memory: the manifest this chart replaces capped the container at
|
|
# 100Mi, but a warm container serving five concurrent feed fetches was
|
|
# measured peaking at 119 MiB - the old limit was already below the real
|
|
# peak. php-fpm is configured for up to five workers with a 128M PHP
|
|
# memory_limit each, so the theoretical ceiling is far higher still.
|
|
# 512Mi covers the measured peak with room to spare and still bounds a
|
|
# runaway bridge.
|
|
memory: 512Mi
|
|
# Unchanged from the previous manifest on purpose: a large cap costs
|
|
# nothing (it reserves no capacity) and guarantees this change cannot
|
|
# make eviction more likely than it is today.
|
|
ephemeralStorage: 2Gi
|
|
# No CPU limit by default (repo standard): CPU is compressible, so a limit
|
|
# only throttles. The previous manifest capped CPU at 0.5.
|
|
|
|
ingress:
|
|
# Gates the whole Ingress template. Checked in both directions per guideline
|
|
# 1: nothing outside this template reads an ingress value - the container
|
|
# takes no domain in its environment and nginx serves as default_server
|
|
# without a server_name - so switching the Ingress off frees every value
|
|
# below, and none of them needs a separate required().
|
|
#
|
|
# MUTUALLY EXCLUSIVE WITH httpRoute.enabled (Gitea #114) - the render aborts
|
|
# when both are true, naming both value paths. Note the default here is TRUE,
|
|
# so switching to Gateway mode means setting this to false explicitly.
|
|
#
|
|
# Re-checked for #114, because this is the value that trips charts up in the
|
|
# Gateway mode: anything COMPUTED from ingress.enabled flips when the mode
|
|
# changes, and three charts of the sweep (sure, freesailarr,
|
|
# ytdlp-web-player) had exactly such a value - one of them a silent
|
|
# authentication bypass. This chart has none. The grep was run over the whole
|
|
# chart directory: outside the Ingress template the only readers of an
|
|
# ingress value are NOTES.txt (which knows its own mode) and the tlsGroups
|
|
# helper (called only from behind this switch). RSS-Bridge takes no base URL
|
|
# and no hostname in its environment, so there is nothing here that could
|
|
# come out wrong while the pod stayed Ready - no "published" helper needed.
|
|
enabled: true
|
|
# NOT READ IN GATEWAY MODE: the chart renders no Certificate there, so there
|
|
# is nothing for cert-manager to do on behalf of this release. Required only
|
|
# while ingress.enabled - the single read lives inside the Ingress template,
|
|
# behind that switch.
|
|
clusterIssuer: null
|
|
# NOT READ IN GATEWAY MODE: the class is a property of the Gateway there, and
|
|
# the Gateway belongs to the platform (cluster-config).
|
|
className: nginx
|
|
# Extra annotations for the Ingress; merged with the cert-manager
|
|
# cluster-issuer annotation the chart always sets.
|
|
#
|
|
# NOT READ IN GATEWAY MODE: the Gateway API has no annotation channel for
|
|
# controller behaviour, so anything put here is gone in that mode.
|
|
#
|
|
# Unlike most charts of the sweep, this one loses NOTHING by that today, and
|
|
# it was measured rather than assumed (2026-10-13, read-only kubectl against
|
|
# the live object): the running Ingress carries the cert-manager
|
|
# cluster-issuer annotation plus Helm and Rancher/Fleet bookkeeping, and not
|
|
# one nginx.ingress.kubernetes.io annotation. Group 3 of the sweep found an
|
|
# operator-set annotation filling a chart's gap on four of its six charts -
|
|
# that screen came back empty here. An absence of evidence about THIS
|
|
# installation is not a guarantee about yours: whatever you put here still
|
|
# disappears in Gateway mode.
|
|
annotations: {}
|
|
# The hosts this Ingress serves. Required - the chart ships no default,
|
|
# because hostnames are installation data and have no business in a chart.
|
|
#
|
|
# NOT READ IN GATEWAY MODE, and this is the one value of the block where that
|
|
# needed a decision rather than a note - see httpRoute.hostnames below. The
|
|
# required() on this list lives inside the Ingress template, behind
|
|
# ingress.enabled, so it is already conditional on the mode and demands
|
|
# nothing in Gateway mode.
|
|
#
|
|
# Each entry is a host plus an OPTIONAL tlsSecretName:
|
|
#
|
|
# hosts:
|
|
# - host: rss-bridge.example.com
|
|
# - host: feeds.example.com
|
|
# tlsSecretName: tls-legacy-feeds-ingress
|
|
#
|
|
# Entries sharing a tlsSecretName are grouped into one tls entry, so they
|
|
# share a single certificate with several SANs. Entries with distinct names
|
|
# get one certificate each. Omitting tlsSecretName falls back to the repo
|
|
# convention, tls-<release>-<chart>-ingress.
|
|
#
|
|
# DOCUMENTED DEVIATION - why the secret name is configurable at all:
|
|
#
|
|
# The repo convention (guideline 4) is exactly one TLS secret per Ingress,
|
|
# named tls-<release>-<chart>-ingress. The installation this chart takes over
|
|
# has grown three separate secrets, one per host, from three years of
|
|
# kubectl apply. Renaming them would not be a cosmetic cleanup: cert-manager
|
|
# keys certificates by secret name, so three new names mean three fresh
|
|
# issuances, and the service is unreachable on each host until its
|
|
# certificate is issued. That is a self-inflicted outage plus three
|
|
# avoidable Let's Encrypt issuances, for a deployment that has been running
|
|
# untouched for over a year.
|
|
#
|
|
# Making host and secret name per-entry values keeps the existing names in
|
|
# place today and turns the eventual consolidation onto one certificate - or
|
|
# the retirement of the legacy hostnames - into a values change instead of a
|
|
# template change (the explicit ask from cluster-config#33).
|
|
#
|
|
# tlsSecretName IS MEANINGLESS IN GATEWAY MODE - the certificate sits on the
|
|
# Gateway's listener - which is why httpRoute.hostnames below is a plain list
|
|
# of strings rather than a reuse of this one.
|
|
hosts: null
|
|
|
|
# THE GATEWAY-API ALTERNATIVE TO THE INGRESS ABOVE (Gitea #114), and this chart
|
|
# is the LAST of that sweep - 22 charts carried an Ingress template, 21 an
|
|
# HTTPRoute template, and the difference was this one. It was held back because
|
|
# its install-test had been failing on the Gitea runner (#51), not for anything
|
|
# about its shape - and that test went green in the very PR that converted it,
|
|
# on a render byte-identical to main, which ruled the chart out and left the
|
|
# runner. #51 was closed on that round; the cause was never identified, so a
|
|
# recurrence is a fresh finding rather than a known quirk.
|
|
#
|
|
# Off by default, so an existing release is unaffected. Mutually exclusive with
|
|
# ingress.enabled - the render aborts when both are true, naming both value
|
|
# paths. Note that ingress.enabled DEFAULTS TO TRUE here, so this mode needs
|
|
# ingress.enabled: false set explicitly.
|
|
#
|
|
# The chart renders ONLY an HTTPRoute with parentRefs - no Gateway, no
|
|
# gatewayClassName, no Certificate and no implementation-specific policy
|
|
# object. Class and certificate belong to the Gateway and therefore to the
|
|
# platform (cluster-config), which is what keeps this chart independent of
|
|
# whether the cluster runs nginx-gateway-fabric, Cilium, Envoy Gateway or
|
|
# Istio.
|
|
#
|
|
# ONE OBJECT FOR EVERY HOSTNAME, because nothing differs per host: all three
|
|
# hostnames of the live installation serve the same Service at "/", measured on
|
|
# the running Ingress. spec.hostnames is a list and its rules apply to every
|
|
# hostname of the object, so one object is enough - unlike homeassistant (paths
|
|
# differ per host) or matrix-synapse (different paths and backends).
|
|
#
|
|
# WHAT BECOMES INERT, AND IT IS A SIMPLIFICATION RATHER THAN A LOSS:
|
|
# rss-bridge.tlsGroups, the helper that groups hosts by TLS secret name so the
|
|
# three grown certificates keep their names. With TLS on the listener there is
|
|
# nothing left for it to group, and this mode never calls it.
|
|
#
|
|
# The Gateway-API CRDs must be installed in the cluster: the chart does not and
|
|
# cannot detect them (.Capabilities.APIVersions is unreliable at template
|
|
# time), so with httpRoute.enabled: true and no CRDs the INSTALL fails.
|
|
httpRoute:
|
|
enabled: false
|
|
# The Gateway(s) this route attaches to - a platform object, usually in
|
|
# another namespace, which must allow this namespace in its listener's
|
|
# allowedRoutes. One entry per parent, the fields are the Gateway API's
|
|
# ParentReference (name, and optionally namespace, sectionName, port, group,
|
|
# kind), passed through unchanged:
|
|
#
|
|
# parentRefs:
|
|
# - name: public
|
|
# namespace: gateway
|
|
# sectionName: https
|
|
#
|
|
# REQUIRED while httpRoute.enabled is true - the render aborts on an empty
|
|
# list, because a route without a parent is created, is valid and routes
|
|
# nothing, with no event to say so.
|
|
parentRefs: []
|
|
# The public names of this release in Gateway mode. REQUIRED while
|
|
# httpRoute.enabled is true - the render aborts on an empty list.
|
|
#
|
|
# Its own value, and both halves of that are deliberate:
|
|
#
|
|
# Why not a fallback like the other charts: most of them have an
|
|
# ingress.domain - one public name - and an empty hostnames list falls back
|
|
# to it so there is a single source of truth. This chart has no
|
|
# ingress.domain; it has a LIST of hosts, so there is no single name to fall
|
|
# back to.
|
|
#
|
|
# Why not a reuse of ingress.hosts: those entries carry an optional
|
|
# tlsSecretName, which exists only to keep three grown certificates alive on
|
|
# their existing secret names, and which addresses nothing once TLS sits on
|
|
# the Gateway's listener. Reusing the list would drag a structure whose
|
|
# second field is meaningless into this mode and invite somebody to set it
|
|
# there. (freesailarr and homeassistant REJECT a hostnames key outright, for
|
|
# the opposite reason: a chart-global list could not say which app or which
|
|
# host entry it belonged to. Here there is one Service on one path, so a
|
|
# chart-global list says exactly one thing - which is why this chart gets the
|
|
# key those two refuse.)
|
|
#
|
|
# An empty list does NOT render nothing: an HTTPRoute without hostnames
|
|
# matches every request that reaches its listener, so on a shared Gateway
|
|
# this release would answer for hostnames belonging to other releases. Hence
|
|
# the abort.
|
|
#
|
|
# hostnames:
|
|
# - rss-bridge.example.com
|
|
# - feeds.example.com
|
|
hostnames: []
|
|
|
|
# ---------------------------------------------------------------------------
|
|
# NetworkPolicy (Gitea #5). On by default. The reference implementation with
|
|
# the full reasoning is template-chart; the convention is in README, "Chart
|
|
# style guidelines", and the operator's view on this chart's wiki page.
|
|
# ---------------------------------------------------------------------------
|
|
networkPolicy:
|
|
# WHAT THIS POLICY ALLOWS: inbound 80 only (the container's port), and
|
|
# outbound DNS plus TCP 80 and 443 to ANY destination.
|
|
#
|
|
# WHAT IT DOES NOT DO, and this one needs saying out loud: the egress rule
|
|
# permits the open internet on both web ports, because that IS the
|
|
# application - a feed bridge that cannot reach the sites it bridges does
|
|
# nothing, and a NetworkPolicy cannot express "only these hosts". What the
|
|
# cap still buys is real but narrow: this pod cannot open any OTHER outbound
|
|
# port, so a compromised bridge cannot reach a database, a mail server or an
|
|
# SSH port anywhere in the cluster.
|
|
#
|
|
# Inbound 80 is not restricted by source in the default (it is the probe
|
|
# port), and a policy is only a boundary where the CNI enforces one.
|
|
enabled: true
|
|
# Namespaces whose pods may reach this workload, in addition to the release's
|
|
# own namespace, which is always allowed. Empty means: own namespace only.
|
|
#
|
|
# Matched on the "kubernetes.io/metadata.name" label Kubernetes sets on every
|
|
# namespace itself, so no labelling work is needed on a namespace this chart
|
|
# does not own - and no typo protection either: a name that does not exist
|
|
# matches nothing and is silently ineffective. Note the granularity: an entry
|
|
# opens the port to EVERY pod in that namespace.
|
|
allowedNamespaces: []
|
|
# Source CIDRs allowed to reach port 80, which is the port all three probes address.
|
|
#
|
|
# EMPTY MEANS OPEN, NOT BLOCKED. With no entry that rule is rendered WITHOUT a
|
|
# "from" selector, so the port is reachable from anywhere the CNI routes to -
|
|
# inside the cluster, since it carries no NodePort.
|
|
#
|
|
# That is the deliberate choice between two bad defaults. The kubelet's probes
|
|
# originate from the IP of the WORKER NODE running the pod, an address this
|
|
# chart cannot know and must not guess: a CIDR that excludes the real node
|
|
# blocks every probe, the pod never becomes Ready, the rollout times out, and
|
|
# the symptom reads as a broken application rather than as a policy.
|
|
#
|
|
# Narrow it by listing the worker node IPs (e.g. ["10.0.1.11/32"]) - and mind
|
|
# the companion trap: once this list is non-empty the rule IS restricted, so
|
|
# everything else that needs the port has to be in it. The chart adds the own
|
|
# namespace, the ingressController below and allowedNamespaces to the same rule for exactly that reason.
|
|
probeSources: []
|
|
# The ingress controller allowed to reach the routed port once probeSources
|
|
# restricts it. Rendered only while ingress.enabled or httpRoute.enabled is true, and only in
|
|
# the restricted branch - with the default (open) rule the controller reaches
|
|
# the port anyway. The two keys become ONE "from" entry and are therefore an
|
|
# AND: pods carrying podLabels IN namespace. That is the point of having them
|
|
# at all - the controller's namespace in allowedNamespaces would open the port
|
|
# to every pod in kube-system.
|
|
#
|
|
# MEASURED ON THIS CLUSTER, NOT ASSUMED (2026-10-14): ingress-nginx is gone,
|
|
# the only IngressClass is "traefik" and it is the default, and the controller
|
|
# is the DaemonSet rke2-traefik in kube-system. The same Traefik serves the
|
|
# Gateway API here, so this one source covers the Ingress and the HTTPRoute
|
|
# path alike. A policy written against the wrong controller is accepted, looks
|
|
# strict, and silently blocks all web traffic - and ingress.className says
|
|
# nothing about it, because a class names an implementation, not the pods the
|
|
# traffic comes from.
|
|
ingressController:
|
|
namespace: kube-system
|
|
podLabels:
|
|
app.kubernetes.io/name: rke2-traefik
|
|
|
|
# The policy's INBOUND side. Mind the three names that overlap as substrings,
|
|
# because a search for "ingress" matches all of them and they are different
|
|
# things:
|
|
#
|
|
# ingress (top level) the Ingress OBJECT this chart
|
|
# renders - host, TLS, className
|
|
# networkPolicy.ingress this block: what the policy lets IN
|
|
# networkPolicy.ingressController the SOURCE SELECTOR for the ingress
|
|
# controller's pods. A SIBLING of this block
|
|
# and NO PART OF IT, despite the name.
|
|
ingress:
|
|
# Opens the pod for Istio's ambient mesh (Gitea #143). OFF by default and
|
|
# additive: while it is false this chart renders byte for byte as it did
|
|
# before the value existed.
|
|
#
|
|
# IT RENDERS TWO THINGS, and that they come together is the point:
|
|
#
|
|
# 1. 15008/TCP inbound - ztunnel's HBONE tunnel. Every inbound mesh
|
|
# connection arrives on it, and ambient "does not and will never bypass
|
|
# Kubernetes NetworkPolicy enforcement", so without this port a pod
|
|
# whose namespace has joined the mesh is unreachable.
|
|
# 2. 169.254.7.127/32 as an additional peer - but ONLY where the rule
|
|
# restricts sources at all, which here means probeSources is non-empty.
|
|
# Inside the mesh the kubelet's probes are redirected and no longer come
|
|
# from the worker node's address.
|
|
#
|
|
# WHY ONE SWITCH AND NOT TWO: point 2 is the one nobody thinks of. Whoever
|
|
# adds "15008" to a port list by hand writes a policy that passes review, and
|
|
# the first time probeSources is narrowed every probe is dropped - the pod
|
|
# never becomes Ready and the symptom reads as a broken application rather
|
|
# than as a policy. A switch whose halves can only be had together cannot be
|
|
# set halfway, which is why this is a named intention and not a port list.
|
|
#
|
|
# TWO THINGS IT DOES NOT PROVE:
|
|
# - That 15008 alone is enough. That comes from Istio's documentation;
|
|
# measured on this cluster is only which listeners ztunnel opens.
|
|
# Provable at the first namespace to join the mesh - none carries
|
|
# istio.io/dataplane-mode yet.
|
|
# - That the probe-source half works. probeSources is empty in every chart
|
|
# here, so no release reaches that branch. CI proves its render, not its
|
|
# effect.
|
|
#
|
|
# Note where the port lands: it joins the rule that carries the probe port,
|
|
# so once probeSources restricts that rule, 15008 is restricted with it.
|
|
# Whether ztunnel needs a peer of its own is open - it runs with its own pod
|
|
# IPs in istio-system (measured: no hostNetwork on the DaemonSet, Istio
|
|
# 1.30.6), so if one proves necessary it is expressible as a
|
|
# namespaceSelector plus podSelector and needs no unknowable node CIDR.
|
|
ambientMesh: false
|
|
|
|
egress:
|
|
# Additional outbound TCP ports. DNS (UDP and TCP 53) is always allowed and
|
|
# has no switch - a knob whose only other setting breaks every name lookup
|
|
# in the pod is a trap, not a feature.
|
|
#
|
|
# PORTS, NOT DESTINATIONS, and that is a limit of the object rather than
|
|
# laziness: a NetworkPolicy matches CIDRs and selectors and never hostnames,
|
|
# so "only to the database host" cannot be written at all. Each entry
|
|
# permits its port to ANY destination. What the cap still buys is real: a
|
|
# compromised pod cannot open arbitrary outbound connections.
|
|
#
|
|
# 80 and 443 are already allowed, so most bridges need nothing here. Add a
|
|
# port only for a source that serves feeds somewhere else.
|
|
extraPorts: []
|