Flag</th>	ENV</th>	Subcommands</th></tr></thead>
`--deployment</code></td>`	`K8S_SCALE_DEPLOYMENT</code></td>`	both</td></tr>
`--namespace</code></td>`	`K8S_SCALE_NAMESPACE</code></td>`	both</td></tr>
`--replicas</code></td>`	`K8S_SCALE_REPLICAS</code></td>`	scale</td></tr>
`--dry-run</code></td>`	`K8S_SCALE_DRY_RUN</code></td>`	both</td></tr>
`--extra-ca-bundle</code></td>`	`K8S_SCALE_EXTRA_CA_BUNDLE</code></td>`	both</td></tr> </tbody></table> The `--namespace</code> flag exists, but the CronJob does not hardcode it. Instead, the pod reads its own namespace from the Downward API and passes it through as an environment variable. That keeps the ServiceAccount’s Role safely namespace-scoped: the tool can only ever act on Deployments in the namespace where the CronJob itself runs. Not a general-purpose “scale anything anywhere” tool.</p>` Design highlights🔗</a></h2> Minimal RBAC via the scale</code> subresource🔗</a></h3> Setting replicas does not need patch</code> on the full Deployment. Kubernetes exposes deployments/scale</code> as a dedicated subresource:</p> r</span>ules</span>:</span></span> -</span> a</span>piGroups</span>:</span> [</span>"</span>apps</span>"</span>]</span></span> r</span>esources</span>:</span> [</span>"</span>deployments/scale</span>"</span>]</span></span> v</span>erbs</span>:</span> [</span>"</span>get</span>"</span>,</span> "</span>patch</span>"</span>,</span> "</span>update</span>"</span>]</span></span></code></pre> That is all the scale mode needs. Restart mode does need patch</code> on deployments</code> itself (to update the pod template annotation), so the shipped Role covers both:</p> -</span> a</span>piGroups</span>:</span> [</span>"</span>apps</span>"</span>]</span></span> r</span>esources</span>:</span> [</span>"</span>deployments</span>"</span>]</span></span> v</span>erbs</span>:</span> [</span>"</span>get</span>"</span>,</span> "</span>patch</span>"</span>]</span></span></code></pre> patch</code> on the full Deployment is broader than patch</code> on deployments/scale</code> — RBAC review at deploy time should factor that in when the CronJob is configured for restart mode.</p> Extra-CA bundle merged into the trust store🔗</a></h3> The kube client uses the in-cluster CA from the ServiceAccount token secret automatically. For clusters whose API server certificate is signed by a corporate CA that is not in the SA-mounted ca.crt</code>, --extra-ca-bundle <path></code> reads a PEM file (or a full chain of them) and appends every CERTIFICATE</code> block to kube::Config.root_cert</code>. Non-certificate blocks in the file are filtered out.</p> Rendered in Helm as an optional ConfigMap mount; in Kustomize as an opt-in Component. Neither path forces the mount when there is no corporate CA to add.</p> The rustls 0.23 CryptoProvider gotcha🔗</a></h3> If you build against kube-rs</code> with the rustls-tls</code> feature on the current release, the binary compiles cleanly — and then panics at the first TLS handshake with:</p> Could not automatically determine the process-level CryptoProvider from Rustls crate features</span></span></code></pre> rustls</code> 0.23 no longer picks a crypto backend based on downstream feature flags. The application itself must call rustls::crypto::ring::default_provider().install_default()</code> before any TLS work happens. In k8s-scale-app-rs this runs as the first step in main()</code>.</p> Two notes for anyone hitting the same wall: the panic never fires at compile time, and no test caught it locally because integration tests without a cluster do not open a TLS connection. It only surfaces when the CronJob actually tries to reach the API server.</p> Two deploy paths, independent🔗</a></h3> Helm and Kustomize both ship in the repo, and either can be used on its own:</p> Helm chart</strong> with values-{dev,preprod,prod}.yaml</code>, a mode: scale \| restart</code> toggle that swaps the subcommand argument and drops the unused replicas env, and serviceAccount.create</code> / rbac.create</code> / extraCA.enabled</code> toggles for the pieces that a given cluster may or may not need.</li> Kustomize</strong> with a base that has only the CronJob, plus three opt-in Components (serviceaccount/</code>, rbac/</code>, extra-ca/</code>) that overlays include as needed. Overlays under overlays/{dev,preprod,prod}/</code> set namespace and image tag and a patch that touches only the fields that vary per stage.</li> </ul> No Helm-inside-Kustomize glue, no Kustomize-on-Helm-render. Whichever tool matches an existing pipeline is the one to use.</p> Two container images🔗</a></h2> The default image and a -debug</code> variant, both built in the same GitHub Actions matrix — the production/-debug</code> split itself is a general pattern, covered in more depth in Part 2 of the K8s/OpenShift Best Practices series</a>:</p> File</th> Base</th> Contents</th> Approx. size</th></tr></thead> Containerfile</code></td> registry.access.redhat.com/ubi10/ubi-micro</code></td> Binary + CA trust store + /licenses/</code>, no package manager</td> ≈35 MB</td></tr> Containerfile.debug</code></td> registry.access.redhat.com/ubi10/ubi-minimal</code></td> Everything above + bash</code>, curl</code>, bind-utils</code> (dig</code>)</td> ≈115 MB</td></tr> </tbody></table> ubi10-micro</code> is not fully distroless in the Google sense — bash and coreutils are still there — but it has no package manager and no network tools, which fits the pod’s actual operational surface for a scheduled scale or restart call. The -debug</code> variant exists for the day a pod loops in ImagePullBackOff</code> or a network policy silently drops the API-server traffic and someone needs to kubectl exec</code> in with tools to check.</p> Why UBI10🔗</a></h3> The base itself, not just the two variants built from it, was a deliberate choice. I went with Red Hat’s UBI over an Alpine or a generic Docker Hub base image for one reason: it gives the image a level of maintenance stability I don’t have to police myself — CVE scanning and rebuilds are Red Hat’s job, not something I track on my own. That comes with a tradeoff worth stating plainly: UBI is not “digitally sovereign” in the sense the upcoming Digital Sovereignty in Practice series covers — it is a US vendor’s supply chain, the same as pulling from Docker Hub or almost any other public registry would be. I did not find a base that solved that concern without giving up the maintenance guarantees I wanted, so UBI10 here is a compromise I made deliberately, not a claim that the underlying problem is solved.</p> Both images ship an aggregated /licenses/LICENSES.txt</code> bundled with cargo-about</code> during the container build, generated from a whitelist of accepted SPDX identifiers. A new dependency that pulls in an unfamiliar license fails the container build on purpose.</p> Supply chain🔗</a></h2> The build-publish workflow</a> runs three jobs on every push, plus a release job on tag pushes:</p> test</code></strong> — cargo fmt --check</code>, cargo clippy -D warnings</code>, cargo test --release</code>. Cluster tests auto-skip in CI (no KUBECONFIG</code>, no in-cluster SA token).</li> build-image</code></strong> — matrix over Containerfile</code> and Containerfile.debug</code>. Each variant is built with buildx, pushed to ghcr.io/git001/k8s-scale-app-rs</code>, smoke-tested (--version</code>, scale --help</code>, restart --help</code>), then: signed with cosign keyless</strong> via the GitHub OIDC token (no key management — Fulcio issues a short-lived certificate, the signature is logged to Rekor);</li> has an SPDX-JSON SBOM</strong> generated with syft and attached via cosign attest --type spdxjson</code>;</li> has SLSA build provenance</strong> pushed with actions/attest-build-provenance</code>.</li> </ul> </li> publish-chart</code></strong> — helm lint</code> and helm package</code> on every push; OCI push to oci://ghcr.io/git001/charts/k8s-scale-app-rs</code>, plus cosign sign and SLSA provenance only on tag events (avoids overwrite conflicts on GHCR-immutable tags).</li> release</code></strong> (tag events only) — creates the GitHub Release with auto-generated notes from commits since the previous tag, attaches the packaged chart .tgz</code> as an asset, and prepends the release body with pull and verify snippets.</li> </ol> All of that runs with permissions: contents:read, packages:write, id-token:write, attestations:write</code> — the minimum needed for OIDC-based signing plus attestation upload.</p> Verifying a published image🔗</a></h2> A consumer that wants to check what came out of that pipeline needs cosign v2:</p> IMG</span>=</span>g</span>h</span>c</span>r</span>.</span>i</span>o</span>/</span>g</span>i</span>t</span>0</span>0</span>1</span>/</span>k</span>8</span>s</span>-</span>s</span>c</span>a</span>l</span>e</span>-</span>a</span>p</span>p</span>-</span>r</span>s</span>:</span>v</span>1</span>.</span>0</span>.</span>0</span></span> IDENTITY</span>=</span>'</span>^https://github.com/git001/k8s-scale-app-rs/</span>'</span></span> ISSUER</span>=</span>h</span>t</span>t</span>p</span>s</span>:</span>/</span>/</span>t</span>o</span>k</span>e</span>n</span>.</span>a</span>c</span>t</span>i</span>o</span>n</span>s</span>.</span>g</span>i</span>t</span>h</span>u</span>b</span>u</span>s</span>e</span>r</span>c</span>o</span>n</span>t</span>e</span>n</span>t</span>.</span>c</span>o</span>m</span></span> </span> cosign</span> verify</span> \</span></span> -</span>-certificate-identity-regexp</span> "</span>$</span>IDENTITY</span>"</span> \</span></span> -</span>-certificate-oidc-issuer</span> "</span>$</span>ISSUER</span>"</span> \</span></span> "</span>$</span>IMG</span>"</span></span> </span> cosign</span> verify-attestation</span> -</span>-type</span> spdxjson</span> \</span></span> -</span>-certificate-identity-regexp</span> "</span>$</span>IDENTITY</span>"</span> \</span></span> -</span>-certificate-oidc-issuer</span> "</span>$</span>ISSUER</span>"</span> \</span></span> "</span>$</span>IMG</span>"</span></span> </span> cosign</span> verify-attestation</span> -</span>-type</span> slsaprovenance</span> \</span></span> -</span>-certificate-identity-regexp</span> "</span>$</span>IDENTITY</span>"</span> \</span></span> -</span>-certificate-oidc-issuer</span> "</span>$</span>ISSUER</span>"</span> \</span></span> "</span>$</span>IMG</span>"</span></span></code></pre> For enforcement inside the cluster, a cosign-aware admission controller — Kyverno</a>, Sigstore policy-controller</a>, or Connaisseur</a> — can turn the signature into a hard gate that rejects any pod trying to pull an image that was not produced by exactly this workflow. That is a separate deployment concern; the tool repo does not ship the policy itself.</p> Mirroring the image into another registry🔗</a></h2> Verifying a signature only works if the signature actually travels with the image. Not every docker pull && docker push</code>-style mirroring tool preserves it — some tools do, some quietly drop it, and one (oc-mirror v2</code>) solves a related but entirely different signature problem. I wrote up a full, sourced comparison — Which Tool Mirrors a Cosign-Signed Image into a Private Registry?</a> — with regctl</code> coming out as the most complete option for this specific image.</p> Code and repository🔗</a></h2> Repository: k8s-scale-app-rs on GitHub</a></li> Container images: ghcr.io/git001/k8s-scale-app-rs:v1.0.0</code> and ghcr.io/git001/k8s-scale-app-rs:v1.0.0-debug</code></li> Helm chart: oci://ghcr.io/git001/charts/k8s-scale-app-rs:1.0.0</code></li> </ul> Feedback and PRs welcome.</p> Which Tool Mirrors a Cosign-Signed Image into a Private Registry? 2026-07-06T00:00:00+00:00 TL;DR🔗</a></h2> regctl</code> is the most complete option — it exposes the legacy tag-based signature scheme and the modern OCI 1.1 referrers API as two separate, explicit flags. oras cp -r</code> is the second choice, and the tool cosign’s own project points to now that cosign copy</code> is deprecated. oc-mirror v2</code> looks like it should be on this list but actually solves a different, unrelated signature problem.</p> The problem🔗</a></h2> Verifying a signature only works if the signature actually travels with the image. Anyone mirroring a Cosign-signed image into a private or air-gapped registry needs the copy step itself to carry the signature along, not just the layers — and that is not automatic. Some tools drop it silently, some need a config flag turned on first, and one widely-used tool solves a related but entirely different problem. k8s-scale-app-rs</a> is the worked example throughout this post — its own container images are signed keylessly with cosign, carry an SBOM and SLSA build provenance, and its “Verifying a published image”</a> section shows what verification actually checks. This post is about what happens before</em> verification: getting the signature into the registry the verifier will actually query.</p> A short, sourced comparison, checked directly against each project’s docs/source (as of July 2026):</p> A naming trap worth knowing first🔗</a></h2> Red Hat’s oc-mirror v2</code> — the tool for mirroring into disconnected OpenShift installs — has its own --secure-policy</code>/--remove-signatures</code>/--registries.d</code> flags, but they implement Red Hat’s older “simple signing” scheme: a policy.json</code> plus GPG keys plus an external sigstore:</code> URL (e.g. mirror.openshift.com/pub/openshift-v4/signatures</code> for OpenShift release images). That predates, and has nothing to do with, the CNCF Sigstore project this post’s cosign workflow uses — same word, unrelated mechanism. oc-mirror v2</code> went GA in OpenShift 4.18 (release notes</a>), but its ImageSetConfiguration</code> API is still v2alpha1</code>, and none of Red Hat’s own walkthroughs for it touch Cosign-style signatures at all.</p> Tool comparison🔗</a></h2> Tool</th> Legacy tag-based signature (sha256-<digest>.sig</code>)</th> OCI 1.1 referrers (modern Cosign/SBOM/attestations)</th> Note</th></tr></thead> regctl image copy</code></a></td> --digest-tags</code></td> --referrers</code></td> only tool here with separate, explicit flags for both schemes</td></tr> oras cp -r</code></a></td> via -r</code></td> -r</code> (marked “Preview”)</td> --from/to-distribution-spec</code> handles referrers-tag vs. referrers-API mismatches between registries</td></tr> skopeo copy</code></td> opt-in</td> not supported</td> needs use-sigstore-attachments: true</code> under the default-docker</code> key in registries.d</code>, on both source and destination</td></tr> Zot registry sync</code></td> syncLegacyCosignTags</code> (default true</code>)</td> only with preserveDigest: true</code></td> without preserveDigest</code>, Zot re-encodes Docker-format images to OCI on sync, which changes the digest and detaches the signature</td></tr> cosign copy</code></td> yes</td> no</td> deprecated</strong> as of sigstore/cosign#4681</a> (merged 2026-02-04) — the tool itself now points to oras copy -r</code> instead</td></tr> crane copy</code></td> only incidentally, via --all-tags</code></td> no</td> plain manifest/layer copier, no signature awareness at all</td></tr> Harbor replication</td> per Harbor’s own docs, yes</td> open gap (goharbor/harbor#23210</a>)</td> works for the legacy scheme; OCI 1.1 referrers replication is not yet reliable</td></tr> </tbody></table> regctl</code> is the only tool in this comparison that exposes both signature schemes as distinct, intentional flags rather than as a side effect of copying “everything.” For a registry pair that already speaks the OCI 1.1 referrers API end to end, oras cp -r</code> is the other option worth checking — it’s what the cosign project’s own deprecation notice for cosign copy</code> points to.</p> Example: mirroring with regctl🔗</a></h2> Here is an example command to mirror k8s-scale-app-rs</code> itself, signature included, using regctl</code>:</p> regctl</span> image</span> copy</span> \</span></span> -</span>-digest-tags</span> -</span>-referrers</span> \</span></span> ghcr.io/git001/k8s-scale-app-rs:v1.0.0</span> \</span></span> my-private-registry.example.com/k8s-scale-app-rs:v1.0.0</span></span></code></pre>Sources🔗</a></h2> sigstore/cosign PR #4681 — “Deprecate cosign copy”</a></li> sigstore/cosign#4335 — Complete OCI 1.1 Referrers API Support Across All Cosign Commands</a></li> sigstore/cosign#4564 — cosign verify fails after cosign copy (JFrog Artifactory)</a></li> podman-container-tools/skopeo#2061 — sigstore signature copying and use-sigstore-attachments</code></a></li> regctl image copy</code> reference</a></li> oras cp</code> command reference</a></li> goharbor/harbor#23210 — OCI 1.1 referrers not replicated</a></li> Zot registry: mirroring/sync documentation</a></li> OpenShift Container Platform 4.18 release notes</a></li> openshift/oc-mirror — signature-verification.md</a></li> </ul> K8s & OpenShift: Compliance 2026-07-01T00:00:00+00:00 Part 6</a> covered the operational loop: GitOps, observability, cost control, and upgrades. This final part maps the cluster configuration covered throughout this series to the regulatory frameworks that require it — NIS2, DORA, PCI-DSS, HIPAA, and the Cyber Resilience Act (CRA) — and covers the two topics that compliance work adds on top of security: audit logging as evidence and log retention as a contractual obligation.</p> K8s & OpenShift: Security 2026-07-01T00:00:00+00:00 Part 4</a> covered scaling and resilience. This part covers security — not as a checklist to complete before an audit, but as a set of controls that reduce real attack surface and limit the blast radius when something goes wrong.</p> What is Application Security 2026-06-20T00:00:00+00:00 The third part of the (D)DoS series — but a step sideways: this post covers attacks at the Application layer that affect confidentiality and integrity</strong> rather than availability. SQL Injection, Log4Shell, and similar vulnerabilities have a different threat model than the DDoS attacks covered in the technical part</a>.</p> What is a (D)DoS - technical 2026-06-20T00:00:00+00:00 The technical follow-up to the non-technical (D)DoS overview</a>. Covers Layer 3/4 network floods (SYN, UDP, amplification), BGP hijacking, Layer 7 application DDoS, and operational resilience — all focused on availability.</p> Originally published at opensourcerers.org</a>; updated with current attack vectors and technologies.</p> What is a (D)DoS 2026-06-20T00:00:00+00:00 (D)DoS attacks are not just a technical problem — they operate at the Business, Social, and Informational level as well. This post covers the non-technical dimensions; the technical follow-up</a> covers Layer 3/4 network floods, BGP hijacking, TLS handshake attacks, Layer 7 application DDoS, and operational resilience.</p> Originally published at opensourcerers.org</a>; updated with current examples and expanded framing.</p> (D)DoS and Application Security: The Complete Guide 2026-06-19T00:00:00+00:00 This is the index and reading guide for a three-part series on denial-of-service and application security. The first two parts cover availability</strong> attacks — a service being made unreachable or unusable — at levels most people don’t associate with the term “DDoS”: the business level (losing the people who run the service), the social level (manipulating the humans behind it), the informational level (reputational disruption), and finally the technical level most readers expect (network floods, BGP hijacking, Layer 7 exhaustion). The third part is a deliberate step sideways, into application-layer attacks — SQL Injection, Log4Shell, the OWASP Top 10 — that threaten confidentiality and integrity</strong> instead of availability.</p> Elasticsearch vs. OpenSearch vs. Loki vs. Quickwit vs. ClickHouse: Security & Compliance 2026-05-14T00:00:00+00:00 Access control, encryption, and immutability requirements often determine whether a log archive can be used for compliance purposes — and the five systems differ substantially in what they enforce natively versus what must be delegated to infrastructure.</p> This is Part 3 of a five-part series.</p> Full guide:</strong> Elasticsearch vs. OpenSearch vs. Loki vs. Quickwit vs. ClickHouse: The Complete Guide</a></li> Part 1 — Comparison:</a> Storage tiering, compression, resource consumption, query languages, SaaS options</li> Part 2 — Operations:</a> Setup, ingest pipeline, ECS vs. OTel, backup & DR, observability, alerting</li> Part 3 — Security & Compliance — this post:</strong> Encryption, RBAC, WORM / S3 Object Lock</li> Part 4 — UX, Dashboards & Alerts:</a> UI layers, log search UX, cold-tier query behaviour, dashboard building, sharing, alerting</li> Part 5 — Use Case:</a> Vector, Istio/Envoy, nginx, Java on OVH MKS — complete ClickHouse ingestion setup and monthly awffull report</li> </ul>

