helm-charts/bentopdf/templates/NOTES.txt

{{- $replicas := include "bentopdf.replicas" (dict "scaleDown" .Values.scaleDown "replicas" .Values.bentopdf.replicas) -}}
{{- $httpRoute := .Values.httpRoute | default dict -}}
{{- $hostnames := $httpRoute.hostnames | default list -}}
{{- if not $hostnames -}}
{{- $hostnames = list .Values.ingress.domain -}}
{{- end -}}
BentoPDF {{ .Chart.AppVersion }} — release {{ .Release.Name }} in namespace {{ .Release.Namespace }}.

{{- if .Values.ingress.enabled }}

ACCESS — INGRESS MODE (ingress.enabled: true, httpRoute.enabled: false)
  https://{{ .Values.ingress.domain }}

  The certificate is requested by cert-manager through the "{{ .Values.ingress.clusterIssuer }}"
  cluster issuer. Until it has been issued the browser shows a warning; follow it with

    kubectl -n {{ .Release.Namespace }} get certificate tls-{{ .Release.Name }}-{{ .Chart.Name }}-ingress

  This chart has no secrets and no volumes — the two ingress values above are
  everything an installation needs.
{{- else if $httpRoute.enabled }}

ACCESS — GATEWAY MODE (httpRoute.enabled: true, ingress.enabled: false)
{{- range $hostnames }}
  https://{{ . }}
{{- end }}

  This release renders an HTTPRoute ({{ .Release.Name }}-{{ .Chart.Name }}-httproute) and NOTHING else
  of the routing path — no Gateway, no class, no Certificate. Three things
  therefore belong to the cluster and not to this chart, and if any of them is
  missing the hostname above simply does not answer:

    1. The Gateway-API CRDs. Without them this install would have failed, so
       they are present — nothing to check.
    2. The Gateway named in httpRoute.parentRefs
{{- range $httpRoute.parentRefs }}
         {{ .name }}{{ if .namespace }} in namespace {{ .namespace }}{{ end }}{{ if .sectionName }}, listener {{ .sectionName }}{{ end }}
{{- end }}
       must exist AND its listener must allow routes from this namespace
       ({{ .Release.Namespace }}) in allowedRoutes. A rejected attachment is
       visible only in the route's status:

         kubectl -n {{ .Release.Namespace }} get httproute {{ .Release.Name }}-{{ .Chart.Name }}-httproute -o yaml

       Read status.parents[].conditions — "Accepted: True" and
       "ResolvedRefs: True" is what a working attachment looks like. An empty
       status means no controller has looked at the route at all.
    3. The TLS certificate for the hostname, on the Gateway's listener.
       ingress.clusterIssuer is NOT used in this mode and is not required —
       the chart renders no Certificate here, so there is no
       tls-{{ .Release.Name }}-{{ .Chart.Name }}-ingress secret and nothing for cert-manager to do
       on behalf of this release.

  AND TWO THINGS THIS MODE TAKES AWAY FROM YOU, both because the Gateway API
  has no annotation channel and this chart renders no implementation-specific
  policy object on purpose:

    * THE X-Robots-Tag HEADER. A publicly reachable instance gets indexed, and
      its pages carry a canonical link to the vendor's site. In Ingress mode
      ingress.annotations is the lever (see values.yaml); here there is none in
      the chart at all — the header has to be added at the Gateway, or the
      instance has to not be public.
    * THE REPAIR FOR A PROXY THAT MANGLES RESPONSES. See the two notes below on
      the cross-origin headers and on .mjs; in this mode neither can be fixed
      from this chart.
{{- else }}

ACCESS — NEITHER INGRESS NOR HTTPROUTE
  ingress.enabled and httpRoute.enabled are both false, so this release has no
  Ingress, no HTTPRoute and no certificate; ingress.domain and
  ingress.clusterIssuer are not needed. The app is only reachable inside the
  cluster, as
  {{ .Release.Name }}-{{ .Chart.Name }}-service:80. To open it locally:

    kubectl -n {{ .Release.Namespace }} port-forward svc/{{ .Release.Name }}-{{ .Chart.Name }}-service 8080:80

  Then browse to http://localhost:8080. To publish it instead, set either
  ingress.enabled=true with ingress.domain and ingress.clusterIssuer, or
  httpRoute.enabled=true with ingress.domain and httpRoute.parentRefs.
{{- end }}
{{ if eq $replicas "0" }}
SCALED TO ZERO
  {{ if .Values.scaleDown }}scaleDown: true{{ else }}bentopdf.replicas: 0{{ end }} — the deployment runs with replicas: 0, so the endpoint
  above does not answer until you set it back and upgrade again. Service{{ if .Values.ingress.enabled }} and
  Ingress stay in place, so the certificate is not re-issued.{{ else if $httpRoute.enabled }} and
  HTTPRoute stay in place, so the route keeps pointing at a Service with no
  endpoints — the Gateway answers with an error of its own rather than with
  nothing.{{ else }} stays in
  place.{{ end }}
{{ end }}
A GREEN POD ONLY PROVES DELIVERY
  BentoPDF computes in the visitor's browser: not one of its tools runs in
  this pod, which serves static files and nothing else. The probes hit "/"
  because the image has no health endpoint, so they prove that nginx is
  handing out index.html — no more. Whether PDF processing works is a
  question about the browser, not about this release.

