Add autoregistration functionality to agents

[ViktorOrda]

What would you like to be added?

In this #3202 PR possibility to automatically register machines in LAPI was introduced. As far as I can see, there are no such automatical fuctionality for agents: as pointed in the docs, after LAPI configuration one should manually register agent machine. We wanna use containerized solution with autoscaling, so agents autoregistration is crucial for us.

I've tried several ways to implement such a solution locally:

1. Start agent container with LAPI disabled (and try to configure remote LAPI server in runtime) - agent container didn't start because of the next errors:

level=debug msg="running agent after 625.768181ms ms"
level=debug msg="[URL] POST http://0.0.0.0:8080/v1/watchers/login"
level=debug msg="resetting jwt token"
level=fatal msg="unable to start crowdsec routines: authenticate watcher (): Post \"http://0.0.0.0:8080/v1/watchers/login\": performing jwt auth: dial tcp 0.0.0.0:8080: connect: connection refused" 

2. Start agent container with LAPI enabled, register it to the remote LAPI and restart agent (as described in the blog post) - there were 2 cases:

• after agent registration in remote LAPI, local LAPI was disabled in config (as mentioned in article). After container restart it didn't start becase of the next errors

Error: no matches found
Generate local agent credentials
level=warning msg="crowdsec local API is disabled because 'enable' is set to false"
level=fatal msg="local API is disabled -- this command must be run on the local API machine"

• after agent registration in remote LAPI, local LAPI was not disabled. After container restart LAPI URL was reverted to http://0.0.0.0:8080 according to the entrypoint script

Even if container started without any errors, this solution is not suitable for us - we use AWS Fargate as container runtime, so container restart would lead to its re-creation.

3. Start agent container with remote LAPI configured initially:

• token can't be passed in local_api_credentials.yaml

level=fatal msg="loading api client: failed unmarshaling api client credential configuration file '/etc/crowdsec/local_api_credentials.yaml': yaml: unmarshal errors:\n  line 1: field token not found in type csconfig.ApiCredentialsCfg"

• passing token via password parameter doesn't work (expected 😄)

Why is this needed?

It would be great to have possibility to pass autoregistration token to agent machines (either via local_api_credentials.yaml or via env vars)

[github-actions]

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

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

[LaurenceJJones]

Please note the PR you are referencing is not general release yet, you can either use the dev container image OR shortly the RC1 tag for 1.6.4

I will read the rest of your issue, I thought I'll point this out early so you can see why it may not have worked.

Edit: Okay, I can see the issue is the docker_script has no way to pass the registration method to the container runtime, plus also at the moment I dont see any calls to cscli lapi register I guess it hard for us to gauge within the context if this should be ran, however, with this new variable we should presume it will be a remote LAPI.

[LaurenceJJones]

Just for documentation skake I dump some ideas here:

crowdsec/docker/docker_start.sh

Lines 277 to 284 in 5d414f5

	conf_set_if "$LOCAL_API_URL" '.url = strenv(LOCAL_API_URL)' "$lapi_credentials_path"
	if istrue "$DISABLE_LOCAL_API"; then
	# we only use the envvars that are actually defined
	# in case of persistent configuration
	conf_set_if "$AGENT_USERNAME" '.login = strenv(AGENT_USERNAME)' "$lapi_credentials_path"
	conf_set_if "$AGENT_PASSWORD" '.password = strenv(AGENT_PASSWORD)' "$lapi_credentials_path"
	fi

We check if LAPI is disabled then set the configuration via env vars that are passed into the container, if we have a registration token these could be randomly generated instead 🤷🏻 so we should add an if check firstly if these vars exist then set them?

then there should be a if check on the registration key and if this is passed we run cscli lapi register either with the passed username/password or randomly generated? so for example I would expect the agent env vars to be below:

DISABLE_LOCAL_API=true
LOCAL_API_URL=http://remote_api_url
LOCAL_API_TOKEN=XYZ123 ## Sets token on LAPI only nodes?
AGENT_AUTO_REGISTRATION_TOKEN=XYZ123 ## Sets token to be used by agents when registering 

We might want to rename the varaible as you might want to spin up a LAPI only that sets the configuration as this token but 🤷🏻

[LaurenceJJones]

Also because I never asked, are you using some orchestration software like kubernetes for auto scaling?

[ViktorOrda]

We use AWS ECS Fargate as orchestrator

[ViktorOrda]

IMO env for LAPI (i.e. LOCAL_API_TOKEN) is not so necessary since LAPI should be single - token can be passed via config.yaml.local. But for agents passing parameters as envs is more convenient

[LaurenceJJones]

IMO env for LAPI (i.e. LOCAL_API_TOKEN) is not so necessary since LAPI should be single - token can be passed via config.yaml.local. But for agents passing parameters as envs is more convenient

Yeah I came to the same conclusion whilst I was editing my comments 👍🏻