k8s-scale-app-rs: Scale or Restart a Kubernetes Deployment from a CronJob

2026-07-06T00:00:00+00:00

restart</code></strong> — patches the pod template’s restartedAt</code> annotation, which is the same mechanism kubectl rollout restart</code> uses.</li> </ul> Designed to run as a CronJob</code>. Version 1.0.0 is published; container images and the Helm chart are on ghcr.io</code>, signed with cosign (keyless via GitHub OIDC), and shipped with an SPDX SBOM plus SLSA build provenance.</p>

Why I built it🔗</a></h2>
The classic way to “run kubectl scale</code> on a schedule in a cluster” is to put a kubectl</code> binary into a Job image. That works, but it drags in a few things I did not want:</p>

The full kubectl</code> binary (about 50 MB stripped) for one API call.</li>
A kubeconfig / ServiceAccount plumbing that is broader than the one operation actually needs.</li>
Enough YAML around the pod spec to hide the actual behavior behind a template.</li>
</ul>
A purpose-built tool is a natural fit for Rust here: a single self-contained binary — no OpenSSL, no runtime dependency beyond glibc and the CA trust store — and a ServiceAccount that only needs deployments/scale: patch</code>. That is what k8s-scale-app-rs is.</p>
KEDA and Argo Workflows solve a related but different problem — reacting to events or orchestrating multi-step pipelines — not “flip a replica count or a restart annotation on a fixed schedule.” KEDA in particular has its own well-known scale-from-zero gap: a Prometheus-metric trigger can scale 1→N but not 0→1, because a Deployment at zero replicas emits no metric to react to (see the LLM inference series</a> for the concrete failure mode). None of that machinery applies here — a CronJob calling a purpose-built binary on a fixed schedule has nothing to react to.</p>
The same binary also covers restart. kubectl rollout restart deployment/foo</code> under the hood is one patch on spec.template.metadata.annotations["kubectl.kubernetes.io/restartedAt"]</code>. Two subcommands, same binary, same image.</p>
What it does🔗</a></h2>
The CLI is two subcommands sharing common arguments:</p>
k8s-scale-app-rs scale   --deployment <NAME> --replicas <N> [--dry-run] [--extra-ca-bundle <PATH>]</span></span>
k8s-scale-app-rs restart --deployment <NAME>                [--dry-run] [--extra-ca-bundle <PATH>]</span></span></code></pre>
Configuration is via environment variables, overridable by CLI flags:</p>
Flag</th> ENV</th> Subcommands</th></tr></thead>

