Create Elastic Agent enrolment tokens in the operator #5846
Conversation
|
run/e2e-tests tags=agent |
1 similar comment
|
run/e2e-tests tags=agent |
|
Jenkins test this please |
| if kb.Status.Health != commonv1.GreenHealth { | ||
| return false, nil // requeue | ||
| } | ||
| return true, nil |
There was a problem hiding this comment.
I realise this does not work well with external KibanaRefs. I will look into making an actuall HTTP request instead here.
There was a problem hiding this comment.
It turns out this is a rabbit hole. Making external refs work is more complicated. Other things required: communication between Fleet Server and Elasticsearch needs to use a service token otherwise Agent will try to talk to Kibana to generate one. Also I ran into some weird connectivity issues where Agent seemed to connect to an IP directly without host header and failed to connect through the ESS proxy. Still looking into that, but I might punt the external ref support to another PR if it makes sense at all.
|
run/e2e-tests tags=agent |
|
@elasticmachine, run elasticsearch-ci/docs |
david-kow
changed the title
Do not expose highly privileged Kibana credentials to Elastic Agent Pods. Instead make the operator do all the Kibana API interactions with the more limited user (possible as of 8.1) and expose only the enrolment token to the Elastic Agent as it would be also the case on a typical bare metal installation. Tradeoffs: - Agent rollout needs to wait until Kibana is available (but in the old system the Agents would just crash loop until that was the case so I consider this actually an improvement) - Operator needs to stay up to date with Fleet API development. So far the relevant APIs have been fairly stable with one API being renamed for consistency. - Each Kibana association creates a Kibana user. Technically we could use a single user to do all the API interactions with Kibana but that would have broken out of the association mechanism and it seemed convenient and correct to keep using that.
Fixes #5779
See issue for detail on the approach taken. But to repeat the gist: do not expose highly privileged Kibana credentials to Elastic Agent Pods. Instead make the operator do all the Kibana API interactions with the more limited user (possible as of 8.1) and expose only the enrolment token to the Elastic Agent as it would be also the case on a typical bare metal installation.
Tradeoffs:
Some additional choices I made that are maybe of interest to reviewers: I am not reusing the default enrolment token but creating a new one. No particular strong reason for that. It allows us to clean the tokens up if something goes wrong and also allows us to run without explicitly calling
/api/fleet/setup(which creates the default tokens). In practice I ended up calling the setup API anyway because we cannot rely on users configuring Kibana with pre-defined policies inkibana.yml(as do all our recipes). So if there are strong feelings against creating our own tokens we can revisit this choice.I hope I did not miss anything fundamental. I did manual tests with
7.14(first version of Fleet we support),7.17and a recent8.x.