Appsec high availability using replicas

[srkoster]

Thanks @he2ss for implementing Appsec into the Crowdsec helmchart. This PR builds upon #189 and #206 and make Appsec high availability possible by defining appsec.replicas.

Other changes:

• RegistrationToken generation is moved into _helpers.tpl. It can now also be passed through values.yaml
• appsec-deployment.yaml is structured more like agent-deployment.yaml
• Added the appsec registration_token config into values.yaml (starred out)
• ci\crowdsec-values.yaml: removed agent.additionalAcquisition as the dummy values make the helm chart test fail because the agent pod isn't able to start.
• ci\crowdsec-values.yaml: added agent.metrics.enabled: true to use the agent metrics endpoint in the helm chart test
• test_agent_up.yaml: Using the LAPI watchers/login endpoint with username and password is no longer an option when using autoregistration. Instead check the agent metrics endpoint to see if the agent is running during the helm chart test.

[github-actions]

@srkoster: There are no 'kind' label on this PR. You need a 'kind' label to generate the release automatically.

• /kind feature
• /kind enhancement
• /kind fix
• /kind chore
• /kind dependencies

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]

@srkoster: There are no area labels on this PR. You can add as many areas as you see fit.

• /area agent
• /area local-api
• /area cscli
• /area security
• /area configuration

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.

[srkoster]

/kind enhancement
/area configuration

[he2ss]

Hi @srkoster,

I'm sorry I didn't reply quickly to the old PR. IMO, for the high availability, we can play with replicas, and that's it.
The DaemonSet for the agent is different because the agent pod is mounting the node logs directory and analyzing them while the appsec is communicating over HTTP with the ingress controllers via the bouncer.
So what I suggest, is to have only the deployment for the appsec, so users can handle HA with replicas and annotations if they want.

[srkoster]

@he2ss no worries. Thanks for explaining why the agent is defined as a daemonset and your thoughts about the appsec deployment. I've removed the daemonset option from the PR.

[he2ss]

Hi @srkoster,

Sorry, I got busy with other tasks. So I have a last comment. Otherwise the PR seems good, I also tested it and seems working 👍

[srkoster]

I resolved the merge conflict by accepting the config.yaml.local.api.server.auto_registration comment from main

[he2ss]

Hi @srkoster,

I'll bother you again. The chart testing has been falling since this PR:#209

We may want to autoregister an agent before connecting to Lapi in the test chart. Can you please handle this?

[srkoster]

Hi @he2ss,
Yes, i'll have a look.

[srkoster]

@he2ss
The chart testing fails for 2 reasons:

• The test-agent pod can't be created because it still relies on the agent-credentials secret, which is removed in favor of autoregistration. I've fixed this in this PR by removing the environment variables referring to it and changing the test to do a curl on the agent metrics port. This test is imho a better implementation than the current one, as it checks if the agent is running successfully instead of logging in the LAPI with the test-agent pod.
• The agent pod isn't running but in status error. This is because the ci/crowdsec-values.yaml contains agent.additionalAcquisition. These additionalAcquisitions don't work, prevent the agent pod from running successfully and thus make the test-agent pod fail after my modification above. For example, the chart test shows:

time="2024-12-16T11:53:47Z" level=error msg="datasource 'journalctl' is not available: exec: \"journalctl\": executable file not found in $PATH"
time="2024-12-16T11:53:47Z" level=error msg="aws_region is not specified, specify it or aws_config_dir" group=/aws/my/group type=cloudwatch
time="2024-12-16T11:53:47Z" level=fatal msg="crowdsec init: while loading acquisition config: while configuring datasource of type cloudwatch from /etc/crowdsec/acquis.yaml (position: 4): failed to configure datasource cloudwatch: aws_region is not specified, specify it or aws_config_dir"

I've removed the agent.additionalAcquisition entry in a separate branch and the chart test is successful. Do you want me to modify the agent.additionalAcquisition entry in ci/crowdsec-values.yaml here or create a new PR?

[he2ss]

Thanks @srkoster for this troubleshoot.
Yes you can remove the additionalAcquisitions as was done to test the jsonSchema, but not relevant to put random info in those additionalAcquistions.

[srkoster]

@he2ss I've removed the agent.additionalAcquisition entry in this PR and modified the PR comment to reflect all changes.