helm-charts/rss-bridge/values.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: []