--deployment</code></td> K8S_SCALE_DEPLOYMENT</code></td> both</td></tr>
--namespace</code></td> K8S_SCALE_NAMESPACE</code></td> both</td></tr>
--replicas</code></td> K8S_SCALE_REPLICAS</code></td> scale</td></tr>
--dry-run</code></td> K8S_SCALE_DRY_RUN</code></td> both</td></tr>
--extra-ca-bundle</code></td> K8S_SCALE_EXTRA_CA_BUNDLE</code></td> both</td></tr>
</tbody></table>
The --namespace</code> flag exists, but the CronJob does not hardcode it. Instead, the pod reads its own namespace from the Downward API and passes it through as an environment variable. That keeps the ServiceAccount’s Role safely namespace-scoped: the tool can only ever act on Deployments in the namespace where the CronJob itself runs. Not a general-purpose “scale anything anywhere” tool.</p>
Design highlights🔗</a></h2>
Minimal RBAC via the scale</code> subresource🔗</a></h3>
Setting replicas does not need patch</code> on the full Deployment. Kubernetes exposes deployments/scale</code> as a dedicated subresource:</p>
r</span>ules</span>:</span></span>
  -</span> a</span>piGroups</span>:</span> [</span>"</span>apps</span>"</span>]</span></span>
    r</span>esources</span>:</span> [</span>"</span>deployments/scale</span>"</span>]</span></span>
    v</span>erbs</span>:</span> [</span>"</span>get</span>"</span>,</span> "</span>patch</span>"</span>,</span> "</span>update</span>"</span>]</span></span></code></pre>
