[BUG] LAPI instances are registered in the portal as if they were log procesors

[david-garcia-garcia]

Looks like the LAPI pod is registering itself into the CAPI as if it were a log procesor. I do not know if this is intended or not:

Plus they keep accumulating endlessly because flush criteria is flaky: crowdsecurity/crowdsec#3728

[github-actions]

@david-garcia-garcia: 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]

@david-garcia-garcia: 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.

[LaurenceJJones]

Yes, it is kind off intentional but has this side effect.

So the tldr is that if you want to use all cscli commands you have to have valid credentials made and we didn't want user to be confused that they couldn't run those cscli commands within the LAPI pods.

The issue is "machines" do not have the context if the machine is LAPI, log processor or both so simply a machine is counted towards your total count, this is fine for traditional deployments but within k8s this issue is more promient.

Furthermore the issue with lapis not being flushed since they do not have a last heartbeat just further emphasises the issue since LAPI do not actually use the credentials at runtime they are simply made for cscli.

We having a pending task for all lapis to use the same generated credentials this means that if you have X amount of replicas they will just be simply counted as 1 in the console. It doesn't completely solve the issue as 1 will be billable but that is the easiest solution we have for now until we either extend the machines table or use a combination of the machine metrics to know which flags the machine has enabled.

Hope that gives some context and the current situation plus a slight fix.