[Fleet] Agent authentication model

[ph]

Context

When trust is important:

• At enroll, when the agent initially communicate to Fleet to receives the API KEY (which is both the Fleet key and the Elasticsearch key), the key is used to uniquely identify an Agent.

• At checkin, when the agent posts status and events and retrieves policies and actions.

• For the elasticsearch output and monitoring: when Events from Beats are sent to Elasticsearch.

Enroll

We will change the behavior to use certificate pinning to establish the initial trust, the agent will receive both an enrollment key and a certificate hash encoded using sha256. The agent will retrieve the remote certificate and compare the hash. If it matches we can trust the remote server and continue with the enroll.

Note: Due to how TLS termination and re-encryption is handled in Cloud we will need to add a new setting to Kibana to allow to specify what hash to use for the certificate verification.

As part of the enroll response, Fleet will need to send back in the payload the certificate authorities (CA) that the agent and the other processes managed by the agent can use to verify the authenticity of the Elasticsearch cluster used by the output or the monitoring endpoint. The Agent will need to persist that CA locally.

Checkin

The Agent will not use any locally defined CA to verify the remotes Elasticsearch cluster instead it will use the CA received when enrolling to identify the remote clusters.

Output and Monitoring

The Agent will not use any locally defined CA to verify the remotes Elasticsearch cluster instead it will use the CA received when enrolling to identify the remote clusters.

Changed needed

Fleet

• Make sure Fleet can return the Hash
• Make Fleet's enroll return the CA.

Agent

• Add options for Agent's enroll subcommand to specify a hash.
• Change behavior in the TLS handling of libbeat to support Certificate pinning
• Allow the agent to securely the CA on disk.
• Allow Libbeat Elasticsearch client to receive a CA in bytes and not only a file on disk.

[ph]

cc @mattapperson and @clintongormley This is the current plan for trust?

[nchaulet]

@ph How do we plane to manage certificate expiration/rotation?

[scunningham]

@nchaulet You mean when the CA expires? That's going to be a pain. We'll have to build some mechanism that allows a CA swap out when we get within N days of the CA expiring. Ideally we have some kind of trusted time source as well. We'd have to defend an attacker tricking the system into swapping out the root of trust with a counterfeit.

Perhaps we could punt on this problem short term, and enforce a CA with an expiration of 2+ years. Maybe more if we can get away with it.

[ph]

I think we can skip that for v1, and enforce 2+ sound like a good idea.

[ph]

Going to close this and link all the related issues.

Opened related issues based on the conclusion above:

• Update the design on the install page [Fleet] Update the install Agent page kibana#55453
• Allow to specify the CA Hash for Kibana and Elasticsearch in the Kibana configuration. [Fleet] Provide a way to specify the CA Hash for Kibana and the Elasticsearch host. kibana#55452
• Enrolling of the Agent need to verify the CA hash of the remote Kibana [Agent] required changes for enroll #15716
• Checkin call of the Agent to Fleet need to verify the CA hash. [Agent] The Checkin API need to verify the CA hash of the remote Kibana. #15718
• The elasticsearch output need to support CA pinning. [Agent] Add CA certificate pinning to the elasticsearch output. #15717

[ph]

Note only the kibana issue are still open.