That is all the scale mode needs. Restart mode does need patch</code> on deployments</code> itself (to update the pod template annotation), so the shipped Role covers both:</p>
  -</span> a</span>piGroups</span>:</span> [</span>"</span>apps</span>"</span>]</span></span>
    r</span>esources</span>:</span> [</span>"</span>deployments</span>"</span>]</span></span>
    v</span>erbs</span>:</span> [</span>"</span>get</span>"</span>,</span> "</span>patch</span>"</span>]</span></span></code></pre>
patch</code> on the full Deployment is broader than patch</code> on deployments/scale</code> — RBAC review at deploy time should factor that in when the CronJob is configured for restart mode.</p>
Extra-CA bundle merged into the trust store🔗</a></h3>
The kube client uses the in-cluster CA from the ServiceAccount token secret automatically. For clusters whose API server certificate is signed by a corporate CA that is not in the SA-mounted ca.crt</code>, --extra-ca-bundle <path></code> reads a PEM file (or a full chain of them) and appends every CERTIFICATE</code> block to kube::Config.root_cert</code>. Non-certificate blocks in the file are filtered out.</p>
Rendered in Helm as an optional ConfigMap mount; in Kustomize as an opt-in Component. Neither path forces the mount when there is no corporate CA to add.</p>
The rustls 0.23 CryptoProvider gotcha🔗</a></h3>
If you build against kube-rs</code> with the rustls-tls</code> feature on the current release, the binary compiles cleanly — and then panics at the first TLS handshake with:</p>
Could not automatically determine the process-level CryptoProvider from Rustls crate features</span></span></code></pre>
rustls</code> 0.23 no longer picks a crypto backend based on downstream feature flags. The application itself must call rustls::crypto::ring::default_provider().install_default()</code> before any TLS work happens. In k8s-scale-app-rs this runs as the first step in main()</code>.</p>
Two notes for anyone hitting the same wall: the panic never fires at compile time, and no test caught it locally because integration tests without a cluster do not open a TLS connection. It only surfaces when the CronJob actually tries to reach the API server.</p>
Two deploy paths, independent🔗</a></h3>
Helm and Kustomize both ship in the repo, and either can be used on its own:</p>

