- Fleet and Elastic Agent Guide: other versions:
- Fleet and Elastic Agent overview
- Beats and Elastic Agent capabilities
- Quick starts
- Migrate from Beats to Elastic Agent
- Deployment models
- Install Elastic Agents
- Install Fleet-managed Elastic Agents
- Install standalone Elastic Agents (advanced users)
- Install Elastic Agents in a containerized environment
- Run Elastic Agent in a container
- Run Elastic Agent on Kubernetes managed by Fleet
- Advanced Elastic Agent configuration managed by Fleet
- Run Elastic Agent on GKE managed by Fleet
- Run Elastic Agent on Amazon EKS managed by Fleet
- Run Elastic Agent on Azure AKS managed by Fleet
- Run Elastic Agent Standalone on Kubernetes
- Scaling Elastic Agent on Kubernetes
- Using a custom ingest pipeline with the Kubernetes Integration
- Environment variables
- Installation layout
- Air-gapped environments
- Using a proxy server with Elastic Agent and Fleet
- Uninstall Elastic Agents from edge hosts
- Start and stop Elastic Agents on edge hosts
- Elastic Agent configuration encryption
- Secure connections
- Manage Elastic Agents in Fleet
- Configure standalone Elastic Agents
- Create a standalone Elastic Agent policy
- Structure of a config file
- Inputs
- Providers
- Outputs
- SSL/TLS
- Logging
- Feature flags
- Agent download
- Config file examples
- Grant standalone Elastic Agents access to Elasticsearch
- Example: Use standalone Elastic Agent with Elastic Cloud Serverless to monitor nginx
- Example: Use standalone Elastic Agent with Elasticsearch Service to monitor nginx
- Debug standalone Elastic Agents
- Kubernetes autodiscovery with Elastic Agent
- Monitoring
- Reference YAML
- Manage integrations
- Define processors
- Processor syntax
- add_cloud_metadata
- add_cloudfoundry_metadata
- add_docker_metadata
- add_fields
- add_host_metadata
- add_id
- add_kubernetes_metadata
- add_labels
- add_locale
- add_network_direction
- add_nomad_metadata
- add_observer_metadata
- add_process_metadata
- add_tags
- community_id
- convert
- copy_fields
- decode_base64_field
- decode_cef
- decode_csv_fields
- decode_duration
- decode_json_fields
- decode_xml
- decode_xml_wineventlog
- decompress_gzip_field
- detect_mime_type
- dissect
- dns
- drop_event
- drop_fields
- extract_array
- fingerprint
- include_fields
- move_fields
- parse_aws_vpc_flow_log
- rate_limit
- registered_domain
- rename
- replace
- script
- syslog
- timestamp
- translate_sid
- truncate_fields
- urldecode
- Command reference
- Troubleshoot
- Release notes
Package signatures
editPackage signatures
editAll integration packages published by Elastic have package signatures that prevent malicious attackers from tampering with package content. When you install an Elastic integration, Kibana downloads the package and verifies the package signature against a public key. If the package is unverified, you can choose to force install it. However, it’s strongly recommended that you avoid installing unverified packages.
By installing an unverified package, you acknowledge that you assume any risk involved.
To force installation of an unverified package:
- When using the Integrations UI, you’ll be prompted to confirm that you want to install the unverified integration. Click Install anyway to force installation.
-
When using the Fleet API, if you attempt to install an unverified package,
you’ll see a 400 response code with a verification failed message. To force
installation, set the URL parameter
ignoreUnverified=true
. For more information, refer to Kibana Fleet APIs.
After installation, unverified Integrations are flagged on the Installed integrations tab of the Integrations UI.
Why is package verification necessary?
editIntegration packages contain instructions, such as ILM policies, transforms, and mappings, that can significantly modify the structure of your Elasticsearch indices. Relying solely on HTTPS DNS name validation to prove provenance of the package is not a safe practice. A determined attacker could forge a certificate and serve up packages intended to disrupt the target.
Installing verified packages ensures that your integration software has not been corrupted or otherwise tampered with.
What does it mean for a package to be unverified?
editHere are some situations where an integration package will fail verification during installation:
- The package zip file on the Elastic server has been tampered with.
- The user has been maliciously redirected to a fake Elastic package registry.
- The public Elastic key has been compromised, and Elastic has signed packages with an updated key.
Here are some reasons why an integration might be flagged as unverified after installation:
- The integration package failed verification, but was force installed.
- The integration package was installed before Fleet added support for package signature verification.
What if the Elastic key changes in the future?
editIn the unlikely event that the Elastic signing key changes in the future, any
verified integration packages will continue to show as verified until new
packages are installed or existing ones are upgraded. If this happens, you can
set the xpack.fleet.packageVerification.gpgKeyPath
setting in the kibana.yml
configuration file to use the new key.
On this page