Encryption between filebeat and Elastic Service?


When filebeat uses cloud.id and api_key fields, is the connection between filebeat and ElasticCloud encrypted ? Has anyone already checked this before ?
It would be helpful if you can point me to related documentation.

Thanks in advance for your reponse.

As far as I know Elastic Cloud only supports encrypted connections.

Hi @Chinnu welcome to the community and considering Elastic Cloud

First , yes ALL communications to and from all Elastic Cloud components is via HTTPS.

There are also many other security features see here.

You can also setup SAML

There are further security features such as IP Filters and Private Link connections as well.

Thank you @Christian_Dahlqvist

Thanks @stephenb for the documentation.
I have gone through it: Securing your deployment | Elasticsearch Service Documentation | Elastic
For a user provisioned instance, I understand that we can have encrypted connections via Public Key Infrastructure ( Java key store, trust store, keys etc).

But, in Elastic Cloud Service, we use cloud.id and api_key. In this case, is the communication between filebeat and Cloud encrypted first and then, secrets ( api key ) are then sent to Clould Cluster ?

Hi @Chinnu

Yes. The connection itself is HTTPS so any credential passed are via HTTPS / Encrypted.

cloud.id under the covers is just and encoded version of the https endpoints

There is no way to communicate with Elastic Cloud Resources (Elasticsearch, Kibana, APM, FLeet) in and unencrypted way.

Hi @stephenb
I take advantage of the space, to ask the following and suddenly not open another unnecessary thread.
I will handle PII data in the information that I will store in the elastic indexes, therefore I must implement encryption at rest of the indexes.
Would you have any information or documentation about it?
What options can I have?

Thanks in advance

Elastic Cloud has a very strong Security Posture

You should read this closely.

You should also read this closely

And about all the Security Features Here

To Directly to you question from the first link.

We’ve built In logical security controls

We've taken significant measures to ensure that Elastic Cloud customer data cannot be read, copied, modified, or deleted during electronic transmission, transport, or storage through unauthorized means. To reduce the likelihood of vulnerability-related incidents, the Elastic Cloud team deploys Elasticsearch instances based on the latest operating system kernels, and patches the computing “fleet” whenever a critical CVE (i.e., "Common Vulnerability and Exposure," in security-speak) is discovered in any component software. Similarly, Elastic software, including Elastic Stack components and Elastic Cloud Enterprise, used in the provisioning of Elastic Cloud SaaS offerings, is updated as soon as it is released to ensure the latest versions are deployed.

To protect customer data, Elastic Cloud clusters are equipped with Elastic security features that randomly assign individual passwords. Clusters are deployed behind redundant proxies and are not visible to internet scanning. Transport Layer Security (TLS) encrypted communication from the Internet is provided in the default configuration. Elasticsearch nodes run in isolated containers, configured according to the principle of least privilege, and with restrictions on system calls and allowed root operations. Elasticsearch nodes communicate using TLS (requires customer to select 6.0 or later versions of the Elastic Stack). Cluster data is encrypted at rest. We support IP address-based access controls so users may restrict access to their hosted deployments by filtering specific IP ranges. Additional network layer security is available on Amazon with AWS PrivateLink integration. Our support for AWS PrivateLink helps eliminate the exposure of your data to the public internet. This is accomplished by securing the network connection between your Amazon VPCs, applications, and your Elastic Cloud deployments on AWS. API access is limited to Elasticsearch APIs, and no remote access to the instance or container at the Linux level is allowed. Containers have no means of setting up communication with containers from another cluster.

And Finally Depending on your Company's Needs you should reach out to sales@elastic.co and engage with a Solution Architect Like Me.

Typically a company will go through a joint cloud review etc. when it involves PII.

1 Like

Good Morning @stephenb

Thanks for your answer, I saw in this information, that talk about Elastic Cloud. Do you have any information, about Elastic OnPremise ?

Thanks again.

I think that this post is still accurate: How should I encrypt data at rest with Elasticsearch?

For "Self Managed"

Well of course then all the host, network, disk, organization etc. Security is up to You.

The CVE Program still applies.

And if you engage in a commercial relationship you will have support and can get Professional Services to help with your Architecture, Design and Implementation

Some of the Security features of Elasticsearch are Commercial Licensed only
A couple examples are : SSO / SAML, Field Level Security etc

You can look at all the features vs license here

Then, the actual Elasticsearch product / technical features (which are quite extensive) you will need to take a look at out docs about Securing Your Cluster.