How is storeCAPICredentialsInSecret expected to work?

[pfaelzerchen]

As far as I understood, the newly introduced storeCAPICredentialsInSecret option will store the credentials after enrolment of the security engine. I tried to set that option to true and persistentVolume.config.enable to false.

With this configuration, every restart of the lapi-container will do a new security engine enrolment. With persistentVolume.config.enable=true and storeCAPICredentialsInSecret=false restarting does not cause a new enrolment.

Is this behaviour intended? Or did I misunderstand storeCAPICredentialsInSecret?

[github-actions]

@pfaelzerchen: Thanks for opening an issue, it is currently awaiting triage.

If you haven't already, please provide the following information:

• kind : bug, enhancementor documentation
• area : agent, appsec, configuration, cscli, local-api

In the meantime, you can:

1. Check Crowdsec Documentation to see if your issue can be self resolved.
2. You can also join our Discord.
3. Check Releases to make sure your agent is on the latest version.

Details

I am a bot created to help the crowdsecurity developers manage community feedback and contributions. You can check out my manifest file to understand my behavior and what I can do. If you want to use this for your project, you can check out the forked project rr404/oss-governance-bot repository.

[github-actions]

@pfaelzerchen: There are no 'kind' label on this issue. You need a 'kind' label to start the triage process.

• /kind bug
• /kind documentation
• /kind enhancement

Details

I am a bot created to help the crowdsecurity developers manage community feedback and contributions. You can check out my manifest file to understand my behavior and what I can do. If you want to use this for your project, you can check out the forked project rr404/oss-governance-bot repository.

[pfaelzerchen]

/kind documentation

[blotus]

Hello,

The goal of this settings is store the CAPI credentials in a secret, so that if you don't want (or can't) persist the config of the LAPI pod, you will not lose them between restarts or upgrades.

From our testing, the credentials are stable over time when deleting and recreating the LAPI pod (if you uninstall and reinstall the chart, they will not be kept).

A small precision: the pod will always try to enroll itself in the console, but will get an error from CAPI telling it it's already enrolled (it's the expected behavior, not very clean, but way easier to handle in the docker startup script.)
Do you see multiple enrollment requests in the console ?

[pfaelzerchen]

I am deploying the chart via ArgoCD. So probably the secret will be recreated that way. But yes, I see multiple enrolment requests in the console that I have to confirm.

[srkoster]

I use Flux and restarting the container doesn't trigger a new enrollment. Removing the Helmrelease or the Kustomization above it does (which is to be expected unless I would put the following annotation on the secret
kustomize.toolkit.fluxcd.io/prune: disabled. Unfortunately I would have to do that manually, maybe a nice feature for the chart to be able to add annotations to the secret)

[pfaelzerchen]

Just retested the CAPI secret variant with v0.15.0. After one initial enrolment (as expected) the secret is stable and restarting the lapi container does not cause new enrolments. I will check if this remains stable when redeploying config changes.

[pfaelzerchen]

I believe it has something to do with the way ArgoCD deploys crowdsec. After changing the values (adding a new collection and acquisition) ArgoCD does a resync and seems to rerun the CAPI key generation leading to a new enrolment in the console.

ArgoCD displays waiting for completion of hook batch/Job/crowdsec-capi-register-job which probably causes the re-enrolment.