CrowdSec•5mo ago

csLapiSecret and registrationToken injection from k8s secret impossible

Hello, I deployed Crowdsec using helm chart in 0.18.1 version, and I want to make my agents register to my LAPI with the csLapiSecret and the registrationToken. Both fields are present in the helm values. In order not to hardcode them in values, I wanted to inject the content of a k8s secret in the LAPI container environment variables but it doesn't work. Do you know if it is really impossible to do it or is there something I failed?

30 Replies

CrowdSec•5mo ago

Important Information

Thank you for getting in touch with your support request. To expedite a swift resolution, could you kindly provide the following information? Rest assured, we will respond promptly, and we greatly appreciate your patience. While you wait, please check the links below to see if this issue has been previously addressed. If you have managed to resolve it, please use run the command /resolve or press the green resolve button below.

Log Files

If you possess any log files that you believe could be beneficial, please include them at this time. By default, CrowdSec logs to /var/log/, where you will discover a corresponding log file for each component.

Guide Followed (CrowdSec Official)

If you have diligently followed one of our guides and hit a roadblock, please share the guide with us. This will help us assess if any adjustments are necessary to assist you further.

Screenshots

Please forward any screenshots depicting errors you encounter. Your visuals will provide us with a clear view of the issues you are facing.

Unknown User•5mo ago

Message Not Public

MTRYLAOP•5mo ago

Okay, but actually I have two problems: 1. If I don't set a csLapiSecret value, my agents don't succeed in registering to LAPI. 2. I use FluxCD to deploy Crowdsec. Do you have an example of to use it for indicating the secret name that would contain the csLapiSecret value?

Unknown User•5mo ago

Message Not Public

MTRYLAOP•5mo ago

