jklein
b50e9d80dd
Gitea #143, maintainer's instruction. The HBONE port and the redirected probe source are ISTIO CONSTANTS, not standards, so they move from template literals into values with documented defaults - an operator can then correct them when Istio changes a number, without waiting for a chart release. One object under one "enabled", so the two halves still cannot be set separately; two values could drift apart, which is what this design exists to prevent. Every read is null-safe (#99), so a deleted object or one carrying only "enabled: true" falls back to the defaults declared here rather than dereferencing nil - the defect #136 shipped one value away. Provenance now written on each constant: 15008 is Istio's HBONE port, not IANA-registered for this and unknown to Kubernetes; 169.254.7.127 is link-local (RFC 3927, never routed), its IPv6 counterpart carries the same digits plus 1337, and neither the NetworkPolicy API nor the kubelet knows the address - only Istio's data plane rewrites the probe source onto it. Both read for ztunnel 1.30.6, and a change in either fails silently. The exception in ci/run-networkpolicy-test.sh stays pinned to the numbers that test names, and additionally asserts this chart declares the same defaults - never "whatever the value says", which would let a mistyped port in through a configurable field. No version change: nothing is published yet, the default is still off, and the render at defaults is byte-identical - re-diffed against origin/main.
670 lines
35 KiB
YAML
670 lines
35 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. Services and Ingress
|
|
# stay in place; scaleDown: false brings the workloads back up.
|
|
#
|
|
# It does NOT reach into the oauth2-proxy subchart: that chart has its own
|
|
# replicaCount, and a value of this chart cannot override it implicitly. With
|
|
# the proxy enabled, scaling the whole release down means setting
|
|
# oauth2-proxy.replicaCount: 0 as well.
|
|
scaleDown: false
|
|
|
|
secrets:
|
|
# op:// item path for the oauth2-proxy credentials. Read ONLY while the proxy
|
|
# is enabled and still points at the Secret this chart creates for it (see
|
|
# oauth2-proxy.config.existingSecret below); a plain install without the
|
|
# proxy needs no 1Password item at all.
|
|
#
|
|
# The item must carry these three fields, spelled exactly like this, because
|
|
# the operator copies an item's field names into the Secret's keys and the
|
|
# subchart reads them by name:
|
|
#
|
|
# client-id the OIDC client id of the provider application
|
|
# client-secret its client secret
|
|
# cookie-secret 16, 24 or 32 bytes, URL-SAFE base64
|
|
#
|
|
# The cookie-secret is the one that costs an evening. oauth2-proxy decodes it
|
|
# as URL-safe base64 FIRST, so the obvious "openssl rand -base64 32" produces
|
|
# a value containing + and /, the decode fails, and the pod exits with
|
|
# "cookie_secret must be 16, 24, or 32 bytes". Generate it as:
|
|
#
|
|
# openssl rand -base64 32 | tr '+/' '-_'
|
|
#
|
|
# A field spelled differently does not fail the install: the operator writes
|
|
# a Secret without that key and the proxy pod stays in
|
|
# CreateContainerConfigError, which looks like a broken chart.
|
|
oauth2ProxySecretRef: null
|
|
|
|
ytdlpWebPlayer:
|
|
# Replica count for this workload; 0 is allowed and scales it down.
|
|
# The chart-global scaleDown flag takes precedence.
|
|
#
|
|
# More than one replica is possible but shares nothing: each pod keeps its
|
|
# own /data emptyDir, so a video fetched by one pod is invisible to the
|
|
# other, and without session affinity the HLS segment requests of a single
|
|
# playback are spread over both. Raise it only behind an ingress that pins a
|
|
# client to a pod.
|
|
replicas: 1
|
|
# DOCUMENTED DEVIATION FROM THE HARDENING BASELINE - runAsUser/runAsGroup.
|
|
#
|
|
# The upstream image carries no USER instruction and therefore runs as root
|
|
# by default (verified in the published Dockerfile for v1.2.0: python:3.13-
|
|
# alpine, apk add ffmpeg deno, no USER). That is a default, not a
|
|
# requirement: measured, the container runs as an arbitrary uid with
|
|
# readOnlyRootFilesystem: true and the full hardening baseline, serving the
|
|
# UI and completing a real transcode. Everything it writes goes below
|
|
# DATA_PATH and into the cache directory, and both are emptyDirs this chart
|
|
# mounts writable (see storage). So the chart pins a non-root uid rather than
|
|
# following the image, and this deviation is about the NUMBER only - no part
|
|
# of the hardening baseline is relaxed.
|
|
#
|
|
# The uid is arbitrary on purpose (20000, the repo default). Nothing in the
|
|
# image belongs to it - /app is world-readable and read-only here - and no
|
|
# PersistentVolume is involved, so no data is tied to the number.
|
|
securityContext:
|
|
pod:
|
|
runAsNonRoot: true
|
|
runAsUser: 20000
|
|
runAsGroup: 1000
|
|
fsGroup: 1000
|
|
fsGroupChangePolicy: Always
|
|
# RuntimeDefault applies the container runtime's default seccomp filter,
|
|
# which blocks the syscalls a normal workload never makes. It sits in the
|
|
# pod context on purpose: from here it covers every container in the pod
|
|
# including init containers, while a container-level seccompProfile would
|
|
# have to be repeated for each one (and silently missed on the next one
|
|
# added). A container that genuinely needs a different filter can still
|
|
# override it under securityContext.container, which wins over this value.
|
|
seccompProfile:
|
|
type: RuntimeDefault
|
|
container:
|
|
allowPrivilegeEscalation: false
|
|
readOnlyRootFilesystem: true
|
|
runAsNonRoot: true
|
|
capabilities:
|
|
drop:
|
|
- ALL
|
|
add: []
|
|
# The application exposes no health endpoint, so all three probes use "/".
|
|
#
|
|
# What that path costs: it is Flask's index route, which renders the player
|
|
# template and touches neither ffmpeg, yt-dlp nor the network. Measured in
|
|
# k3d it answers in single-digit milliseconds, so probing it every 10s is
|
|
# free even while transcoding runs.
|
|
#
|
|
# What a green probe does NOT prove: that any video can be played. The app
|
|
# fetches its content from the internet at request time; with egress blocked
|
|
# or DNS broken, "/" still answers 200 while every playback fails. See
|
|
# NOTES.txt.
|
|
livenessProbe:
|
|
httpGet:
|
|
path: /
|
|
port: http
|
|
periodSeconds: 10
|
|
timeoutSeconds: 5
|
|
failureThreshold: 3
|
|
readinessProbe:
|
|
httpGet:
|
|
path: /
|
|
port: http
|
|
periodSeconds: 10
|
|
timeoutSeconds: 5
|
|
failureThreshold: 3
|
|
# The startup probe gates liveness/readiness, so those need no
|
|
# initialDelaySeconds. Startup budget = 5s x 30 = 150s, which is generous:
|
|
# the app opened its port in about two seconds in k3d, and the budget only
|
|
# has to cover a slow image pull's first process start.
|
|
startupProbe:
|
|
httpGet:
|
|
path: /
|
|
port: http
|
|
periodSeconds: 5
|
|
timeoutSeconds: 5
|
|
failureThreshold: 30
|
|
# Extra environment variables, APPENDED to the ones the chart sets itself
|
|
# (DATA_PATH and PORT). Values are rendered through tpl; the value,
|
|
# secretKeyRef and configMapKeyRef forms are supported.
|
|
#
|
|
# This is where the application is configured. The upstream offers around
|
|
# twenty switches and this chart deliberately mirrors none of them as its own
|
|
# values: a chart that rebuilds every option is a lie one upstream release
|
|
# later, and it would also have to be kept in values.schema.json. The full,
|
|
# authoritative list is src/example.env in the upstream repository. As of
|
|
# v1.2.0 it holds APP_TITLE, THEME_COLOR, GENERATE_SPRITE_BELOW, AMOLED_BG,
|
|
# MAX_VIDEO_AGE, MAX_VIDEO_DURATION, DEFAULT_QUALITY, MAX_QUALITY, AUTOPLAY,
|
|
# MIN_LIVE_BUFFER, ALWAYS_TRANSCODE, DISABLE_TRANSCODING, MAX_PROCESSES,
|
|
# AUTOSKIP_SB_SEGMENTS, COOKIES_ONLY_ON_FAILURE, PLAYLIST_SUPPORT,
|
|
# AUTO_BG_PLAYBACK, AUDIO_VISUALIZER and PROXY.
|
|
#
|
|
# Do not set DATA_PATH, PORT, HOME or XDG_CACHE_HOME here: those four are the
|
|
# chart's, and a second entry with the same name silently wins (Kubernetes
|
|
# applies the LAST entry of the list) - pointing the app away from its
|
|
# writable volume, off the port the Service and probes use, or its caches
|
|
# back onto the read-only root filesystem.
|
|
#
|
|
# Example:
|
|
# env:
|
|
# - name: APP_TITLE
|
|
# value: "Player"
|
|
# - name: MAX_PROCESSES
|
|
# value: "2"
|
|
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".
|
|
#
|
|
# No CPU limit on purpose (and this is the chart where it matters most):
|
|
# transcoding is what this app does, ffmpeg takes every core it is given,
|
|
# and a CPU limit does not fail a request - it throttles the encoder, which
|
|
# arrives at the viewer as a stuttering stream with nothing in any log.
|
|
#
|
|
# ephemeral-storage is the interesting number here, not memory. Downloaded
|
|
# and transcoded videos live in the /data emptyDir, and an emptyDir counts
|
|
# against the container's ephemeral-storage LIMIT. Going over it does not
|
|
# produce an application error: the kubelet evicts the whole pod, the
|
|
# reason sits on the pod rather than in the app's log, and every video in
|
|
# flight is gone with the emptyDir.
|
|
#
|
|
# Raising this number is the wrong first move. The knobs that decide how
|
|
# much lands there are MAX_VIDEO_AGE (how long a file survives after the
|
|
# last access), MAX_VIDEO_DURATION (upstream default 36000s = 10 hours, an
|
|
# enormous single file) and MAX_PROCESSES (how many can arrive at once) -
|
|
# all three via ytdlpWebPlayer.env. The limit only decides how the excess
|
|
# is discovered.
|
|
limitFactor: 3
|
|
requests:
|
|
cpu: 0.5
|
|
memory: 512Mi
|
|
# 2Gi request -> 6Gi limit at limitFactor 3.
|
|
ephemeralStorage: 2Gi
|
|
ports:
|
|
# The port the application listens on, and the single place it is
|
|
# configured: the chart derives the PORT environment variable from the
|
|
# entry named "http", the Service targets it by that name, and all three
|
|
# probes address it by name too. Changing the number here moves all four
|
|
# together - which is why the chart sets PORT itself instead of leaving it
|
|
# to ytdlpWebPlayer.env, where it could disagree with this list.
|
|
#
|
|
# 5000 is the upstream default (EXPOSE 5000) and unprivileged, so the
|
|
# AVD-KSV-0117 rule about containerPort < 1024 does not apply.
|
|
- containerPort: 5000
|
|
protocol: TCP
|
|
name: http
|
|
|
|
storage:
|
|
# DATA_PATH is set to /data and backed by an emptyDir: the app treats the
|
|
# directory as a cache and removes videos again after MAX_VIDEO_AGE, so there
|
|
# is nothing here worth a PersistentVolume - and nothing that survives a pod
|
|
# restart either. That is deliberate; see NOTES.txt.
|
|
#
|
|
# Optional size caps for the two emptyDirs. Leave them null and the only
|
|
# ceiling is the container's ephemeral-storage limit (see resources above);
|
|
# note that the outcome of hitting either is the same - the kubelet evicts
|
|
# the pod - so a sizeLimit buys a clearer eviction message, not a graceful
|
|
# failure.
|
|
dataSizeLimit: null
|
|
|
|
# The second emptyDir, at /cache, with HOME and XDG_CACHE_HOME pointed at it.
|
|
#
|
|
# EVERY MOUNT HERE WAS MEASURED SEPARATELY, and the result is not the one the
|
|
# reflex predicts. Two runs of the image at uid 20000 with a read-only root
|
|
# filesystem, driven through metadata extraction, HLS transcoding, sprite
|
|
# generation and audio extraction:
|
|
#
|
|
# - /tmp is NEVER written to. Not once, in any of those paths. The usual
|
|
# "read-only rootfs, so mount an emptyDir on /tmp" is dead weight for
|
|
# this image, and it is not mounted here.
|
|
# - $HOME/.cache IS written to, and without it the log carries ten
|
|
# "OSError: [Errno 30] Read-only file system: '/.cache'" lines. Both
|
|
# bundled tools use it: deno for its module cache, yt-dlp for the
|
|
# JavaScript challenge-solver library it fetches from github.com.
|
|
#
|
|
# The failure is a WARNING, not an error - the run continues. What it costs
|
|
# is silent: the challenge-solver library is re-downloaded from github.com on
|
|
# every single extraction instead of once, which turns an outage there, or an
|
|
# egress rule that does not expect it, into broken playback with a warning
|
|
# nobody read. With the volume mounted, both tools' caches land in /cache and
|
|
# the log is clean.
|
|
#
|
|
# Nothing here is worth keeping across a restart - it is a cache in the
|
|
# literal sense, refilled from the network.
|
|
cacheSizeLimit: null
|
|
|
|
ingress:
|
|
# Gates this chart's own Ingress. MUTUALLY EXCLUSIVE WITH httpRoute.enabled -
|
|
# the render aborts when both are true, and the message names both value
|
|
# paths.
|
|
#
|
|
# CORRECTED WITH THE GATEWAY-API SUPPORT (Gitea #114): this used to say that
|
|
# everything the Ingress needs is read only inside its template, and that
|
|
# switching the Ingress off therefore freed BOTH ingress.domain and
|
|
# ingress.clusterIssuer. The second half still holds - the application needs
|
|
# no hostname of its own (no base-URL setting, no absolute links, no
|
|
# url_for(_external=True)) and this mode renders no Certificate, so
|
|
# clusterIssuer is still freed. But ingress.domain is now read by the
|
|
# HTTPRoute as well, so it is freed only when BOTH modes are off.
|
|
#
|
|
# WHO OWNS THE HOST, WITH THE PROXY ENABLED: the proxy sits in the data path,
|
|
# so with oauth2-proxy.enabled=true the Ingress belongs to the PROXY
|
|
# (oauth2-proxy.ingress) and this one is switched off; the app is then
|
|
# reached only through its Service. Leaving both on for the same host does
|
|
# not produce a merged route - ingress-nginx's admission webhook rejects the
|
|
# second Ingress outright - so the chart refuses to render that combination.
|
|
# Leaving this one on for a DIFFERENT host is allowed and means exactly what
|
|
# it says: an unauthenticated way past the proxy.
|
|
enabled: true
|
|
clusterIssuer: null
|
|
domain: null
|
|
className: nginx
|
|
# Extra annotations for the Ingress; merged with the cert-manager
|
|
# cluster-issuer annotation the chart always sets.
|
|
#
|
|
# INERT IN GATEWAY MODE - the Gateway API has no annotation channel for
|
|
# controller behaviour. Note which annotation this is NOT about: the 16k
|
|
# proxy-buffer-size this chart recommends belongs on the PROXY's Ingress
|
|
# (oauth2-proxy.ingress.annotations), and the subchart keeps rendering an
|
|
# Ingress in either mode, so that one is unaffected by the switch.
|
|
annotations: {}
|
|
|
|
# THE GATEWAY-API ALTERNATIVE TO THE INGRESS (Gitea #114).
|
|
#
|
|
# Mutually exclusive with ingress.enabled - the render aborts when both are
|
|
# true. The chart renders ONLY an HTTPRoute with parentRefs: no Gateway, no
|
|
# class, no Certificate, and no implementation-specific policy object. Class
|
|
# and certificate sit on the Gateway and its listeners and belong to the
|
|
# platform (cluster-config).
|
|
#
|
|
# BEFORE SWITCHING THIS ON, KNOW WHAT IT DOES NOT DO. The oauth2-proxy
|
|
# SUBCHART HAS NO GATEWAY SUPPORT and this chart cannot give it one - upstream's
|
|
# chart is consumed as it comes (README, "Chart dependencies"), so it renders an
|
|
# Ingress or nothing. In the RECOMMENDED configuration, where the proxy sits in
|
|
# the data path and owns the host while this chart's own routing object is off,
|
|
# the object that publishes the release is THE SUBCHART'S INGRESS whatever this
|
|
# value says. Turning httpRoute on there buys nothing.
|
|
#
|
|
# This route is for the other two cases:
|
|
# - the proxy switched off (oauth2-proxy.enabled: false), so this chart
|
|
# publishes the application itself;
|
|
# - the application on a host of ITS OWN beside the proxy's host, which is
|
|
# allowed and means exactly what it says: an unauthenticated way past the
|
|
# proxy.
|
|
#
|
|
# AND THE HOST GUARD IS SHARPER IN THIS MODE, NOT WEAKER. If this chart and the
|
|
# proxy's Ingress claim the SAME host:
|
|
# - in Ingress mode ingress-nginx's admission webhook rejects the second
|
|
# object loudly (the Fleet bundle goes to ErrApplied);
|
|
# - in Gateway mode the webhook NEVER FIRES - it compares Ingress objects
|
|
# with Ingress objects, and an HTTPRoute is a different kind. Both objects
|
|
# stay valid and one hostname is served over two data paths that are NOT
|
|
# equivalent: the proxy's Ingress goes through authentication, this chart's
|
|
# HTTPRoute goes straight to the application. Which one a client reaches
|
|
# depends on DNS, so it is an authentication bypass that comes and goes
|
|
# with a record and that nothing in Kubernetes reports.
|
|
# The chart therefore refuses to render that combination in BOTH modes, via the
|
|
# ytdlp-web-player.published helper (ingress.enabled OR httpRoute.enabled).
|
|
# Before #114 that guard asked ingress.enabled, which is false by construction
|
|
# in Gateway mode - it would have gone silent exactly where it matters most.
|
|
#
|
|
# NOTHING WAS MEASURED ON A LIVE INGRESS OF THIS CHART, because there is none.
|
|
# Checked 2026-10-12: the release runs in namespace jlab-player with both
|
|
# Deployments Ready, and not one of the cluster's 23 Ingress objects is in that
|
|
# namespace - neither this chart's nor the subchart's. What publishes it
|
|
# instead could not be determined from this workspace (its identity may not
|
|
# list httproutes or secrets). An open question, not a guess.
|
|
#
|
|
# THE GATEWAY-API CRDs MUST BE PRESENT. The chart cannot detect them
|
|
# (.Capabilities.APIVersions is unreliable at template time) and an HTTPRoute
|
|
# without them fails at install, so this is a value and not a guess.
|
|
httpRoute:
|
|
enabled: false
|
|
|
|
# The Gateway(s) the route attaches to - a platform object, usually in
|
|
# another namespace, whose listener must allow this namespace in
|
|
# allowedRoutes. Entries 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: []
|
|
|
|
# Empty means [ingress.domain], so the hostname has one source of truth. Set
|
|
# explicitly only to publish under a different or an additional name - which
|
|
# is how a migration from the Ingress runs, and also how the application is
|
|
# given a host of its own beside the proxy's. The host guard reads this list
|
|
# too, so a hostname set here that the proxy's Ingress also claims is caught.
|
|
hostnames: []
|
|
|
|
# --- oauth2-proxy subchart -------------------------------------------------
|
|
#
|
|
# Everything below this line is passed to the oauth2-proxy chart
|
|
# (https://oauth2-proxy.github.io/manifests), not read by this chart - with the
|
|
# single exception of oauth2-proxy.enabled and oauth2-proxy.ingress.hosts,
|
|
# which the two guards above consult. The keys are the subchart's, the full
|
|
# list of them is in its own values.yaml, and this chart does not restrict
|
|
# them: whatever it does not set here stays at the subchart's default.
|
|
#
|
|
# The subchart's own conventions are NOT this repo's. It is upstream software
|
|
# and treated as such - we do not patch its templates, do not re-harden its
|
|
# workload and do not re-implement its values. Two consequences worth knowing
|
|
# before looking for them:
|
|
#
|
|
# - Its resource limits, probes and security context follow ITS defaults, not
|
|
# the rules in README "Chart style guidelines". Set them under
|
|
# oauth2-proxy.resources / .securityContext / .livenessProbe if you want
|
|
# this repo's shape; the chart does not impose it on you.
|
|
# - The 1Password operator's auto-restart and this repo's checksum/config
|
|
# mechanism do not reach into it either. Repointing
|
|
# secrets.oauth2ProxySecretRef at a different item changes the
|
|
# OnePasswordItem this chart renders, but nothing in the subchart's pod
|
|
# template - restart it by hand:
|
|
# kubectl -n <ns> rollout restart deployment/<release>-oauth2-proxy
|
|
#
|
|
# The subchart itself has a conditional dependency on redis-ha (off by
|
|
# default), which is why a helm dependency update here pulls two repositories.
|
|
oauth2-proxy:
|
|
# Off by default. The chart is fully usable without it, nothing of the
|
|
# subchart is rendered, and no oauth2-proxy image is pulled.
|
|
#
|
|
# READ THIS BEFORE LEAVING IT OFF: the application has NO authentication of
|
|
# any kind and this chart adds none. An Ingress without the proxy is an open
|
|
# instance - anyone who reaches the URL can make it fetch and transcode
|
|
# arbitrary videos from the internet, on your egress and your CPU.
|
|
enabled: false
|
|
|
|
# Whether a new proxy version reaches the cluster is decided by the
|
|
# dependency version in Chart.yaml, not here - see the comment at that line.
|
|
# It is the only remaining path for a proxy update, because the subchart is
|
|
# invisible to everything that watches Helm release versions.
|
|
|
|
ingress:
|
|
# With the proxy enabled this is the Ingress that should be on, and
|
|
# ingress.enabled above the one that should be off. Set hosts to the same
|
|
# single host the app would otherwise carry.
|
|
enabled: false
|
|
className: nginx
|
|
# hosts:
|
|
# - player.example.com
|
|
# tls:
|
|
# - secretName: tls-player-example-com
|
|
# hosts:
|
|
# - player.example.com
|
|
annotations: {}
|
|
# cert-manager.io/cluster-issuer: letsencrypt
|
|
# # The second half of the 4kB cookie trap below: the response carrying
|
|
# # the session cookie does not fit in ingress-nginx's default 4k proxy
|
|
# # buffer, and what the browser gets is a 502 AFTER a successful login.
|
|
# nginx.ingress.kubernetes.io/proxy-buffer-size: "16k"
|
|
|
|
config:
|
|
# The Secret holding client-id, client-secret and cookie-secret. This chart
|
|
# renders it as an OnePasswordItem (see secrets.oauth2ProxySecretRef above)
|
|
# exactly while this value still names it; point it at a Secret of your own
|
|
# and the chart creates none.
|
|
#
|
|
# The subchart runs this string through tpl, so .Release.Name resolves.
|
|
# .Chart.Name would NOT: inside the subchart it is "oauth2-proxy", so the
|
|
# parent chart name is written out literally here.
|
|
existingSecret: '{{ .Release.Name }}-ytdlp-web-player-oauth2-proxy-secret'
|
|
|
|
# The proxy's whole configuration, and the reason it is a configFile rather
|
|
# than the structured config.upstreams: the subchart emits config.upstreams
|
|
# with toJson and WITHOUT tpl, so a {{ .Release.Name }} written there ends
|
|
# up in the manifest verbatim as those eleven characters. config.configFile
|
|
# is passed through "tpl ... $", which is what makes the release name
|
|
# reachable at all. A wrong upstream here is not a render error - it is a
|
|
# 404 after a successful login, in production.
|
|
configFile: |
|
|
email_domains = ["*"]
|
|
upstreams = ["http://{{ .Release.Name }}-ytdlp-web-player-service:80"]
|
|
|
|
# Trust X-Forwarded-*. Without it the proxy considers every request
|
|
# plain http, and builds its redirect back to http:// - behind a
|
|
# TLS-terminating Ingress that is a redirect loop the moment a login
|
|
# completes.
|
|
reverse_proxy = true
|
|
|
|
# Keep id_token and access_token OUT of the session cookie. With them in,
|
|
# a user with a longer group list produces a cookie past the browsers'
|
|
# 4kB limit; the browser drops it and the request comes back as HTTP 502
|
|
# AFTER a successful login - with "[AuthSuccess]" in the proxy's log,
|
|
# which is why this one is hunted in the wrong place for hours.
|
|
#
|
|
# It is incompatible with pass_access_token, set_authorization_header and
|
|
# pass_authorization_header: switch any of those on together with this
|
|
# and the proxy refuses to start at all. This app needs none of them - it
|
|
# reads no identity headers whatsoever.
|
|
session_cookie_minimal = true
|
|
|
|
# Set these to your provider. Example for an OIDC provider:
|
|
# provider = "oidc"
|
|
# oidc_issuer_url = "https://sso.example.com/application/o/player/"
|
|
# redirect_url = "https://player.example.com/oauth2/callback"
|
|
|
|
# Leave this off. With alphaConfig.enabled=true the subchart generates a
|
|
# configuration WITHOUT any upstreams and ignores config.configFile
|
|
# silently - the login then succeeds and the app answers 404, because the
|
|
# proxy has nothing to forward to. It is off in the subchart's defaults too;
|
|
# it is spelled out here because switching it on looks like an upgrade.
|
|
alphaConfig:
|
|
enabled: false
|
|
|
|
# ---------------------------------------------------------------------------
|
|
# 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 5000 only, and outbound DNS plus TCP 80
|
|
# and 443 to ANY destination - fetching media is the application, and this
|
|
# object cannot name a host.
|
|
#
|
|
# WHAT IT DOES NOT COVER: THE OAUTH2-PROXY SUBCHART'S PODS. This policy
|
|
# selects this chart's own workload by its app label. The subchart renders
|
|
# its own Deployment with its own labels and ships no policy, so with the
|
|
# proxy enabled the pod that actually faces the Ingress is unrestricted in
|
|
# both directions. That is a gap in the convention, not a choice of this
|
|
# chart: an upstream chart is consumed as it comes (README, "Chart
|
|
# dependencies"). Do not read "this chart has a NetworkPolicy" as "this
|
|
# release is covered".
|
|
#
|
|
# Inbound 5000 is not restricted by source in the default (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 the port named "http" (5000), which 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.
|
|
# BOTH NUMBERS BELOW ARE ISTIO CONSTANTS, NOT STANDARDS, and they are values
|
|
# rather than template literals for exactly that reason: a vendor constant
|
|
# can change, and an operator should be able to correct it without waiting
|
|
# for a chart release. Their provenance is written on each one.
|
|
#
|
|
# DELETING THIS OBJECT IS SAFE. Every read falls back to the defaults
|
|
# declared here (#99), so "ambientMesh: null", or an object carrying only
|
|
# "enabled: true", renders the documented defaults instead of failing.
|
|
ambientMesh:
|
|
# The switch. Everything else here is inert while it is false, and the
|
|
# chart renders exactly as it did before the object existed.
|
|
enabled: false
|
|
|
|
# ISTIO'S HBONE PORT. A constant Istio chose, not a standard: not
|
|
# registered with IANA for this, prescribed by no protocol, and unknown to
|
|
# Kubernetes. Read for ztunnel 1.30.6 (measured on this cluster: ztunnel
|
|
# opens [::]:15008 as its inbound listener).
|
|
#
|
|
# If Istio changes it, a pod in the mesh cannot be reached. Change it here
|
|
# in all 30 charts AND in the pinned expectation inside
|
|
# ci/run-networkpolicy-test.sh - the test is deliberately what forces
|
|
# someone to look, because the exception it grants this port is pinned to
|
|
# the number IT knows and not to whatever this value says. A value-driven
|
|
# exception would let a mistyped port through, which is the hole design A
|
|
# of #143 was rejected for.
|
|
#
|
|
# NOT MEASURED: that this port ALONE suffices comes from Istio's
|
|
# documentation. Measured here is only which listeners ztunnel opens, and
|
|
# no namespace carries istio.io/dataplane-mode yet.
|
|
port: 15008
|
|
|
|
# SOURCES THE KUBELET'S PROBES ARRIVE FROM ONCE ISTIO HAS REDIRECTED THEM.
|
|
#
|
|
# NOT THE SAME VALUE AS networkPolicy.probeSources one level up, and the
|
|
# two are easy to confuse, so:
|
|
#
|
|
# networkPolicy.probeSources
|
|
# YOUR worker node CIDRs. Empty by default, and empty means the
|
|
# probe rule is OPEN. The chart cannot know these addresses.
|
|
# networkPolicy.ingress.ambientMesh.redirectedProbeSources
|
|
# ISTIO's rewrite address. Shipped filled, because unlike the node
|
|
# IPs it is a constant the chart CAN know. Only rendered where the
|
|
# rule above is restricted, i.e. where probeSources is non-empty.
|
|
#
|
|
# WHERE 169.254.7.127 COMES FROM - vendor magic, not protocol:
|
|
#
|
|
# - LINK-LOCAL, 169.254.0.0/16 (RFC 3927): a range reserved for
|
|
# node-local use that is never routed - exactly the range one picks a
|
|
# vendor's magic address out of.
|
|
# - Istio's IPv6 counterpart gives it away:
|
|
# fd16:9254:7127:1337:ffff:ffff:ffff:ffff carries the SAME DIGITS
|
|
# (9254:7127 is 169.254.7.127) plus 1337. Numbers built that way are
|
|
# vendor constants, not protocols.
|
|
# - KUBERNETES DOES NOT KNOW THIS ADDRESS. Neither the NetworkPolicy API
|
|
# nor the kubelet has any notion of it; only Istio's own data plane
|
|
# rewrites the probe source onto it.
|
|
#
|
|
# Read for ztunnel 1.30.6. IF ISTIO CHANGES IT, THE FAILURE IS SILENT:
|
|
# probes would be dropped, and only where probeSources is non-empty - which
|
|
# is nowhere in this repository today - so nothing here and nothing in
|
|
# Kubernetes would report it. What to re-check then: the address Istio's
|
|
# release notes name for probe redirection, this list in all 30 charts, and
|
|
# the pinned expectation in ci/run-networkpolicy-test.sh.
|
|
#
|
|
# A LIST, not a string, and the one case where that does not contradict "a
|
|
# constant, not a configuration": on a DUAL-STACK cluster BOTH entries are
|
|
# needed at the same time, not one of two. This cluster is SingleStack
|
|
# IPv4, so the IPv6 counterpart is left out - an ipBlock of the wrong
|
|
# family is accepted by the API server and matches nothing. Add it
|
|
# ALONGSIDE, never instead, if the cluster gains IPv6.
|
|
#
|
|
# Clearing this list restores the default rather than removing the ipBlock,
|
|
# deliberately: the two halves of this switch are not separable. To not
|
|
# open the port at all, set enabled: false.
|
|
#
|
|
# UNPROVEN IN OPERATION: probeSources is empty in every chart here, so no
|
|
# release reaches this branch. CI proves the render, not the effect.
|
|
redirectedProbeSources:
|
|
- 169.254.7.127/32
|
|
|
|
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. Add a port only for a source that serves
|
|
# media elsewhere.
|
|
extraPorts: []
|