For now a workaround seems unlikely, as technically you could just modify the startup script and add the checks (we need to test and validate it before we merge anything hence the 1.6.5 flag as 1.6.4 is nearing feature completion.)

 conf_set_if "$LOCAL_API_URL" '.url = strenv(LOCAL_API_URL)' "$lapi_credentials_path" 
  
 if istrue "$DISABLE_LOCAL_API"; then 
     # we only use the envvars that are actually defined 
     # in case of persistent configuration 
     if [  "$AGENT_USERNAME" != "" ] then;
        conf_set_if "$AGENT_USERNAME" '.login = strenv(AGENT_USERNAME)' "$lapi_credentials_path" 
     fi
     if [  "$AGENT_PASSWORD" != "" ] then;
        conf_set_if "$AGENT_PASSWORD" '.password = strenv(AGENT_PASSWORD)' "$lapi_credentials_path"
     fi
     if [  "$AGENT_AUTO_REGISTRATION_TOKEN" != "" ] then;
       if [  "$AGENT_USERNAME" != "" ] then;
           cscli lapi register --url "$LOCAL_API_URL" --token "$AGENT_AUTO_REGISTRATION_TOKEN" --machine "$AGENT_USERNAME"
       else
           cscli lapi register --url "$LOCAL_API_URL" --token "$AGENT_AUTO_REGISTRATION_TOKEN"
       fi
     fi
 fi 

[ViktorOrda]

technically you could just modify the startup script

Was thinking about the same during investigation 🙂

[burylo]

I use Helm to set up CrowdSec. The agent’s registration works fine, but validation doesn’t

wait-for-lapi-and-register container:
level=info msg="Successfully registered to Local API (LAPI)" level=info msg="Local API credentials written to '/etc/crowdsec/local_api_credentials.yaml'" level=warning msg="Run 'sudo systemctl reload crowdsec' for the new configuration to be effective."

crowdsec-agent container:
time="2025-01-09T17:52:37Z" level=fatal msg="unable to start crowdsec routines: authenticate watcher (crowdsec-agent-9pgjh): API error: machine crowdsec-agent-9pgjh not validated"

Go by this instruction
https://www.crowdsec.net/blog/kubernetes-crowdsec-integration

[ViktorOrda]

@burylo as I can see, your message is not related to the initial issue. Moreover, it just confirms that agent autoregistration feature is not implemented - is is replaced by wait-for-lapi-and-register init container in k8s Helm charts

[fgeck]

@ViktorOrda I am running into the same issue as @burylo .
Should I open a new issue, or is there some documentation or similar because we are missing something obvious?

[burylo]

@fgeck Of course, why not? I searched the documentation, but I didn't find anything like that. However, something may have been updated during this time. I was looking for a solution for my project, and came across CrowdSec, it was almost perfect except for the problem with automatic agent validation. So I went ahead and rejected the CrowdSec option

[LaurenceJJones]

@ViktorOrda I am running into the same issue as @burylo . Should I open a new issue, or is there some documentation or similar because we are missing something obvious?

Hey @fgeck and @burylo if you are using helm best place to raise issues is the chart repo itself https://github.com/crowdsecurity/helm-charts

The issue with agent auto registration is you need to use the token that is generated to be used by the LAPI to accept requests:

lapi:
  config.yaml.local: |
    api:
      server:
        auto_registration:
          enabled: true
          token: "${REGISTRATION_TOKEN}" # /!\ Do not modify this variable (auto-generated and handled by the chart)
          allowed_ranges:
            - "10.0.0.8/8" #modify to your cluster requirements

[burylo]

No, problem with validation, bit registration. It's not very convenient to go in and manually validate pods every time after they've been converted. сб, 8 лют. 2025 р., 11:08 користувач Laurence Jones < ***@***.***> пише:

…

@ViktorOrda <https://github.com/ViktorOrda> I am running into the same issue as @burylo <https://github.com/burylo> . Should I open a new issue, or is there some documentation or similar because we are missing something obvious? Hey @fgeck <https://github.com/fgeck> and @burylo <https://github.com/burylo> if you are using helm best place to raise issues is the chart repo itself https://github.com/crowdsecurity/helm-charts The issue with agent auto registration is you need to define a token to be used by the LAPI to accept requests: lapi: config.yaml.local: | api: server: auto_registration: enabled: true token: "${REGISTRATION_TOKEN}" # /!\ Do not modify this variable (auto-generated and handled by the chart) allowed_ranges: - "10.0.0.8/8" — Reply to this email directly, view it on GitHub <#3319 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AZAT2FLHQQRZVNVF2QE5WDL2OXCPVAVCNFSM6AAAAABRNZQEK2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNBUG4ZTKNBVG4> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[LaurenceJJones]

No, problem with validation, bit registration

If you define the token, it automatically validates.

[fgeck]

@LaurenceJJones thank you. Your post solved my issue. Flux was templating "${REGISTRATION_TOKEN}" to an empty string.