kube-vip-cloud-provider: specify unprivileged securityContext

[rptaylor]

Further to #46 , specify additional securityContext fields that allow kvcp to run fully unprivileged. This is required to run on clusters that enforce Pod Security Standards.

The Dockerfile shows that kvcp is intended to run as the "nonroot" user, but there is no UID specified:
https://github.com/kube-vip/kube-vip-cloud-provider/blob/main/Dockerfile#L24
In this case I think kubernetes may leave it up to the container runtime to figure out what UID to use. I'm not sure what the actual behaviour would be, but in any case it is better to be explicit.
I checked the container image:

podman pull kubevip/kube-vip-cloud-provider:v0.0.10
podman unshare
podman image mount 0ed6a7c8d466
# cat ~/.local/share/containers/storage/overlay/f748292c6e9da40ad983d11baa5eead146e5ed92ca8bdf7e778e00e1924651ff/merged/etc/passwd
root:x:0:0:root:/root:/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/sbin/nologin
nonroot:x:65532:65532:nonroot:/home/nonroot:/sbin/nologin
# cat ~/.local/share/containers/storage/overlay/f748292c6e9da40ad983d11baa5eead146e5ed92ca8bdf7e778e00e1924651ff/merged/etc/group
root:x:0:
nobody:x:65534:
tty:x:5:
staff:x:50:
nonroot:x:65532:

This confirms that the intended UID and GID of the "nonroot" account that kvcp should run as are 65532.

This also removes capabilities, which AFAICT kvcp does not need. It would have only had ones provided by default by whichever container runtime is used. Again this would result in inconsistent behaviour depending on implementation/deployment details and it is preferable to be explicit instead.

[rptaylor]

It is working in my tests. @thebsdbox can you please have a look and tag again? Thanks so much!

[rptaylor]

@thebsdbox sorry to bother but any feedback/review on this? Or anyone other maintainers who can review? Thanks!