Restrict access to K8s secret token

[mjura]

The most of the containerized workloads do not need to interact with the Kubernetes API server and
they don't need to read the token that is associated with the ServiceAccount used to create the Pod.

This path can be blocked /var/run/secrets/kubernetes.io

[flavio]

@mjura do we really need to add the whole lockc.toml to the helm chart too? I think the container image should come with the default lockc configuration we create.

It's fine to allow the user to overload the configuration via helm, but I wouldn't use that a a mechanism to get our default config into kubernetes.

[vadorovsky]

You need to add this dir to lockc/src/settings.rs as well. These are default values used in case there is no configuration found.

[vadorovsky]

@flavio I actually like the idea of adding the whole config to the helm chart. It gives people a reference and lets them adjust the configuration by editing it.

What worries me a bit is that we have multiple files where we need to put new configuration options, which starts becoming quite a hassle. I have no clear idea how to solve that yet, but it would be nice to have some one file for defining options and then generate all the others (.rs, /etc and configmap) based on it. Of course I wouldn't do that in this PR, rather as an follow up issue.

[vadorovsky]

Also, there is a typo in the commit message and PR name - s/secter/secret/

[flavio]

What worries me a bit is that we have multiple files where we need to put new configuration options, which starts becoming quite a hassle.

That's exactly my main concern. Just to reiterate over what I've already said, I would leave the default configuration inside of the lockc repo on GitHub, have that tagged and automatically added to the container image at build time.

As for the users, we can address your concern ("how do they find a sample of the configuration file?") by adding a simple comment inside of the helm chart. The comment can point to the configuration file on the GitHub repo

[mjura]

I have updated also baseline restricted paths

[vadorovsky]

I'm fine with accepting this PR as it is now. I would address the idea of having a config in one place as a separate, follow up change. I hope it's fine for you @flavio

[vadorovsky]

Linter is complaining, but it's not related to changes in this PR, let me fix it with a new PR and let's keep this one on hold.

[vadorovsky]

@flavio we are going to remove a duplicated config from helm chart (and instead use the .toml file from the container image) as a follow up change.