TWO HEADERS HAVE TO SURVIVE YOUR PROXY
  The image sends Cross-Origin-Opener-Policy: same-origin and
  Cross-Origin-Embedder-Policy: credentialless. Without both arriving at the
  browser there is no SharedArrayBuffer, and the LibreOffice-backed
  conversions (Word, Excel, PowerPoint) fail while everything else keeps
  working. Check them through the published URL, not at the pod:

    curl -sI https://{{ if .Values.ingress.enabled }}{{ .Values.ingress.domain }}{{ else if $httpRoute.enabled }}{{ first $hostnames }}{{ else }}<host>{{ end }}/ | grep -i cross-origin

  The image sends them itself, so they arrive in both modes unless something
  in the path strips or rewrites them. The difference is the repair: in Ingress
  mode ingress.annotations can put them back, in Gateway mode that channel does
  not exist and it is the Gateway's business. Same for the .mjs MIME type (see
  values.yaml).

ANYONE WHO REACHES THE URL CAN USE IT
{{- if $httpRoute.enabled }}
  BentoPDF has no login, and this chart adds none. That is defensible here —
  the server takes nothing in, stores nothing and has no session — but a
  public instance also gets indexed, and its pages carry a canonical link to
  the vendor's site. In GATEWAY MODE there is no place in this chart for either
  fix: the Gateway API has no annotation channel, so the X-Robots-Tag snippet
  documented in values.yaml has NO counterpart here, and the chart renders no
  implementation-specific policy object on purpose (it would bind the chart to
  one Gateway implementation). Both have to happen at the Gateway — or the
  instance must not be publicly reachable.
{{- else }}
  BentoPDF has no login, and this chart adds none. That is defensible here —
  the server takes nothing in, stores nothing and has no session — but a
  public instance also gets indexed, and its pages carry a canonical link to
  the vendor's site. Both are addressed through ingress.annotations; see
  values.yaml. Note that this escape hatch exists in Ingress mode only:
  httpRoute.enabled has no annotation channel at all.
{{- end }}

NOTHING TO BACK UP, NOTHING TO MIGRATE
  No database, no volumes, no uploads: documents never leave the visitor's
  device. App-version upgrades and rollbacks carry no data risk.
{{- if .Values.bentopdf.config }}

TOOLS ARE DISABLED VIA config.json
  bentopdf.config is set and is served as /config.json. A change here rolls
  the pods (checksum/config), but browsers may keep the old file for up to a
  week — the image serves .json with Cache-Control: max-age=604800. Verify
  what is actually being served with:

    kubectl -n {{ .Release.Namespace }} exec deploy/{{ .Release.Name }}-{{ .Chart.Name }}-deployment -- wget -qO- localhost:8080/config.json
{{- end }}
{{- if .Values.bentopdf.env }}

bentopdf.env HAS NO EFFECT ON THE APP — AND THREE VALUES BREAK THE POD
  The served BentoPDF bundle is static and reads no environment variables;
  entries only reach nginx and its entrypoint scripts. Beware of PORT,
  DISABLE_IPV6 and ROBOTS_NOINDEX: all three rewrite files with "sed -i" and
  abort the entrypoint on a read-only root filesystem, so the pod never
  starts. Using them means also setting
  securityContext.container.readOnlyRootFilesystem: false.
{{- end }}
{{- if .Values.networkPolicy.enabled }}

NETWORKPOLICY IS ACTIVE — WHAT IT CAPS, AND WHAT IT DOES NOT
  {{ .Release.Name }}-{{ .Chart.Name }}-networkpolicy selects this workload's pods.
  Inbound: TCP 8080 only. Outbound: DNS{{ with .Values.networkPolicy.egress }}{{ with .extraPorts }} plus TCP {{ join ", " . }}{{ end }}{{ end }} — the documents are
  processed in the browser, so the pod needs nothing more.

  Three limits belong in the same breath, because none of them is visible in
  the object itself:

  - EGRESS IS BY PORT, NEVER BY DESTINATION. A NetworkPolicy matches CIDRs and
    selectors and cannot express a hostname, so every egress rule permits its
    port to ANY address. That is a limit of the object, not a shortcut — this
    cluster's CNI (Canal: Flannel plus Calico) has no FQDN rule either. An
    outbound port the chart does not know about is BLOCKED: add it to
    networkPolicy.egress.extraPorts, and expect to find out through an
    application-level connection error rather than through this object.
{{- if .Values.networkPolicy.probeSources }}
  - THE PROBE PATH IS RESTRICTED in this release, because
    networkPolicy.probeSources is set to
      {{ join ", " .Values.networkPolicy.probeSources }}
    Probes come from the IP of the WORKER NODE running the pod. If none of those
    CIDRs covers the node this pod lands on, the kubelet's probes are dropped
    and THE POD NEVER BECOMES READY — the rollout then times out and the symptom
    looks like a broken application. Compare

      kubectl -n {{ .Release.Namespace }} describe pod -l app={{ .Release.Name }}-{{ .Chart.Name }}-deployment

    against `kubectl get node -o wide`.
{{- else }}
  - THE PROBED PORT IS OPEN INSIDE THE CLUSTER. networkPolicy.probeSources is
    empty, so that rule carries no source selector at all and any pod the CNI
    routes to can reach it. Not from the internet — but this is NOT pod-level
    isolation. Narrowing it means listing the worker node IPs in
    networkPolicy.probeSources, because the kubelet probes from the node's own
    address and the chart cannot know it; a wrong guess there leaves the pod
    permanently un-Ready.
{{- end }}
  - IT IS ONLY A BOUNDARY WHERE THE CNI ENFORCES POLICIES. Where it does not,
    this object is accepted and filters nothing, so everything reads as
    configured while nothing is filtered. `kubectl -n {{ .Release.Namespace }} get networkpolicy`
    shows the object exists; only a connection attempt from an unrelated
    namespace shows that it bites.

  Switch it off with networkPolicy.enabled: false.
{{- end }}