-
Threat: Unauthorized Data Access via Client API
- Description: An attacker gains unauthorized access to the etcd client API (typically port 2379) and issues read requests (e.g.,
get
,range
) to retrieve sensitive data. This leverages weaknesses within etcd's authentication or authorization mechanisms or exploits vulnerabilities in the API handling. - Impact: Exposure of sensitive configuration data, service discovery information, secrets, leading to further compromise.
- Affected etcd Component:
etcdserver/api/v3rpc
(gRPC server handling client requests),auth
module (if authentication is bypassed or flawed). - Risk Severity: Critical
- Mitigation Strategies:
- Enable TLS with Mutual Authentication (mTLS): Enforce client certificate verification within etcd.
- Implement RBAC: Use etcd's RBAC to restrict client access to only necessary keys/prefixes. Regularly audit RBAC rules.
- Audit Logging: Enable and regularly review etcd's audit logs for unauthorized access.
- Description: An attacker gains unauthorized access to the etcd client API (typically port 2379) and issues read requests (e.g.,
-
Threat: Data Modification/Deletion via Client API
- Description: An attacker gains unauthorized access to the etcd client API and issues write requests (e.g.,
put
,delete
,txn
) to modify or delete data. This exploits vulnerabilities in etcd's authorization, input validation, or transaction handling. - Impact: Disruption of application functionality, service outages, data loss, potential for complete system compromise.
- Affected etcd Component:
etcdserver/api/v3rpc
(gRPC server),auth
module,mvcc
(Multi-Version Concurrency Control) module. - Risk Severity: Critical
- Mitigation Strategies:
- Strong Authentication and Authorization (RBAC): Use mTLS and granular RBAC within etcd to strictly control write access.
- Input Validation (within etcd client libraries): While primarily a client-side concern, etcd client libraries should perform basic validation to prevent obviously malformed requests.
- Transaction Limits: Use etcd's transaction features correctly; avoid overly large or complex transactions that could be exploited.
- Description: An attacker gains unauthorized access to the etcd client API and issues write requests (e.g.,
-
Threat: Denial of Service via Excessive Key-Value Operations
- Description: An attacker floods the etcd cluster with read/write requests, exceeding etcd's capacity and causing it to become unresponsive. This targets vulnerabilities in etcd's request handling, resource management, or the Raft consensus algorithm.
- Impact: Denial of service for all applications relying on etcd.
- Affected etcd Component:
etcdserver/api/v3rpc
(gRPC server),mvcc
module,raft
module. - Risk Severity: High
- Mitigation Strategies:
- Rate Limiting (within etcd): Utilize etcd's built-in rate limiting features to protect against request floods.
- Connection Limits (within etcd): Configure etcd to limit the number of concurrent connections.
- Resource Limits (within etcd): Configure appropriate resource limits (CPU, memory) for the etcd process itself.
- Request Timeouts (within etcd): Ensure etcd has appropriate timeouts configured to prevent slow clients from consuming resources.
-
Threat: Denial of Service via Lease Exhaustion
- Description: An attacker creates many leases with short TTLs, exhausting etcd's lease ID space and preventing legitimate clients from creating leases. This targets the
lease
module specifically. - Impact: Disruption of services relying on leases (leader election, ephemeral data).
- Affected etcd Component:
lease
module. - Risk Severity: High
- Mitigation Strategies:
- Limit Maximum Lease TTL (within etcd): Configure a reasonable maximum TTL within etcd to prevent abuse.
- Monitor Lease Usage (and alert on anomalies): Track lease creation rates and alert on suspicious activity.
- Rate Limiting (on lease creation, within etcd): Implement rate limiting specifically for lease creation requests within etcd.
- Description: An attacker creates many leases with short TTLs, exhausting etcd's lease ID space and preventing legitimate clients from creating leases. This targets the
-
Threat: Compromise of etcd Peer Communication
- Description: An attacker intercepts/modifies communication between etcd cluster members, exploiting vulnerabilities in the Raft communication protocol or its implementation. This could involve injecting false data or disrupting quorum.
- Impact: Loss of data consistency, split-brain, cluster instability, data corruption/loss.
- Affected etcd Component:
etcdserver/api/rafthttp
(Raft communication),raft
module. - Risk Severity: High
- Mitigation Strategies:
- Enable TLS for Peer Communication (within etcd): Configure etcd to use TLS for all inter-member communication. Use strong cipher suites.
-
Threat: Exploitation of etcd Vulnerabilities
- Description: An attacker exploits a known or zero-day vulnerability in the etcd software itself (e.g., buffer overflow, code injection) to gain unauthorized access, execute code, or cause a DoS.
- Impact: Varies; could range from data exposure to complete cluster compromise.
- Affected etcd Component: Potentially any component, depending on the vulnerability.
- Risk Severity: Critical (for exploitable vulnerabilities)
- Mitigation Strategies:
- Keep etcd Up-to-Date: Regularly update etcd to the latest stable release. This is the primary defense.
- Monitor Security Advisories: Stay informed about new etcd vulnerabilities.
- Vulnerability Scanning (of the etcd binary): Use tools to scan the etcd binary for known vulnerabilities.
-
Threat: Improper Cluster Membership Changes Leading to Split Brain
- Description: An operator incorrectly adds or removes nodes, violating quorum or causing partitions, leading to a "split-brain" where multiple inconsistent clusters form. This is a direct operational error interacting with etcd's core functionality.
- Impact: Data inconsistency, data loss, cluster unavailability.
- Affected etcd Component:
raft
module,etcdserver/api/membership
. - Risk Severity: High
- Mitigation Strategies:
- Strictly Adhere to etcd Documentation: Follow official procedures for membership changes.
- Use
etcdctl
for Membership Changes: Use theetcdctl
commands; avoid manual configuration edits. - Monitor Cluster Health: Closely monitor health during and after changes.