PII Shield 2.2.5 - Helm Chart for a Scratch Logging Sidecar

pii-shield published tag pii-shield-2.2.5 on 27 September 2026. The release body is one sentence: a Helm chart for deploying PII Shield as a scratch compatible logging sidecar, which is the only claim the notes make. Release metadata sets prerelease to false, so this tag is a final release.

The full release notes and downloads are on the GitHub release page.

The release body is a chart description ¶

The GitHub release page has no Added, Fixed, or Changed headings. It cites no pull request, no commit, and no image digest. The sentence matches a chart description copied into the release body.

That limits what an operator can conclude. A chart version bump can change templates, defaults, the image, RBAC, or only the version string in Chart.yaml. The note shows none of those diffs. The git tag and the release name are the same string, pii-shield-2.2.5. The note never prints a chart version or an appVersion next to that string.

If this chart is already installed, the page is not evidence that the cluster will behave differently after an upgrade. Template the chart with the values file you run in production. Diff the rendered pod against the live sidecar. An empty note is an empty changelog. It is not a promise that the manifests stayed the same.

The sentence calls the artifact a Helm chart. It does not point at a raw manifest or a standalone binary archive. Clusters that copy YAML, or that build the container themselves, get no second procedure in this tag.

Every install argument is missing too. There is no chart repository URL. There is no helm install release name. There is no values key. Those identifiers are absent from the release body, so this post does not supply them.

The metadata does record two GitHub locations, and the owners differ. The repository field is aragossa/pii-shield. The tag is published under pii-shield/pii-shield. The notes do not say whether that split is a rename, a redirect, or two remotes of one history. A pipeline that clones one owner and fetches assets from the other should resolve tag pii-shield-2.2.5 on the remote it builds from. A missing tag is a failed fetch.

Scratch is an empty image. A process described as scratch compatible does not need /bin/sh, a package database, or the directory layout of a general purpose distro. The note attaches that constraint to a logging sidecar: a second container in the pod whose job is log bytes.

Pod logs are an input to anything downstream that stores them. A node agent, an object store, and a warehouse table each keep a copy of the bytes that leave the pod. The sidecar is the last component that still shares the pod network namespace with the writer. It usually shares a volume when it reads files the app container wrote. The note does not say which tap this chart uses. A file tail, an stdout wrap, and a socket listen all fit the words “logging sidecar”. This release does not choose among them.

Compatible is also a weaker claim than a FROM scratch line in a Dockerfile. A static binary can run on an empty root filesystem and still ship on a base that carries certificates or a passwd file. The note does not name the base image, the numeric user, or whether the root filesystem is mounted read only. Those fields belong to the rendered container spec. Read them there.

An empty root filesystem changes how you debug. When /bin/sh is absent, kubectl exec cannot open a shell in that container. Diagnosis falls back to the process logs, or to an ephemeral container the runtime adds beside the sidecar. The note mentions no debug image and no shell flag.

Fewer packages in the sidecar means a smaller image and a shorter package list for that container alone. The application container is unchanged. The note publishes no CPU or memory figure, so the scratch claim says nothing about cost per log line.

No CVE id appears. No environment variable is renamed. No flag is removed. No migration step is written. Treating pii-shield-2.2.5 as a security advisory, or as a breaking bump, adds statements the release does not contain.

No upgrade procedure is written. The remaining check is mechanical. Fetch the chart this tag is supposed to represent. Template it with the values you run in production. Read the sidecar container: image reference, command, args, volume mounts, and security context. Diff that spec against the install already in the cluster. Matching specs mean the git tag moved and the pod did not. A difference is the change list the GitHub body left out.