ci: generate seccomp profile within pipeline

[alegrey91]

This PR introduces the ability of generating seccomp profiles within the pipeline.
This will be helpful in case some user wants to secure his capsule installation by leveraging the power of seccomp.

To do so, capsule container image is built replacing the base image with the one provided by harpoon. This will allow the execution of capsule through harpoon.
Then, set up a Kubernetes cluster using kind with a shared folder that is used to retrieve the metadata generated by harpoon during the e2e tests execution.
Capsule image is consequently installed on the cluster with a customized values file from helm, and the e2e could start.
Once finished, the results are merged with the tracing of the unit tests (handled by harpoon).
This generates the seccomp profile tailored for capsule, which is going to be uploaded with the other artifacts in the upcoming releases.

[netlify]

✅ Deploy Preview for capsule-documentation canceled.

Name	Link
🔨 Latest commit	fb9be0d
🔍 Latest deploy log	https://app.netlify.com/sites/capsule-documentation/deploys/679bdcb1fa87210008218b5b

[oliverbaehler]

Hey @alegrey91 great tool, hope we can get you gain some traction as example. I have requested changes regarding the chart

[oliverbaehler]

Not a big fan of this, we should try to install binaries into the project's bin/ folder, i am assuming this is going to install harpoon at system level. Since it,s go, can't we make a target like the other binary dependencies:

HARPOON = $(shell pwd)/bin/harpoon
HARPOON_VERSION = v0.9.4
harpoon:
	$(call go-install-tool,$(HARPOON),github.com/alegrey91/harpoon@$(HARPOON_VERSION))

[alegrey91]

Hi @oliverbaehler, unfortunately I don't think we can currently use go install with harpoon.
The project has a complex toolchain that requires a separated compilation of the ebpf object.
About the installation directory, I think this is fine, I can set the location through the install script.

[oliverbaehler]

Just use securityContext ? Or what's the reason here

[alegrey91]

.Values.securityContext is used by kubelet image.
.Values.manager.securityContext is used only by the capsule image when built for tracing.
When we don't set .Values.manager.securityContext, then .Values.securityContext come into play for both the images.
Does it make sense to you?

[oliverbaehler]

Which kubelet image? We just have the manager that we are deploying..

ARe you talking about this here:

trace-install: trace-load-image
	helm upgrade \
	    --dependency-update \
		--debug \
		--install \
		--namespace capsule-system \
		--create-namespace \
		--set 'manager.image.pullPolicy=Never' \
		--set 'manager.image.registry=localhost' \
		--set 'manager.image.repository=capsule-tracing' \
		--set 'manager.resources=null'\
		--set "manager.image.tag=latest" \
		--set "manager.image.securityContext.privileged=true" \
		--set 'manager.livenessProbe.failureThreshold=10' \
		--set 'manager.readinessProbe.failureThreshold=10' \
		--values charts/capsule/values-tracing.yaml \
		capsule \
		./charts/capsule

This specifcally manager.image.securityContext.privileged=true (This path is wrong btw)? So the rest of the securitycontext is too restrictive? Otherwise make sure it points to the same values in the Makefile as in the chart values

[alegrey91]

Sorry, I meant the kubectl image which is mentioned in the values.yaml.
The point is that .Values.securityContext is shared between the capsule Deployment and the kubectl Job, so in order to be able to overwrite only the capsule Deployment I created a dedicated item for it.

[oliverbaehler]

Jobs take sec from .Vales.global.jobs.kubectl.securityContext, they are no longer shared

[oliverbaehler]

Which kubelet image? We just have the manager that we are deploying..

ARe you talking about this here:

trace-install: trace-load-image
	helm upgrade \
	    --dependency-update \
		--debug \
		--install \
		--namespace capsule-system \
		--create-namespace \
		--set 'manager.image.pullPolicy=Never' \
		--set 'manager.image.registry=localhost' \
		--set 'manager.image.repository=capsule-tracing' \
		--set 'manager.resources=null'\
		--set "manager.image.tag=latest" \
		--set "manager.image.securityContext.privileged=true" \
		--set 'manager.livenessProbe.failureThreshold=10' \
		--set 'manager.readinessProbe.failureThreshold=10' \
		--values charts/capsule/values-tracing.yaml \
		capsule \
		./charts/capsule

This specifcally manager.image.securityContext.privileged=true (This path is wrong btw)? So the rest of the securitycontext is too restrictive? Otherwise make sure it points to the same values in the Makefile as in the chart values

[alegrey91]

Hello @oliverbaehler, I'm having a problem with the Test charts pipeline.
It's failing due to my values file ci/tracing-values.yaml because this specific configuration needs kind to be configured with an extraMount (see hack/kind-cluster.yml). Without this cluster config, the chart is unable to mount the volumes specified within the values file.
What can we do to fix it?