[bug] ArgoCD integration example in README is incorrect (v4.4.0 image no longer contains /bin/sh)

[motoki317]

Bug description

In README.md, we have the following patch example:
https://github.com/viaduct-ai/kustomize-sops?tab=readme-ov-file#ksops-repo-sever-patch
(btw, this patch itself seems to be a bit outdated as well, see #291)

# argo-cd-repo-server-ksops-patch.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: argocd-repo-server
spec:
  template:
    spec:
      # 1. Define an emptyDir volume which will hold the custom binaries
      volumes:
        - name: custom-tools
          emptyDir: {}
      # 2. Use an init container to download/copy custom binaries into the emptyDir
      initContainers:
        - name: install-ksops
          image: viaductoss/ksops:v4.4.0
          command: ["/bin/sh", "-c"]
          args:
            - echo "Installing KSOPS...";
              mv ksops /custom-tools/;
              mv kustomize /custom-tools/;
              echo "Done.";
          volumeMounts:
            - mountPath: /custom-tools
              name: custom-tools
      # 3. Volume mount the custom binary to the bin directory (overriding the existing version)
      containers:
        - name: argocd-repo-server
          volumeMounts:
            - mountPath: /usr/local/bin/kustomize
              name: custom-tools
              subPath: kustomize
            - mountPath: /usr/local/bin/ksops
              name: custom-tools
              subPath: ksops
        ## If you use AWS or GCP KMS, don't forget to include the necessary credentials to decrypt the secrets!
        # env:
        #  - name: AWS_ACCESS_KEY_ID
        #    valueFrom:
        #      secretKeyRef:
        #        name: argocd-aws-credentials
        #        key: accesskey
        #  - name: AWS_SECRET_ACCESS_KEY
        #    valueFrom:
        #      secretKeyRef:
        #        name: argocd-aws-credentials
        #        key: secretkey

However, starting from v4.4.0, this patch no longer works since the viaductoss/ksops:v4.4.0 image no longer contains /bin/sh nor cp binaries, because it builds from distroless:latest image.
We get this error in k8s: failed to create containerd task: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: exec: "/bin/sh": stat /bin/sh: no such file or directory

(This is expected, since distroless:latest doesn't have shell binaries. If you want one, you are expected to use the :debug tag.)

Proposed solution?

Either include /bin/sh and cp binaries to the image, or rewrite the example to use other containers with sh and cp binaries.

An example of a new patch (replaced initContainers in step 2 and removed kustomize volume mount in step 3):

# argo-cd-repo-server-ksops-patch.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: argocd-repo-server
spec:
  template:
    spec:
      # 1. Define an emptyDir volume which will hold the custom binaries
      volumes:
        - name: custom-tools
          emptyDir: {}
      # 2. Use an init container to download/copy custom binaries into the emptyDir
      initContainers:
        - name: install-ksops
          image: alpine:latest
          command: ["/bin/sh", "-c"]
          args:
            - |
              set -eux
              apk add --no-cache ca-certificates curl tar
              case "$(uname -m)" in
                x86_64|amd64) ARCH="x86_64" ;;
                aarch64|arm64) ARCH="arm64" ;;
                *) echo "unsupported arch: $(uname -m)"; exit 1 ;;
              esac
              VERSION="v4.4.0"
              VERSION_RAW="${VERSION#v}"
              URL="https://github.com/viaduct-ai/kustomize-sops/releases/download/${VERSION}/ksops_${VERSION_RAW}_Linux_${ARCH}.tar.gz"
              curl -fsSL -o ksops.tar.gz "${URL}"
              tar -C /custom-tools -xzf ksops.tar.gz ksops
              chmod +x /custom-tools/ksops
          volumeMounts:
            - mountPath: /custom-tools
              name: custom-tools
      # 3. Volume mount the custom binary to the bin directory
      containers:
        - name: argocd-repo-server
          volumeMounts:
            - mountPath: /usr/local/bin/ksops
              name: custom-tools
              subPath: ksops
        ## If you use AWS or GCP KMS, don't forget to include the necessary credentials to decrypt the secrets!
        # env:
        #  - name: AWS_ACCESS_KEY_ID
        #    valueFrom:
        #      secretKeyRef:
        #        name: argocd-aws-credentials
        #        key: accesskey
        #  - name: AWS_SECRET_ACCESS_KEY
        #    valueFrom:
        #      secretKeyRef:
        #        name: argocd-aws-credentials
        #        key: secretkey

[cguertin14]

Thank you for this writeup!
To the maintainers: this is a breaking change and should have been a major version bump when released. It also breaks existing repo-server argocd deployments.

[devstein]

Hey @cguertin14 @motoki317 apologies for this breaking change. I missed this integration when the contributor optimized the Dockerfile.

I'll try cut a new release as soon as I can and update the README (PRs are welcome!)

[albundy83]

Hello,
moving to distroless now may introduce another problem in the future.

At for moment, gcr.io/distroless/base is also know as gcr.io/distroless/base-debian12 (bookworm) under the hood.

On the other hand, golang 1.24.6 and argocd 3.1.5 have already migrated to debian 13 (trixie).

Unfortunately, distroless images based on debian 13 are not ready yet.
You can check here.

[albundy83]

Here is a small pull request to fix the missing commands.

I have visually indicated that final images are based on debian 12 as a reminder to check from time to time if distroless debian 13 images are ready.

[albundy83]

Also, adding git like it has been done here won't work.
git is broken at the moment as it requires lots of libraries and binaries.

Do you still need it ?

[james-callahan]

Silly but useful idea: could the ksops binary include a little cp utility as a subcommand?
That way we don't need a cp binary.
The source could be hard-coded as /proc/self/exe and you just provider a destination to install to?

[jlaska]

Any updates on this? Are folks successfully working around this in the initContainer? Is the intention to change the Dockerfile as proposed in #303

[kholisrag]

leaving my trace in here, since this is blocking us to update to version 4.4.0 too

Update:

I end up building my own container images because of this bug in here