Elastic Agent: (docker) jq: command not found

[mtojek]

I pulled the lastest Docker image for agent and it doesn't start properly:

➜  environments git:(master) docker logs environments_elastic-agent_1
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100    22  100    22    0     0      2      0  0:00:11  0:00:08  0:00:03     6
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100    78  100    22  100    56     11     28  0:00:02  0:00:01  0:00:01    28
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   373  100   331  100    42    328     41  0:00:01  0:00:01 --:--:--   328
/usr/local/bin/docker-entrypoint: line 44: jq: command not found
{"isInitialized":true}{"isInitialized":true}%                                                                                                                                                                   ➜  environments git:(master)

[elasticmachine]

Pinging @elastic/ingest-management (Team:Ingest Management)

[michalpristas]

same here and it is blocking me so i started working on this

[blakerouse]

Sorry, very surprised this change didn't just work.

Looking at the reason for jq usage, I also wonder if we could just remove it completely. Seems the reason is to get the API key to enroll into Fleet, why not just integrate that directly into the enroll command of agent, instead of using curl and jq?

We should also add an integration test that does a basic smoke test of the agent docker container.

[michalpristas]

i think enroll command should not generate any tokens or setup fleet, it was meant to purely using a token you retrieved from sysadmin make agent capable of communicating with fleet. there was a discussion about this process in some issue about initial trust i will try to find it
@ph correct me please if i'm wrong

[ph]

@michalpristas This is correct, enroll should just make the trust from Agent to the remote Kibana instance.

[blakerouse]

Any reference to that issue so I can read up on it? Seems like it would make the user experience better if we could allow a user to enroll an agent with user/pass.

[nchaulet]

+1 to move the setup outside the docker agent, it could help to solve that issue too #18347 also I created that PR to avoid the creation of a token and used the one created by default #18365 but I am still using jq

[mtojek]

Please keep in mind not to remove entirely any important feature like setup or enrollment. We definitely need them in docker setup.

[blakerouse]

Currently the Dockerfile has this:

if [[ -n "${FLEET_ENROLLMENT_TOKEN}" ]] && [[ ${FLEET_ENROLLMENT_TOKEN} == 1 ]]; then
      apikey = "${FLEET_ENROLLMENT_TOKEN}"
    else
      enrollResp=$(curl -X POST  ${KIBANA_HOST:-http://localhost:5601}/api/ingest_manager/fleet/enrollment-api-keys \
        -H 'Content-Type: application/json' \
        -H 'kbn-xsrf: true' \
        -u ${KIBANA_USERNAME:-elastic}:${KIBANA_PASSWORD:-changeme} \
        -d '{"name":"'"${FLEET_TOKEN_NAME:-demotoken}"'","config_id":"'"${FLEET_CONFIG_ID:-default}"'"}')

      local exitCode=$?
      if [ $exitCode -ne 0 ]; then
        exit $exitCode
      fi

      apikey=$(echo $enrollResp | jq -r '.item.api_key')
    fi

    ./{{ .BeatName }} enroll ${KIBANA_HOST:-http://localhost:5601} $apikey -f

I feel like we could condense this into a single command in the agent itself, which will allow proper unit testing and not relying on bash, curl, or jq.

enroll ${KIBANA_HOST:-http://localhost:5601} --username ${KIBANA_USERNAME:-elastic} --password ${KIBANA_PASSWORD:-changeme}

If agent is already enrolled then it would skip the enrollment and we could add a --force to override the skip behavior. We could add this skip logic to the bash entrypoint, but that is just making the bash more complex and prevents the ability to unit test.

[nchaulet]

@blakerouse in my opinion the agent should only work with kibana host and the enrollment token, and we should never give kibana username and password to the agent

@mtojek in the docker setup can we add another container requirements for the agents, and this container will do the setup and get the enrollment token

[blakerouse]

Being that you still have to pass the username and password to the container for it to enroll unless you have the specific token, I do not see what your preventing by allowing the username and password. The enroll command would just use the username and password to get the token and save the token and not the username or password.

It's already doing the same thing it's just in bash, which is not unit tested or even currently integrated tested.

[ruflin]

Perhaps we need a third command here, something like fetch_enrollment_token (better name needed). This might support username/password or API key to be passed in and returns an API key. This means:

• Instead of having to use bash scripts, we have it on the agent side and can test it
• We still only support API keys for the final enrollment
• We could potentially fetch_enrollment_token, enroll and run merge into one additional command to make it simpler for the user.

[nchaulet]

I still have some concerns about having fetch_enrollment_token in the agent as the goal of enrollment tokens is to not send|use Kibana credentials everywhere too.