IP address changes cause bouncers to be registered again
What would you like to be added?
/kind enhancement
Add support for ephemeral bouncer registration to avoid duplicate registrations on IP changes.
Currently, when a bouncer restarts with a different IP, I believe the different IP causes it to register as a new instance with the new IP address appended to the name.
While not a direct comparison, a similar example would be Tailscale's ephemeral nodes where a separate API key is created to better support ephemeral environments.
Why is this needed?
When deploying a bouncer in an ephemeral environment—such as a pod in a Kubernetes cluster—the pod receives a new IP address each time it is recreated. I believe this causes the bouncer to effectively “re-register” itself by appending the new IP address to its name.
Using go-cs-bouncer, if I create a live/streaming bouncer with the same API key and user agent and deploy it in a Kubernetes pod, each pod recreation results in the new pod’s IP address being appended to the existing bouncer name.
While stale bouncers can be pruned, the system accumulates metrics and metadata associated with the old bouncer names, leading to scenarios like:
cscli metrics
╭──────────────────────────────────────────────────────────────────────────────────────────────────────╮
│ Local API Bouncers Metrics │
├──────────────────────────────────────────────────────────────┬──────────────────────┬────────┬───────┤
│ Bouncer │ Route │ Method │ Hits │
├──────────────────────────────────────────────────────────────┼──────────────────────┼────────┼───────┤
│ envoy-bouncer │ /v1/decisions │ GET │ 5 │
│ envoy-bouncer │ /v1/decisions/stream │ GET │ 24 │
│ [email protected] │ /v1/decisions │ GET │ 22 │
│ [email protected] │ /v1/decisions/stream │ GET │ 477 │
│ [email protected] │ /v1/decisions │ GET │ 1 │
│ [email protected] │ /v1/decisions/stream │ GET │ 18 │
│ [email protected] │ /v1/decisions │ GET │ 28 │
│ [email protected] │ /v1/decisions/stream │ GET │ 700 │
│ [email protected]@10.42.5.128 │ /v1/decisions │ GET │ 56 │
│ [email protected]@10.42.5.128 │ /v1/decisions/stream │ GET │ 4148 │
│ [email protected]@[email protected] │ /v1/decisions │ GET │ 11 │
│ [email protected]@[email protected] │ /v1/decisions/stream │ GET │ 283 │
│ [email protected]@[email protected]@10.42.5.127 │ /v1/decisions │ GET │ 919 │
│ [email protected]@[email protected]@10.42.5.127 │ /v1/decisions/stream │ GET │ 36027 │
│ [email protected]@[email protected]@10.42.5.219 │ /v1/decisions │ GET │ 4 │
│ [email protected]@[email protected] │ /v1/decisions │ GET │ 118 │
│ [email protected]@[email protected] │ /v1/decisions/stream │ GET │ 2614 │
╰──────────────────────────────────────────────────────────────┴──────────────────────┴────────┴───────╯
This behavior complicates accurate tracking of bouncer metrics and metadata over time.
@kdwils: Thanks for opening an issue, it is currently awaiting triage.
In the meantime, you can:
- Check Crowdsec Documentation to see if your issue can be self resolved.
- You can also join our Discord.
- 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.
@kdwils: 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.
/kind enhancement