Files
helm-charts/ytdlp-web-player/values.yaml
T
jklein e4b41577ae feat(ytdlp-web-player): Gateway-API as an alternative to the Ingress
Group 3 of the #114 sweep, last chart - and the one that carried the group-2
pattern this sweep was told to look for. It reads ingress.enabled OUTSIDE its
Ingress template, in ytdlp-web-player.validate, and in Gateway mode
ingress.enabled is false by construction, so that guard would have gone
silent. Fixed with ytdlp-web-player.published = ingress.enabled OR
httpRoute.enabled - the freesailarr.published / sure.publishedOverTls shape,
identical to ingress.enabled while httpRoute.enabled is false, which is why it
changes no existing render.

AND THE GUARD IS NEEDED MORE IN GATEWAY MODE, NOT LESS. It refuses to publish
the application and the oauth2-proxy on the same host:

  - In INGRESS mode the consequence of ignoring it is loud: ingress-nginx's
    admission webhook rejects the second Ingress and 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 - so nothing rejects
    anything, both objects stay valid, and one hostname is served over two
    data paths that are NOT equivalent: the proxy's Ingress goes through
    AUTHENTICATION and this chart's HTTPRoute goes straight to the
    application. Which one a client reaches depends on what DNS resolves to.
    That is an authentication bypass that comes and goes with a DNS record and
    that no Kubernetes object reports.

So the Gateway-mode abort has its own message saying exactly that. Both
messages exercised, plus the collision reached through httpRoute.hostnames
rather than through the ingress.domain fallback, and the guard still firing
when only the Deployment is rendered.

THE SUBCHART HAS NO GATEWAY SUPPORT, and this chart cannot give it one -
upstream's chart is consumed as it comes (README, "Chart dependencies"). It
renders an Ingress or nothing. So in the RECOMMENDED configuration, where the
proxy sits in the data path and owns the host, the publishing object is the
SUBCHART'S INGRESS in both of this chart's modes, and turning httpRoute on
buys nothing. The route is for the proxy-disabled case, or for the application
on a host of its own - which is the documented unauthenticated bypass. Said in
the template header, in values.yaml, in the schema and in the proxy branch of
NOTES.txt, because someone migrating hosts will otherwise set the value and
wonder why nothing moved.

The 16k proxy-buffer-size this chart recommends is NOT lost by this switch,
and that needed stating rather than assuming: it belongs on the PROXY's
Ingress (oauth2-proxy.ingress.annotations) as the second half of the 4kB
session-cookie trap, and the subchart keeps rendering an Ingress. This chart's
own ingress.annotations default is {} and it sets nothing but the cert-manager
annotation, so there is no chart-side annotation loss to name.

CORRECTED CLAIM: values.yaml and the schema both said that everything the
Ingress needs is read only inside its template, so switching it off freed BOTH
ingress.domain and ingress.clusterIssuer. clusterIssuer is still freed; domain
is now read by the HTTPRoute, so it is freed only with both modes off. The
reason the claim was made still holds and is kept - the application has no
base-URL setting and builds no absolute links.

NOTHING WAS MEASURED ON A LIVE INGRESS OF THIS CHART, because there is none.
Measured 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: this workspace's identity may not list httproutes or
secrets, so neither a hand-written HTTPRoute nor the release's Helm values are
readable. Recorded as the open question it is, in values.yaml and in the
overlay, rather than guessed at.

Minor: additive, defaults unchanged. Empty helm template diff against
origin/main with ci/ytdlp-web-player/test-values.yaml.

Part of #114
2026-10-13 08:59:09 +00:00

458 lines
23 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