Skip to main content
protocols.pageprotocols.page
2379

Port 2379 – etcd

TCP

Port 2379 is the etcd client API port – the distributed key-value store used as Kubernetes' backing datastore. etcd also uses port 2380 for peer-to-peer cluster communication. Whoever controls etcd controls the entire Kubernetes cluster – all secrets, configs, and workload definitions are stored here. etcd must use TLS and never be exposed outside cluster networks.

Port Number

2379

Protocol

TCP

Service

etcd Client API

Range

IANA Registered (1024–49151)

Description

etcd stores all Kubernetes cluster state: Secrets (including TLS private keys), ConfigMaps, deployments, service accounts, and RBAC rules. Port 2379 serves the v3 gRPC API and HTTP/JSON gateway. Port 2380 is for etcd peer communication during leader election and log replication. In managed Kubernetes (EKS, GKE, AKS), etcd is not directly accessible to users. In self-hosted clusters, etcd TLS and IP allowlisting are critical.

Security risks

  • 1Full cluster compromise: etcd contains ALL Kubernetes secrets in plaintext (base64-encoded, not encrypted by default). An attacker with etcd access reads every TLS certificate, database password, and API key in the cluster. Enable encryption at rest (--encryption-provider-config) and restrict port 2379 to kube-apiserver IPs only.
  • 2No authentication by default: etcd without --client-cert-auth accepts anonymous connections. Any host reaching port 2379 has full read/write access to all cluster state. Always require client TLS certificates for port 2379.
  • 3Snapshot theft: etcdctl snapshot save creates a full dump of all cluster data. An attacker with port 2379 access can snapshot the entire cluster state and extract secrets offline at leisure.
  • 4Write access = cluster takeover: writing to etcd bypasses all Kubernetes RBAC. An attacker can create cluster-admin ServiceAccounts, modify Deployments to inject containers, or delete critical workloads directly.

Firewall guidance

Port 2379 must be accessible ONLY from kube-apiserver nodes – nothing else. In production Kubernetes, etcd runs on dedicated nodes with firewall rules allowing only apiserver IPs on port 2379 and peer etcd nodes on port 2380. No application pods, no worker nodes, no admin workstations should reach port 2379 directly. Use kubectl (via apiserver on 6443) for all operations.

Diagnosis commands

Check etcd cluster health with TLS

shell
ETCDCTL_API=3 etcdctl --endpoints=https://host:2379 --cacert=ca.crt --cert=etcd.crt --key=etcd.key endpoint health

Show cluster member status, leader, DB size

shell
ETCDCTL_API=3 etcdctl --endpoints=https://host:2379 endpoint status --cluster -w table

HTTP health check (should return {"health":"true"})

shell
curl -s https://host:2379/health --cacert ca.crt --cert client.crt --key client.key

Usage examples

Port 2379 – etcd
shell
etcdctl --endpoints=localhost:2379 get /registry/secrets/default/ --prefix
curl http://localhost:2379/health
ETCDCTL_API=3 etcdctl endpoint status --cluster

Common services on this port

etcd (CoreOS/Red Hat)Kubernetes control planePatroni (PostgreSQL HA)Consul (alternative)Rook/Ceph (uses etcd)

Related ports

2380

etcd peer communication

6443

Kubernetes API server

10250

Kubelet API

History

etcd was created by CoreOS in 2013 for their distributed Linux operating system (Container Linux). It uses Raft consensus for strong consistency. Kubernetes chose etcd as its backing store in 2014. CoreOS was acquired by Red Hat (2018), then IBM. etcd became a CNCF graduated project in 2018.

FAQ

Can I access etcd directly in EKS/GKE/AKS?

No. Managed Kubernetes services hide etcd entirely – you cannot access port 2379 or the etcd data directly. All interactions go through the Kubernetes API (port 6443). This is by design: the cloud provider manages etcd backups, encryption, and HA.

How do I backup etcd?

etcdctl snapshot save /backup/etcd-$(date +%Y%m%d).db --endpoints=https://127.0.0.1:2379 --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/server.crt --key=/etc/kubernetes/pki/etcd/server.key. Store snapshots encrypted and off-cluster. Test restore regularly.