Helm chart</strong> with values-{dev,preprod,prod}.yaml</code>, a mode: scale | restart</code> toggle that swaps the subcommand argument and drops the unused replicas env, and serviceAccount.create</code> / rbac.create</code> / extraCA.enabled</code> toggles for the pieces that a given cluster may or may not need.</li>
Kustomize</strong> with a base that has only the CronJob, plus three opt-in Components (serviceaccount/</code>, rbac/</code>, extra-ca/</code>) that overlays include as needed. Overlays under overlays/{dev,preprod,prod}/</code> set namespace and image tag and a patch that touches only the fields that vary per stage.</li>
</ul>
No Helm-inside-Kustomize glue, no Kustomize-on-Helm-render. Whichever tool matches an existing pipeline is the one to use.</p>
Two container images🔗</a></h2>
The default image and a -debug</code> variant, both built in the same GitHub Actions matrix — the
production/-debug</code> split itself is a general pattern, covered in more depth in
Part 2 of the K8s/OpenShift Best Practices series</a>:</p>
File</th> Base</th> Contents</th> Approx. size</th></tr></thead>

Containerfile</code></td> registry.access.redhat.com/ubi10/ubi-micro</code></td> Binary + CA trust store + /licenses/</code>, no package manager</td> ≈35 MB</td></tr>
Containerfile.debug</code></td> registry.access.redhat.com/ubi10/ubi-minimal</code></td> Everything above + bash</code>, curl</code>, bind-utils</code> (dig</code>)</td> ≈115 MB</td></tr>
</tbody></table>
ubi10-micro</code> is not fully distroless in the Google sense — bash and coreutils are still there — but it has no package manager and no network tools, which fits the pod’s actual operational surface for a scheduled scale or restart call. The -debug</code> variant exists for the day a pod loops in ImagePullBackOff</code> or a network policy silently drops the API-server traffic and someone needs to kubectl exec</code> in with tools to check.</p>
Why UBI10🔗</a></h3>
The base itself, not just the two variants built from it, was a deliberate choice. I went with
Red Hat’s UBI over an Alpine or a generic Docker Hub base image for one reason: it gives the
image a level of maintenance stability I don’t have to police myself — CVE scanning and rebuilds
are Red Hat’s job, not something I track on my own. That comes with a tradeoff worth stating
plainly: UBI is not “digitally sovereign” in the sense the upcoming Digital Sovereignty in
Practice series covers — it is a US vendor’s supply chain, the same as pulling from Docker Hub
or almost any other public registry would be. I did not find a base that solved that concern
without giving up the maintenance guarantees I wanted, so UBI10 here is a compromise I made
deliberately, not a claim that the underlying problem is solved.</p>
Both images ship an aggregated /licenses/LICENSES.txt</code> bundled with cargo-about</code> during the container build, generated from a whitelist of accepted SPDX identifiers. A new dependency that pulls in an unfamiliar license fails the container build on purpose.</p>
Supply chain🔗</a></h2>
The build-publish workflow</a> runs three jobs on every push, plus a release job on tag pushes:</p>

