Allow combining password auth and tls auth for machines and bouncers independently

[Kuchenmampfer]

What would you like to be added?

/kind enhancement

Please allow to choose the authentication type (password or tls auth) for machines and bouncers separately by either offering separate configuration options or allow to use certificates in the lapi credentials alongside a password so that the certificates are used for encryption, but not authentication which is handled by the password.

Why is this needed?

In my crowdsec setup, I would like to only use a password authenticated localhost machine (that acquire from a centralised Loki), but then combine that with many bouncers that use TLS authentication. I want this setup, because I already have certificates set up, but not with a differing OU for the crowdsec server and I don't want to authorise other servers with machine permissions.

Currently, I have tls auth configured for the bouncers, but when I try to connect with a machine through its registered credentials, I get the following error message:

"crowdsec init: while initialising LAPIClient: authenticate watcher (188b82b05a1f4befbe3673ef63bd3d53BSM8vMRB6qBemcKa): Post \"https://[::]:443/v1/watchers/login\": performing jwt auth: tls: failed to verify certificate: x509: cannot validate certificate for :: because it doesn't contain any IP SANs"

I suspect that this is because the lapi expects clients to have certificates which my machine does not use when I put a password in its lapi credentials. I have tried putting both the certificate paths and the password there, but then it complains about both authentication mechanisms are mutually exclusive.

While setting this up, I have also encountered a small bug: When generating lapi credentials through cscli machines add -a --force --error, a http url is written to the credentials file even though my lapi uses https. Due to that, crowdsec fails to start. If I add the missing s to the url, everything runs fine. Shall I open a separate issue for this?

I am running crowdsec 1.7.6 on debian bookworm.

[github-actions]

@Kuchenmampfer: 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]

@Kuchenmampfer: 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.

[Kuchenmampfer]

/kind enhancement

[blotus]

Hello,

This does not seem related to the TLS auth.
By default, if nothing is set in api.server.tls.client_verification in the LAPI config, crowdsec will only use certificate authentication if a cert is sent by the client (see here).

The error you have is about the client validating the server certificate.
cannot validate certificate for :: because it doesn't contain any IP SANs: Are you using :: as the LAPI URL in the LP config ?

If so, the best solution is to use either a proper domain (and make sure your cert is valid for it), or an actual IP (for which the cert is also valid).
Crowdsec would also need to trust the parent certificate.

You can also try to set api.client.insecure_skip_verify in the LP config, but this will make the LP skip all validation of the server certificate.