helm-charts/calibre-web-automated/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

secrets:
  # REQUIRED - op:// item path for the 1Password operator, carrying the fields
  # "hardcover-api-token" and "calibre-plugins". Both are needed even if you
  # never use Hardcover: the OnePasswordItem is created unconditionally, and so
  # are the environment reference and the volume. Without this value the render
  # aborts - required() in calibre-web-automated.secret.yaml is the whole
  # enforcement, and values.schema.json cannot help here (README, guideline 12).
  # Before the guard existed it produced an OnePasswordItem with an empty
  # itemPath, the operator had nothing to resolve, the Secret never appeared and
  # the pod could not start.
  cwaSecretRef: null

cwa:
  # Replica count for this workload; 0 is allowed and scales it down.
  # The chart-global scaleDown flag takes precedence.
  replicas: 1
  storage: 10Gi
  storageClass: longhorn
  timezone: "UTC"
  # The upload cap, and it lives entirely in the INGRESS: the chart renders it
  # into nginx.ingress.kubernetes.io/proxy-body-size and
  # nginx.org/client-max-body-size, so it is enforced by the nginx-family
  # controllers and by nothing inside CWA. Consequences worth knowing before
  # trusting it: with ingress.enabled: false it does nothing at all, and in
  # Gateway mode (httpRoute.enabled) it is NOT ENFORCED either - the Gateway
  # API has no body-size field, the limit is the Gateway's own, and this chart
  # deliberately renders no implementation-specific policy object to set it
  # (Gitea #114). NOTES.txt says so in both modes.
  maxUploadFileSize: "10m"
  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. Startup budget = 10s * 30 = 300s.
  startupProbe:
    httpGet:
      path: /
      port: http
    periodSeconds: 10
    timeoutSeconds: 5
    failureThreshold: 30
  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
      memory: 512Mi
      ephemeralStorage: 100Mi
  # Documented deviation from the repo-wide hardening standard: the CWA image
  # (linuxserver.io-style) must start as root — it boots via the s6-overlay
  # init system, whose stage-1/2 setup runs as uid 0 and then drops the app
  # to the PUID/PGID user (1000), so runAsNonRoot/runAsUser are deliberately
  # not set (s6 supervisors stay root, the application runs as uid 1000).
  # readOnlyRootFilesystem is deliberately false: in read-only mode the image
  # disables the PUID/PGID remapping (the runtime uid would silently change
  # from 1000 to the built-in 911 and break existing volume data) and its
  # init fails to write the ImageMagick policy under /etc. Everything else
  # is hardened: no privilege escalation and all capabilities dropped except
  # the minimal set the s6 init/supervision needs (verified against v4.0.6):
  # CHOWN/DAC_OVERRIDE/FOWNER/SETGID/SETUID for the ownership fix-up of
  # /config etc. and the root->PUID drop, KILL so the root supervisor can
  # signal the uid-1000 services (without it the pod cannot shut down
  # cleanly and gets SIGKILLed).
  securityContext:
    pod:
      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.
      #
      # It is orthogonal to the readOnlyRootFilesystem: false deviation above:
      # the filter restricts syscalls, not mount flags, so the s6 init keeps
      # its writable root filesystem and the PUID/PGID remapping to uid 1000
      # stays active. Verified against v4.0.6 under the filter.
      seccompProfile:
        type: RuntimeDefault
    container:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: false
      capabilities:
        drop:
          - ALL
        add:
          - CHOWN
          - DAC_OVERRIDE
          - FOWNER
          - KILL
          - SETGID
          - SETUID
  # Extra environment variables, appended to the ones the chart always sets.
  # Rendered through tpl; value, secretKeyRef and configMapKeyRef forms are
  # supported (see template-chart).
  env: []

ingress:
  # Set to false to omit the Ingress entirely. Nothing inside the pod reads
  # ingress.domain - no environment variable, no probe Host header, no URL the
  # app builds itself - so with the Ingress off, clusterIssuer and domain are
  # both unnecessary. That is still true, but no longer the whole sentence:
  # the HTTPRoute below is a SECOND reader of ingress.domain (while
  # httpRoute.hostnames is empty), so "domain is not needed" holds only while
  # BOTH routing modes are off.
  #
  # Mutually exclusive with httpRoute.enabled below (Gitea #114): with both
  # true the render aborts, naming both values.
  enabled: true
  clusterIssuer: null
  # The public hostname of this release. Read by the Ingress and - when
  # httpRoute.hostnames is empty - by the HTTPRoute, and by nothing else.
  domain: null
  className: nginx
  # Extra annotations for the Ingress; merged with the cert-manager
  # cluster-issuer and proxy-body-size annotations the chart always sets.
  #
  # THESE HAVE NO COUNTERPART IN GATEWAY MODE. The Gateway API has no
  # annotation channel for controller behaviour, so anything configured here is
  # simply gone when httpRoute.enabled is used instead - it is then the
  # Gateway's business, or that of an implementation-specific policy object
  # this chart deliberately does not render. For THIS chart that includes the
  # upload cap: see cwa.maxUploadFileSize above.
  annotations: {}

# Gateway-API alternative to the Ingress above (Gitea #114). Off by default, so
# an existing release is unaffected; exactly one of ingress.enabled and
# httpRoute.enabled may be true.
#
# 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, which is what keeps this chart independent of whether the cluster
# runs nginx-gateway-fabric, Cilium, Envoy Gateway or Istio.
#
# WHAT THIS MODE COSTS HERE: cwa.maxUploadFileSize is not enforced. It exists
# only as an ingress-nginx annotation and the Gateway API has no body-size
# field, so the limit becomes whatever the Gateway enforces. For an e-book
# library that is the one value worth checking before switching - a book above
# the Gateway's default is rejected by the proxy, and nothing in CWA's log says
# a chart value was ignored. NOTES.txt prints this in Gateway mode.
#
# 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: []
  # 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: the HTTPRoute takes a second
  # hostname while the Ingress keeps ingress.domain.
  #
  # Cheap in this chart, because nothing inside the pod follows the hostname:
  # CWA is told its address by nothing, so a second name needs no second value
  # changed with it.
  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 8083 only, and outbound DNS plus TCP 443
  # for metadata lookups (covers and book details from public providers).
  #
  # WHAT IT DOES NOT DO: 443 goes to any destination - the providers are
  # hostnames, which this object cannot match. Inbound 8083 is not restricted
  # by source in the default, because 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 8083, 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 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
  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.
    #
    # Add a port only for a metadata provider or an e-mail/send-to-Kindle setup
    # that does not use 443 - SMTP submission would be 587 or 465.
    extraPorts: []