test</code></strong> — cargo fmt --check</code>, cargo clippy -D warnings</code>, cargo test --release</code>. Cluster tests auto-skip in CI (no KUBECONFIG</code>, no in-cluster SA token).</li>
build-image</code></strong> — matrix over Containerfile</code> and Containerfile.debug</code>. Each variant is built with buildx, pushed to ghcr.io/git001/k8s-scale-app-rs</code>, smoke-tested (--version</code>, scale --help</code>, restart --help</code>), then:

signed with cosign keyless</strong> via the GitHub OIDC token (no key management — Fulcio issues a short-lived certificate, the signature is logged to Rekor);</li>
has an SPDX-JSON SBOM</strong> generated with syft and attached via cosign attest --type spdxjson</code>;</li>
has SLSA build provenance</strong> pushed with actions/attest-build-provenance</code>.</li>
</ul>
</li>
publish-chart</code></strong> — helm lint</code> and helm package</code> on every push; OCI push to oci://ghcr.io/git001/charts/k8s-scale-app-rs</code>, plus cosign sign and SLSA provenance only on tag events (avoids overwrite conflicts on GHCR-immutable tags).</li>
release</code></strong> (tag events only) — creates the GitHub Release with auto-generated notes from commits since the previous tag, attaches the packaged chart .tgz</code> as an asset, and prepends the release body with pull and verify snippets.</li>
</ol>
All of that runs with permissions: contents:read, packages:write, id-token:write, attestations:write</code> — the minimum needed for OIDC-based signing plus attestation upload.</p>
Verifying a published image🔗</a></h2>
A consumer that wants to check what came out of that pipeline needs cosign v2:</p>
IMG</span>=</span>g</span>h</span>c</span>r</span>.</span>i</span>o</span>/</span>g</span>i</span>t</span>0</span>0</span>1</span>/</span>k</span>8</span>s</span>-</span>s</span>c</span>a</span>l</span>e</span>-</span>a</span>p</span>p</span>-</span>r</span>s</span>:</span>v</span>1</span>.</span>0</span>.</span>0</span></span>
IDENTITY</span>=</span>'</span>^https://github.com/git001/k8s-scale-app-rs/</span>'</span></span>
ISSUER</span>=</span>h</span>t</span>t</span>p</span>s</span>:</span>/</span>/</span>t</span>o</span>k</span>e</span>n</span>.</span>a</span>c</span>t</span>i</span>o</span>n</span>s</span>.</span>g</span>i</span>t</span>h</span>u</span>b</span>u</span>s</span>e</span>r</span>c</span>o</span>n</span>t</span>e</span>n</span>t</span>.</span>c</span>o</span>m</span></span>
</span>
cosign</span> verify</span> \</span></span>
  -</span>-certificate-identity-regexp</span> "</span>$</span>IDENTITY</span>"</span> \</span></span>
  -</span>-certificate-oidc-issuer</span> "</span>$</span>ISSUER</span>"</span> \</span></span>
  "</span>$</span>IMG</span>"</span></span>
</span>
cosign</span> verify-attestation</span> -</span>-type</span> spdxjson</span> \</span></span>
  -</span>-certificate-identity-regexp</span> "</span>$</span>IDENTITY</span>"</span> \</span></span>
  -</span>-certificate-oidc-issuer</span> "</span>$</span>ISSUER</span>"</span> \</span></span>
  "</span>$</span>IMG</span>"</span></span>
</span>
cosign</span> verify-attestation</span> -</span>-type</span> slsaprovenance</span> \</span></span>
  -</span>-certificate-identity-regexp</span> "</span>$</span>IDENTITY</span>"</span> \</span></span>
  -</span>-certificate-oidc-issuer</span> "</span>$</span>ISSUER</span>"</span> \</span></span>
  "</span>$</span>IMG</span>"</span></span></code></pre>
