Support re-using LAPI credentials in Agent and AppSec

[krezovic]

Check beforehand if tmp dir contains the config file and try to re-use it

Fixes: #252

/kind enhancement
/area configuration

[SISheogorath]

While I do enjoy that you tackle the "Let's install packages on container startup" problem, I'm not sure the "let's allow the Pod to patch all Pods in the same namespace" is a good trade.

The solution of using an encrypted annotation to store the secret, seems overly complex to me.

Other approaches:

• Use a named secret, that you can patch to store the secret, this prevents a compromised crowdsec Pod from pivoting to other Pods. (If you want to avoid being unable to start your pod, you can create the secret empty and patch the key/value in later.)
• Use a helm hook to create and re-validate the api-key.
• Use a cronjob to re-validate the api-key.

[krezovic]

While I do enjoy that you tackle the "Let's install packages on container startup" problem, I'm not sure the "let's allow the Pod to patch all Pods in the same namespace" is a good trade.

The solution of using an encrypted annotation to store the secret, seems overly complex to me.

Other approaches:

• Use a named secret, that you can patch to store the secret, this prevents a compromised crowdsec Pod from pivoting to other Pods. (If you want to avoid being unable to start your pod, you can create the secret empty and patch the key/value in later.)
• Use a helm hook to create and re-validate the api-key.
• Use a cronjob to re-validate the api-key.

Hello @SISheogorath. Thank you for your feedback.

I have considered using any additional resource but gave up on it due to the following:

• We do not know the machine (POD) names beforehand, and they will change on every deploy. We would have to clear the secret somehow on every new deploy. Helm Hook may work.
• There may be any number of PODs, dependent on the number of nodes for daemonsets, and number of desired replicas for deployments. Handling concurrent modification of a single resource from many instances on startup is no easy task. Additionally, in a niche scenario, there may be so many instances (improbable, but possible) where the secret will end up storing more than 1 MB of data, which is the default etcd limit.

I did some investigation to address your concern of a compromised POD and the solution may be to use projected volume for a service account only on init container, with minimal expiration time. That way, whole POD won't get the privileges to patch anything, but init container will, and those permissions will be revoked once init container is finished.

https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#serviceaccount-token-volume-projection

[SISheogorath]

If you want to store the token only for the lifetime of a Pod, it would be easier to use a (memory-backed) emptyDir to store the token.

https://kubernetes.io/docs/concepts/storage/volumes/#emptydir-memory-configuration-example

Why all the complications with annotating it to the Pod? There is no need to talk to the Kubernetes API if you just store it in an emptyDir that survives until the Node is restarts (memory-backed emptydir) or the pod is deleted (regular emptyDir).

[krezovic]

If you want to store the token only for the lifetime of a Pod, it would be easier to use a (memory-backed) emptyDir to store the token.

https://kubernetes.io/docs/concepts/storage/volumes/#emptydir-memory-configuration-example

Why all the complications with annotating it to the Pod? There is no need to talk to the Kubernetes API if you just store it in an emptyDir that survives until the Node is restarts (memory-backed emptydir) or the pod is deleted (regular emptyDir).

Well this is embarrassing. POD actually uses tmpDir, I just had to check if the tmpdir was written to before attempting to register.

Thanks for the hint and feedback, the solution became much more simple :)

[krezovic]

Hello @blotus and @sabban. This MR became much more simpler after addressing feedback from @SISheogorath. Would you please take a look and maybe finally merge it? Thanks

[rumfuddle]

Hi, any particular reason why this is not merged yet apart from time constraints? It seems to be a valuable fix and without it, it's too risky for us to use AppSec for production.

[gautamnimmala]

Hi, we are actively using CrowdSec in a Kubernetes environment, and this fix addresses a real production issue we are facing. Could you share any timeline on when this PR is likely to be reviewed and merged?

[gautamnimmala]

Hello @krezovic, @blotus, and @sabban, could you please let us know when this fix will be merged? We are actively using CrowdSec in a Kubernetes environment for PROD.

[jensens]

This blocks me as well. I have many years of experience managing FOSS projects. I can help out here and there if needed. Just ping me.