Caution
Grafana Agent has reached End-of-Life (EOL) on November 1, 2025. Agent is no longer receiving vendor support and will no longer receive security or bug fixes. Current users of Agent Static mode, Agent Flow mode, and Agent Operator should proceed with migrating to Grafana Alloy. If you have already migrated to Alloy, no further action is required. Read more about why we recommend migrating to Grafana Alloy.
remote.kubernetes.secret
remote.kubernetes.secret reads a Secret from the Kubernetes API server and exposes its data for other components to consume.
A common use case for this is loading credentials or other information from secrets that are not already mounted into the Grafana Agent pod at deployment time.
Usage
remote.kubernetes.secret "LABEL" {
namespace = "NAMESPACE_OF_SECRET"
name = "NAME_OF_SECRET"
}Arguments
The following arguments are supported:
When this component performs a poll operation, it requests the Secret data from the Kubernetes API. A poll is triggered by the following:
- When the component first loads.
- Every time the component’s arguments get re-evaluated.
- At the frequency specified by the
poll_frequencyargument.
Any error while polling will mark the component as unhealthy. After a successful poll, all data is exported with the same field names as the source Secret.
Blocks
The following blocks are supported inside the definition of remote.kubernetes.secret:
The > symbol indicates deeper levels of nesting. For example, client > basic_auth
refers to a basic_auth block defined inside a client block.
client block
The client block configures the Kubernetes client used to discover Probes. If the client block isn’t provided, the default in-cluster
configuration with the service account of the running Grafana Agent pod is used.
The following arguments are supported:
At most, one of the following can be provided:
no_proxy can contain IPs, CIDR notations, and domain names. IP and domain
names can contain port numbers. proxy_url must be configured if no_proxy
is configured.
proxy_from_environment uses the environment variables HTTP_PROXY, HTTPS_PROXY
and NO_PROXY (or the lowercase versions thereof). Requests use the proxy from
the environment variable matching their scheme, unless excluded by NO_PROXY.
proxy_url and no_proxy must not be configured if proxy_from_environment
is configured.
proxy_connect_header should only be configured if proxy_url or proxy_from_environment are configured.
basic_auth block
password and password_file are mutually exclusive, and only one can be provided inside a basic_auth block.
authorization block
credential and credentials_file are mutually exclusive, and only one can be provided inside an authorization block.