For enforcement inside the cluster, a cosign-aware admission controller — Kyverno</a>, Sigstore policy-controller</a>, or Connaisseur</a> — can turn the signature into a hard gate that rejects any pod trying to pull an image that was not produced by exactly this workflow. That is a separate deployment concern; the tool repo does not ship the policy itself.</p>
Mirroring the image into another registry🔗</a></h2>
Verifying a signature only works if the signature actually travels with the image. Not every docker pull && docker push</code>-style mirroring tool preserves it — some tools do, some quietly drop it, and one (oc-mirror v2</code>) solves a related but entirely different signature problem. I wrote up a full, sourced comparison — Which Tool Mirrors a Cosign-Signed Image into a Private Registry?</a> — with regctl</code> coming out as the most complete option for this specific image.</p>
Code and repository🔗</a></h2>

Repository: k8s-scale-app-rs on GitHub</a></li>
Container images: ghcr.io/git001/k8s-scale-app-rs:v1.0.0</code> and ghcr.io/git001/k8s-scale-app-rs:v1.0.0-debug</code></li>
Helm chart: oci://ghcr.io/git001/charts/k8s-scale-app-rs:1.0.0</code></li>
</ul>
Feedback and PRs welcome.</p>


Which Tool Mirrors a Cosign-Signed Image into a Private Registry?
2026-07-06T00:00:00+00:00
TL;DR🔗</a></h2>
regctl</code> is the most complete option — it exposes the legacy tag-based signature scheme and the
modern OCI 1.1 referrers API as two separate, explicit flags. oras cp -r</code> is the second choice,
and the tool cosign’s own project points to now that cosign copy</code> is deprecated. oc-mirror v2</code>
looks like it should be on this list but actually solves a different, unrelated signature problem.</p>
The problem🔗</a></h2>
Verifying a signature only works if the signature actually travels with the image. Anyone mirroring
a Cosign-signed image into a private or air-gapped registry needs the copy step itself to carry the
signature along, not just the layers — and that is not automatic. Some tools drop it silently, some
need a config flag turned on first, and one widely-used tool solves a related but entirely different
problem. k8s-scale-app-rs</a> is the worked example
throughout this post — its own container images are signed keylessly with cosign, carry an SBOM and
SLSA build provenance, and its “Verifying a published image”</a>
section shows what verification actually checks. This post is about what happens before</em>
verification: getting the signature into the registry the verifier will actually query.</p>
A short, sourced comparison, checked directly against each project’s docs/source (as of July 2026):</p>
A naming trap worth knowing first🔗</a></h2>
Red Hat’s oc-mirror v2</code> — the tool for mirroring into disconnected OpenShift installs — has its
own --secure-policy</code>/--remove-signatures</code>/--registries.d</code> flags, but they implement Red Hat’s
older “simple signing” scheme: a policy.json</code> plus GPG keys plus an external sigstore:</code> URL (e.g.
mirror.openshift.com/pub/openshift-v4/signatures</code> for OpenShift release images). That predates,
and has nothing to do with, the CNCF Sigstore project this post’s cosign workflow uses — same word,
unrelated mechanism. oc-mirror v2</code> went GA in OpenShift 4.18 (release
notes</a>),
but its ImageSetConfiguration</code> API is still v2alpha1</code>, and none of Red Hat’s own walkthroughs for
it touch Cosign-style signatures at all.</p>
Tool comparison🔗</a></h2>
Tool</th> Legacy tag-based signature (sha256-<digest>.sig</code>)</th> OCI 1.1 referrers (modern Cosign/SBOM/attestations)</th> Note</th></tr></thead>

