Make argoexec image scratch/distroless to improve security

[Sh1ftry]

Summary

Argoexec image has lots of components, which makes it vulnerable to various security findings. With emissary executor though it's possible to make the image distroless.

Use Cases

Workflows using emissary executor.

• Remove the deprecated docker executor #7795
• Replace use of curl binary in the HTTP artifact driver with pure Go #7796
• Replace use of kubectl with pure Go in the resource template code #7797
• Replace use of git binary in Git artifact driver #7798
• Replace jq binary with pure Go #7799
• Replace use of tar binary with pure Go in the Kubernetes API executor #7800

---

Message from the maintainers:

Love this enhancement proposal? Give it a 👍. We prioritise the proposals with the most 👍.

[alexec]

We already move to a more secure base image (alpine), but it'd be awesome to go further.

This work would need to be done piecemeal, as we'd probably want to add tests each step of the way:

• Remove the deprecated Docker executor
• Replace use of curl binary in the HTTP artifact driver with pure Go
• Replace use of kubectl with pure Go in the resource template code
• Replace use of git binary in Git artifact driver (does Golang Git client support submodules)
• Replace the jq with pure Go
• Replace use of the tar with pure Go in the Kubernetes API executor

The above list is in rough order of (cost+risk)/benefit. E.g. removing the Docker executer would easy and drastically improve our posture, where as removing kubectl would require more code changes. Replacing jq would mean we'd need to find a good pure Go replacement.

[alexec]

@Sh1ftry would you be interested in helping?

[NikeNano]

For the work related to replacing kubectl do we aim for using the dynamic k8s client? Have looked around and it don't seem like there is any libs that handle this smoothly so it might be quite a lot of code that needs to be brought in to argo to handle this. I will continue to research it to see what I can find.

[alexec]

Correct. I think we can use dynamic.New.

[NikeNano]

As I see the downside atm is that it will be hard to be backwards compatible since the dynamic API don't have the same functionality out of the box as kubectl. Specifically there is not direct mapping towards apply, but might be in the not to distant future hopefully since k8s now supported apply server side, https://pkg.go.dev/k8s.io/client-go/dynamic#NewForConfig. I guess we could implement checks to see if resource exists and then do and patch similar to kubectl. Do you have some thoughts on this @alexec ?

[alexec]

kubectl is written in Golang. Argo CD uses it like that:

https://github.com/argoproj/argo-cd/blob/master/go.mod#L87

We can do that. Should we discus this is the right issue? #7797

[NikeNano]

We can do that. Should we discus this is the right issue? #7797

yes, my bad!

[alexec]

I've thought about this and I think there is a third-way that might be easier. Instead of replacing the binaries with pure Go, we actually just want to get rid of the operating system. We can do this by copying just the binaries accross. Assmuming all the biniaries work without the underying OS.