jklein
4e97097a64
Three changes, all about values that do not do what they promise: 1. Ingress gate (#93): the Ingress template is wrapped in {{- if .Values.ingress.enabled }}. The key already existed in values.yaml with default true but was never read, so switching it off did nothing. Both required() calls for domain and clusterIssuer live inside the Ingress file, so gating also removes the contradiction that one had to supply a domain and issuer in order to turn off an Ingress one does not want. 2. Null-safety for hardening, probes and resources (#99): an override written without children is YAML null and erased the whole default sub-tree, rendering "securityContext: null" - an unhardened container that starts and reports healthy. 3. values.schema.json types (#68 + #99): the blocks covered by the null-safety accept null. This is load-bearing only for keys that have no chart default (e.g. resources.limits): there Helm has nothing to delete, so the null survives into schema validation and a strict "object" type rejected it outright. Rendering with normal values is byte-identical to 7.0.0.
54 lines
2.5 KiB
Plaintext
54 lines
2.5 KiB
Plaintext
{{- $replicas := include "cyberchef.replicas" (dict "scaleDown" .Values.scaleDown "replicas" .Values.cyberchef.replicas) -}}
|
|
CyberChef {{ .Chart.AppVersion }} — release {{ .Release.Name }} in namespace {{ .Release.Namespace }}.
|
|
|
|
{{- if .Values.ingress.enabled }}
|
|
|
|
ACCESS
|
|
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 }}
|
|
|
|
ACCESS — NO INGRESS
|
|
ingress.enabled is false, so this release has no Ingress 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. Set ingress.enabled=true together with
|
|
ingress.domain and ingress.clusterIssuer to publish it instead.
|
|
{{- end }}
|
|
{{ if eq $replicas "0" }}
|
|
SCALED TO ZERO
|
|
{{ if .Values.scaleDown }}scaleDown: true{{ else }}cyberchef.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 }} stays in
|
|
place.{{ end }}
|
|
{{ end }}
|
|
ANYONE WHO REACHES THE URL CAN USE IT
|
|
CyberChef has no login, and this chart adds none. If it must not be open to
|
|
everyone, put authentication in front of it via ingress.annotations — the
|
|
chart merges them into the Ingress, e.g. ingress-nginx external auth or
|
|
basic auth annotations.
|
|
|
|
NOTHING TO BACK UP, NOTHING TO MIGRATE
|
|
CyberChef is a static web app: recipes and inputs are processed in the
|
|
visitor's browser and never reach the server. The pod only serves files and
|
|
holds no state, so app-version upgrades and rollbacks carry no data risk and
|
|
need no migration step.
|
|
{{- if .Values.cyberchef.env }}
|
|
|
|
cyberchef.env HAS NO EFFECT ON THE APP
|
|
cyberchef.env is set. The entries reach the nginx process that serves the
|
|
files, but the served CyberChef bundle is static and reads none of them —
|
|
configuration has to happen in the browser.
|
|
{{- end }}
|