Alright, actually I have one cluster named "trinity" where the LAPI is deployed on, and I have other clusters named "annexe" that deploy agents that only give information to the LAPI in "trinity" cluster (which means I disabled lapi on "annexe" clusters"). I decided that because I would like Crowdsec to take cross-cluster decisions. It means that agents register well to LAPI on "trinity" cluster, but those on "annexe" clusters don't -> here is the helm error on "annexe" clusters

Helm upgrade failed for release crowdsec/crowdsec with chart crowdsec@0.18.1: execution error at (crowdsec/templates/lapi-secrets.yaml:11:19): lapi.enabled is false, but no lapi.secrets.csLapiSecret provided

Here are my values:

config:
      config.yaml.local: |
        db_config:
          type:     postgresql
          user:     ${DB_USER}
          password: ${DB_PASSWORD}
          db_name:  ${DB_NAME}
          host:     ${DB_HOST}
          port:     5432
          sslmode:  disable
          flush:
            agents_autodelete:
              login_password: 60m # This includes the auto registration token as well
            ## Flush both login types if the machine has not logged in for 60 minutes or more

      api:
        server:
          auto_registration:
            enabled: true
            token: "${REGISTRATION_TOKEN}"
            allowed_ranges:
                - 10.0.0.0/8
                - 100.0.0.0/8
                - 100.64.0.0/16
                - 100.96.0.0/16

Unknown User•5mo ago

Message Not Public

MTRYLAOP•5mo ago

I have tested with the following configurations and I made the crowdsec-lapi pod fall into CrashLoopBackOff state because "

time="2025-04-16T14:53:13Z" level=fatal msg="api server init: unable to run local API: controller init: CS_LAPI_SECRET not strong enough"

". I guess LAPI reads CS_LAPI_SECRET as the content of the secret... Here is my fluxcd kustomization file:

apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: crowdsec
  namespace: flux-system
spec:
  interval: 1h
  retryInterval: 1m
  timeout: 5m
  sourceRef:
    kind: GitRepository
    name: crowdsec
  path: ./k8s/dev-front-trinity/
  prune: true
  postBuild:
    substituteFrom:
      - kind: Secret
        name: crowdsec-lapi-secret
        optional: true

Here is my secret file:

apiVersion: v1
kind: Secret
metadata:
  name: crowdsec-lapi-secret
  namespace: crowdsec
type: Opaque
stringData:
  CROWDSEC_LAPI_SECRET: 7f7AucGy@Wy@#sBbZ6qGtHuTqKqyvwKxQyz&1SY4s7br%ZS73MF^iLl%Hf9^2CF41u

Here is kustomization file:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - ../_base/crowdsec
  - ../_base/crowdsec/crowdsec
  - ../_base/crowdsec/pg-cluster
  - ../_base/crowdsec/cloud-armor-bouncer
  - hr--webhook-receiver.yaml
  - secret--lapi.yaml

Unknown User•5mo ago

Message Not Public

MTRYLAOP•4mo ago

Yes I did. But in the helm values, which field is used for setting a registration token for agents to lapi ? I want my agents on cluster b to register to LAPI hosted on cluster a. I well set the agent.lapiHost on values as is:

agent:
      lapiHost: "crowdsec-service.crowdsec.svc.clusterset.local"
      lapiURL: "http://crowdsec-service.crowdsec.svc.clusterset.local:8080"
      lapiPort: 8080
      acquisition:
        - namespace: "lark-edge"
          podName: "lark-edge-*"
          program: "www-xx-fr"
          poll_without_inotify: true

Here are my values on cluster a:

config.yaml.local: |
        api:
          server:
            auto_registration:
              enabled: true
              token: "${REGISTRATION_TOKEN}"
              allowed_ranges:
                - 10.0.0.0/8

As my agents on cluster b have to register to LAPI on cluster a, they have to regsiter with the same token defined in the cluster a (which is REGISTRATION_TOKEN here). But is there a way in the helm values to set the token used by agents to register to LAPI ?

blotus•4mo ago

We've recently merged https://github.com/crowdsecurity/helm-charts/pull/265/files, which allows to specificy the name of a secret to use as the registration token. We haven't made a new release of the chart yet, but I think it would solve your issue

GitHub

Support external secret by krezovic · Pull Request #265 · crowdse...

Fixes: #257 /kind enhancement /area configuration

blotus•4mo ago

that way, you will be able to specify a value you generate yourself

MTRYLAOP•4mo ago

Alright it's interesting

blotus•4mo ago

for now, you can also get the value from the secret crowdsec-lapi-secrets (it will change if you uninstall and reinstall the chart, so not a good long term solution)

MTRYLAOP•4mo ago

ok but the current lapi.secret.registrationToken is used for what ?

blotus•4mo ago

it's autogenerated and pass as an env var to the LAPI pod and the agent pods You can try to edit the secret in cluster B to the value of the secret in cluster A, it will probably work, but I'm not 100% sure

MTRYLAOP•4mo ago

Yes i edited the secret in cluster B and it works but it's manual and not automated, as you probably assumed so now, it's not possible to set our own registration token in the values ?

blotus•4mo ago

at the moment, no it will be included in the next release

MTRYLAOP•3mo ago

okay I deployed the last version and specified the externalSecret.name, externalSecret.csLapiSecretKey and externalSecret.registrationTokenKey. But some times the crowsec-agents daemonset falls into CrashLoopBackOff due to "time="2025-05-28T11:42:46Z" level=fatal msg="crowdsec init: while initializing LAPIClient: authenticate watcher (crowdsec-agent-2dnzj): API error: ent: machine not found"". Why ? couldn't it be due to the fact that I set 3 LAPI replicas ? or is it due to the fact that the newly created agent checks too fast if the LAPI is ready ? I tested modifying the readinessProbe of agents to /health on 8080 port. I will see if it fixes the CrashLoopBackOff issue. @blotus

blotus•3mo ago

Can you check if the agent exists in the LAPI DB ? The init container of the agent should take care of registering itself on start. You can also try to see if you have any errors in its logs. The only way for it to skip the registration is to set tls.agent.tlsClientAuth , but I'm guessing it's not the case for you (or you wouldn't have authentication issues)

MTRYLAOP•3mo ago

you mean in the machines table ? there is no errr logs in the init container, in charge of registering agents to lapi Indeed, I didn't set the tls.agent.tlsClientAuth field

blotus•3mo ago

yes you can check with cscli machines list Can you paste the logs from the init container ? just to be sure

MTRYLAOP•3mo ago

because I see nothing directly in the database

MTRYLAOP•3mo ago

here are the cscli machines list command outputs

MTRYLAOP•3mo ago

the first pod is running, the second one fell into CrashLoopBackOff error

MTRYLAOP•3mo ago

what do you tkink of it? @blotus

_KaszpiR_•3mo ago

You didn't provide any logs from the containers, so it is hard to guess what is wrong. Also I would double check the secret used if it is actually what it should be.

MTRYLAOP•3mo ago

These are logs from the init container

MTRYLAOP•3mo ago

message.txt

MTRYLAOP•2mo ago

these are logs from the main container can you help me regarding these information? ?

Gaming

Programming

csLapiSecret and registrationToken injection from k8s secret impossible

Did you find this page helpful?