regctl image copy</code></a></td> --digest-tags</code></td> --referrers</code></td> only tool here with separate, explicit flags for both schemes</td></tr>
oras cp -r</code></a></td> via -r</code></td> -r</code> (marked “Preview”)</td> --from/to-distribution-spec</code> handles referrers-tag vs. referrers-API mismatches between registries</td></tr>
skopeo copy</code></td> opt-in</td> not supported</td> needs use-sigstore-attachments: true</code> under the default-docker</code> key in registries.d</code>, on both source and destination</td></tr>
Zot registry sync</code></td> syncLegacyCosignTags</code> (default true</code>)</td> only with preserveDigest: true</code></td> without preserveDigest</code>, Zot re-encodes Docker-format images to OCI on sync, which changes the digest and detaches the signature</td></tr>
cosign copy</code></td> yes</td> no</td> deprecated</strong> as of sigstore/cosign#4681</a> (merged 2026-02-04) — the tool itself now points to oras copy -r</code> instead</td></tr>
crane copy</code></td> only incidentally, via --all-tags</code></td> no</td> plain manifest/layer copier, no signature awareness at all</td></tr>
Harbor replication</td> per Harbor’s own docs, yes</td> open gap (goharbor/harbor#23210</a>)</td> works for the legacy scheme; OCI 1.1 referrers replication is not yet reliable</td></tr>
</tbody></table>
regctl</code> is the only tool in this comparison that exposes both signature schemes as distinct,
intentional flags rather than as a side effect of copying “everything.” For a registry pair that
already speaks the OCI 1.1 referrers API end to end, oras cp -r</code> is the other option worth
checking — it’s what the cosign project’s own deprecation notice for cosign copy</code> points to.</p>
Example: mirroring with regctl🔗</a></h2>
Here is an example command to mirror k8s-scale-app-rs</code> itself, signature included, using regctl</code>:</p>
regctl</span> image</span> copy</span> \</span></span>
  -</span>-digest-tags</span> -</span>-referrers</span> \</span></span>
  ghcr.io/git001/k8s-scale-app-rs:v1.0.0</span> \</span></span>
  my-private-registry.example.com/k8s-scale-app-rs:v1.0.0</span></span></code></pre>Sources🔗</a></h2>

sigstore/cosign PR #4681 — “Deprecate cosign copy”</a></li>
sigstore/cosign#4335 — Complete OCI 1.1 Referrers API Support Across All Cosign Commands</a></li>
sigstore/cosign#4564 — cosign verify fails after cosign copy (JFrog Artifactory)</a></li>
podman-container-tools/skopeo#2061 — sigstore signature copying and use-sigstore-attachments</code></a></li>
regctl image copy</code> reference</a></li>
oras cp</code> command reference</a></li>
goharbor/harbor#23210 — OCI 1.1 referrers not replicated</a></li>
Zot registry: mirroring/sync documentation</a></li>
OpenShift Container Platform 4.18 release notes</a></li>
openshift/oc-mirror — signature-verification.md</a></li>
</ul>


K8s & OpenShift: Compliance
2026-07-01T00:00:00+00:00
Part 6</a> covered the operational loop:
GitOps, observability, cost control, and upgrades. This final part maps the cluster configuration
covered throughout this series to the regulatory frameworks that require it — NIS2, DORA,
PCI-DSS, HIPAA, and the Cyber Resilience Act (CRA) — and covers the two topics that compliance
work adds on top of security: audit logging as evidence and log retention as a contractual
obligation.</p>


K8s & OpenShift: Security
2026-07-01T00:00:00+00:00
Part 4</a> covered scaling and resilience.
This part covers security — not as a checklist to complete before an audit, but as a set of
controls that reduce real attack surface and limit the blast radius when something goes wrong.</p>


What is Application Security
2026-06-20T00:00:00+00:00
The third part of the (D)DoS series — but a step sideways: this post covers attacks at the Application layer that affect confidentiality and integrity</strong> rather than availability. SQL Injection, Log4Shell, and similar vulnerabilities have a different threat model than the DDoS attacks covered in the technical part</a>.</p>


What is a (D)DoS - technical
2026-06-20T00:00:00+00:00
The technical follow-up to the non-technical (D)DoS overview</a>. Covers Layer 3/4 network floods (SYN, UDP, amplification), BGP hijacking, Layer 7 application DDoS, and operational resilience — all focused on availability.</p>
Originally published at opensourcerers.org</a>; updated with current attack vectors and technologies.</p>


What is a (D)DoS
2026-06-20T00:00:00+00:00
(D)DoS attacks are not just a technical problem — they operate at the Business, Social, and Informational level as well. This post covers the non-technical dimensions; the technical follow-up</a> covers Layer 3/4 network floods, BGP hijacking, TLS handshake attacks, Layer 7 application DDoS, and operational resilience.</p>
Originally published at opensourcerers.org</a>; updated with current examples and expanded framing.</p>


(D)DoS and Application Security: The Complete Guide
2026-06-19T00:00:00+00:00
This is the index and reading guide for a three-part series on denial-of-service and application
security. The first two parts cover availability</strong> attacks — a service being made unreachable or
unusable — at levels most people don’t associate with the term “DDoS”: the business level (losing
the people who run the service), the social level (manipulating the humans behind it), the
informational level (reputational disruption), and finally the technical level most readers expect
(network floods, BGP hijacking, Layer 7 exhaustion). The third part is a deliberate step sideways,
into application-layer attacks — SQL Injection, Log4Shell, the OWASP Top 10 — that threaten
confidentiality and integrity</strong> instead of availability.</p>


Elasticsearch vs. OpenSearch vs. Loki vs. Quickwit vs. ClickHouse: Security & Compliance
2026-05-14T00:00:00+00:00
Access control, encryption, and immutability requirements often determine whether a log
archive can be used for compliance purposes — and the five systems differ substantially in
what they enforce natively versus what must be delegated to infrastructure.</p>
This is Part 3 of a five-part series.</p>

Full guide:</strong> Elasticsearch vs. OpenSearch vs. Loki vs. Quickwit vs. ClickHouse: The Complete Guide</a></li>
Part 1 — Comparison:</a> Storage tiering, compression, resource consumption, query languages, SaaS options</li>
Part 2 — Operations:</a> Setup, ingest pipeline, ECS vs. OTel, backup & DR, observability, alerting</li>
Part 3 — Security & Compliance — this post:</strong> Encryption, RBAC, WORM / S3 Object Lock</li>
Part 4 — UX, Dashboards & Alerts:</a> UI layers, log search UX, cold-tier query behaviour, dashboard building, sharing, alerting</li>
Part 5 — Use Case:</a> Vector, Istio/Envoy, nginx, Java on OVH MKS — complete ClickHouse ingestion setup and monthly awffull report</li>
</ul>

Which Tool Mirrors a Cosign-Signed Image into a Private Registry?

K8s & OpenShift: Compliance

K8s & OpenShift: Security

What is Application Security

What is a (D)DoS - technical

What is a (D)DoS

(D)DoS and Application Security: The Complete Guide

Elasticsearch vs. OpenSearch vs. Loki vs. Quickwit vs. ClickHouse: Security & Compliance

Alek's Blog - security

Sovereign-Cloud-Washing: Five Questions

Who Has Access? Humans, Accounts, AI Agents

Legally vs. Technically Enforced

Can You Leave? Data Portability & Egress

Digital Sovereignty: The Complete Guide

What Does It Cost to Leave — or Arrive?

Who Builds the Platform? Ownership vs. Stack

k8s-scale-app-rs: Scale or Restart a Kubernetes Deployment from a CronJob