DISABLE_COLLECTIONS ignored when DISABLE_AGENT=true — LAPI-only container keeps unremovable default collections

[aversag]

What happened?

In a LAPI-only container (DISABLE_AGENT=true, no agent, no acquisition — CrowdSec used purely as a decision store fed by CAPI, with a remote bouncer enforcing decisions), the default collections baked into the image (crowdsecurity/linux and its dependencies: sshd, whitelist-good-actors, plus the related parsers/scenarios/contexts/postoverflows) are present in /etc/crowdsec and show up in cscli collections list.

Setting DISABLE_COLLECTIONS=crowdsecurity/linux — the documented way to drop default collections — has no effect, because the removal runs inside prepare_hub(), which returns early when the agent is disabled (build/docker/docker_start.sh):

prepare_hub() {
    if istrue "$DISABLE_AGENT"; then
        return
    fi
    ...
    ## Remove collections, parsers, scenarios & postoverflows
    if [ "$DISABLE_COLLECTIONS" != "" ]; then
        cscli_if_clean collections remove "$DISABLE_COLLECTIONS" --force
    fi
    ...
}

However, the collections arrive independently of the agent, via the staging populate step, which is not gated on DISABLE_AGENT:

if [ ! -e "/etc/crowdsec/local_api_credentials.yaml" ] && [ ! -e "/etc/crowdsec/config.yaml" ]; then
    ...
    rsync -av --ignore-existing /staging/etc/crowdsec/* /etc/crowdsec
fi

So the copy is unconditional but the removal knob is agent-gated → in a LAPI-only container there is no declarative way to remove the baked-in collections. On an emptyDir config this repeats on every boot.

What did you expect to happen?

One of:

• DISABLE_COLLECTIONS (and DISABLE_PARSERS / DISABLE_SCENARIOS / …) still honored when DISABLE_AGENT=true, so a LAPI-only deployment can clean up hub items it doesn't use; or
• the staging populate of hub items skipped when the agent is disabled (a pure LAPI has no use for scenarios/parsers); or
• at minimum, this behavior documented.

Visible symptom: cscli collections list on a LAPI-only engine advertises SSH scenarios that can never fire (no acquisition). It's misleading during audits and feeds "Security Engine: no activity" confusion in the Console.

How can we reproduce it (as minimally and precisely as possible)?

docker run -d --name cs-lapi \
  -e DISABLE_AGENT=true \
  -e DISABLE_COLLECTIONS="crowdsecurity/linux" \
  crowdsecurity/crowdsec:v1.7.7

docker exec cs-lapi cscli collections list
# crowdsecurity/linux, crowdsecurity/sshd, crowdsecurity/whitelist-good-actors
# are still installed despite DISABLE_COLLECTIONS

Same on Kubernetes via the official helm chart with agent.enabled=false (LAPI-only).

Anything else we need to know?

Current workarounds are all post-copy — e.g. a lifecycle.postStart hook running cscli collections remove crowdsecurity/linux --force (which cascades all deps cleanly, confirmed via --dry-run). With an emptyDir config this has to re-run every boot. An agent-independent DISABLE_*, or skipping the hub-item staging when the agent is off, would remove the need for that.

Related but distinct (both agent-side): #1910 (COLLECTIONS not authoritative), #1331 (install/remove ordering). This one is specifically the DISABLE_AGENT / LAPI-only path.

Crowdsec version

crowdsec/v1.7.7-981e6166-docker

OS version

alpine (docker) - 3.21.6

Enabled collections and parsers

crowdsecurity/linux, crowdsecurity/sshd, crowdsecurity/whitelist-good-actors
(all baked-in image defaults; no acquisition configured)

Acquisition config

none — LAPI-only (DISABLE_AGENT=true)

[github-actions]

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

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

[aversag]

/kind bug