feat: Use RuntimeDefault Seccomp profile by default

[brookelew]

Description

Default to using RuntimeDefault seccomp profile for all pods.

Rationale

Resolves #155

Checklist

• This PR contains a description of the changes I'm making
• I read the CONTRIBUTING.md guide
• I updated the version in Chart.yaml if feasible according to Semantic versioning
• I updated the changelog with an artifacthub.io/changes annotation in Chart.yaml
• I update the changelog in CHANGELOG.md
• I updated applicable README.md files using helm-docs
• By contributing this change, I certify I have signed-off on the
  DCO ownership statement
  and this change did not use post-BUSL-licensed code from HashiCorp.
  Existing MPL-licensed code is still allowed, subject to attribution.
  Code authored by yourself and submitted to HashiCorp for inclusion is
  also allowed.

[brookelew]

@geo-schloesser While working on this pull request I noticed that the chart version for #153 was 0.26.0 but the change in CHANGELOG.md was filed under 0.25.8, was this intentional?

[brookelew]

I avoided adding RuntimeDefault to one container in the CSI daemonset because it seems that the CSI does not define a default pod securityContext and a container securityContext for that container (openbao-csi-provider), but does define a container securityContext for the agent container which is not overridable by the user. Should I go ahead and add that in? I'm not sure if the CSI daemonset has different requirements.

[geo-schloesser]

@geo-schloesser While working on this pull request I noticed that the chart version for #153 was 0.26.0 but the change in CHANGELOG.md was filed under 0.25.8, was this intentional?

No, that was not intentional. Initially 0.25.8 was used and then changed to 0.26.0. Seems like I forgot to set the correct version the changelog

[eyenx]

@geo-schloesser While working on this pull request I noticed that the chart version for #153 was 0.26.0 but the change in CHANGELOG.md was filed under 0.25.8, was this intentional?

No, that was not intentional. Initially 0.25.8 was used and then changed to 0.26.0. Seems like I forgot to set the correct version the changelog

Sorry I did not catch that in my Review.

[eyenx]

Hi @brookelew thanks for your PR

[eyenx]

I avoided added RuntimeDefault to one container in the CSI daemonset because it seems that the CSI does not define a default pod securityContext and a container securityContext for that container (openbao-csi-provider), but does define a container securityContext for the agent container which is not overridable by the user. Should I go ahead and add that in? I'm not sure if the CSI daemonset has different requirements.

There shouldn't be any special requirements for the daemonset, You can add it in. We will check if it still works as intended.

[brookelew]

PR should be ready, the big uncertainties here are dropping all capabilities for the CSI containers, and running the CSI provider container as non-root, but that should be caught by the CI tests if they don't work.

[eyenx]

@brookelew sadly the csi-provider seems not being able to spin up -

2026-03-26T06:46:59.279Z [INFO]  Creating new gRPC server
2026-03-26T06:46:59.280Z [INFO]  Opening unix socket: endpoint=/provider/openbao.sock
2026-03-26T06:46:59.280Z [ERROR] Error running provider: err="failed to listen on unix socket at /provider/openbao.sock: listen unix /provider/openbao.sock: bind: permission denied"

Seems like the permissions are too tight for the csi-provider.

[brookelew]

@brookelew sadly the csi-provider seems not being able to spin up -

2026-03-26T06:46:59.279Z [INFO]  Creating new gRPC server
2026-03-26T06:46:59.280Z [INFO]  Opening unix socket: endpoint=/provider/openbao.sock
2026-03-26T06:46:59.280Z [ERROR] Error running provider: err="failed to listen on unix socket at /provider/openbao.sock: listen unix /provider/openbao.sock: bind: permission denied"

Seems like the permissions are too tight for the csi-provider.

Yep I just got the CI notification, I'll fix it around Tuesday after I finish some uni assignments.