Flush LAPI

[PseudoResonance]

What would you like to be added?

/kind enhancement

Why is this needed?

LAPI registrations build up infinitely on Kubernetes.

Bouncers and agents can be automatically flushed, however LAPIs cannot. For example, I currently 5 appsecs and 5 agents, but 52 LAPIs in the machine list from the past few months...

[github-actions]

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

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 BirthdayResearch/oss-governance-bot repository.

[github-actions]

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

• /kind feature
• /kind enhancement
• /kind refactoring
• /kind bug
• /kind packaging

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 BirthdayResearch/oss-governance-bot repository.

[PseudoResonance]

/kind enhancement

[blotus]

Hello,

We still need to update the documentation, but we added a new lapi.StoreLAPICscliCredentialsInSecret (disabled by default) option in the latest helm chart release which should address this.
If enabled, it will store the credentials in a secret, and will reuse the same creds for every LAPI pods (it will create a new entry in the database, and you will need to delete the old ones manually, but once this is done, the count will stay at 1).

[PseudoResonance]

Sorry if I'm misunderstanding, but how does that help? When the pod is recreated due to configuration changes to the deployment, the new pod that comes up has a different name, and thus a new entry in the list. Maybe I misconfigured something? I'm not sure.

[LaurenceJJones]

Sorry if I'm misunderstanding, but how does that help? When the pod is recreated due to configuration changes to the deployment, the new pod that comes up has a different name, and thus a new entry in the list. Maybe I misconfigured something? I'm not sure.

So the only reason LAPI get credentials is to allow the user to use cscli, in normal operation LAPI do not use the credentials hence why the flush does not operate on them (they have no heartbeat and since time = nil we cannot know when to flush them).

The option purposed is instead of each LAPI pod getting a credential each, they get one shared so when using cscli you can still auth and do the normal things without thinking "ohh to list alerts I have to exec into the agent pod because they have credentials"

Hope that clears up any confusion.

[PseudoResonance]

Ah, I see. Thank you for the clarification, I didn't quite understand how LAPI was interacting with the rest of the system.

However, I'm still confused about "you will need to delete the old ones manually, but once this is done, the count will stay at 1." If the pod is recreated with a new ID, it will still authenticate with a new ID and cause duplicates over time right? Ultimately, it's not that big of a deal, but I just figured I'd ask.

[LaurenceJJones]

Ah, I see. Thank you for the clarification, I didn't quite understand how LAPI was interacting with the rest of the system.

However, I'm still confused about "you will need to delete the old ones manually, but once this is done, the count will stay at 1." If the pod is recreated with a new ID, it will still authenticate with a new ID and cause duplicates over time right? Ultimately, it's not that big of a deal, but I just figured I'd ask.

What blotus is suggesting is setting the configuration to share credential. Once done run cscli machines prune (this will delete all machines with expired last heartbeat and nil heartbeats)

Once done on your next deployment, each LAPI shares a single credential instead of each one generating their own. So if you have 2 lapis they have one shared and when you deploy over and over if the secret exists they will just reuse the same one instead of generating new ones.