Network Access¶
Tenant-Isolation, Control-Plane-Whitelist, Cilium LoadBalancer/BGP, Egress und VPN. Block: ayedo/k8s/cilium. Siehe Cilium.
Tenant-Isolation¶
Was die Plattform typischerweise garantiert (konkrete Edition/Vertrag beachten):
- Namespace-Trennung plus Kubernetes RBAC — kein Cross-Tenant-Zugriff auf API-Objekte anderer Tenants
- Network Policies (Cilium) — Standard-Muster: restriktiver East-West-Traffic; Cross-Namespace nur explizit erlaubt
- eigene Cluster (Dedicated / separater Workspace) — stärkere Isolation als Shared-Namespace-Modelle
Nicht automatisch enthalten: beliebiges „Flat Network“ zu On-Prem ohne vereinbarte VPN-/Peering-Strecke.
Control-Plane (kube-apiserver) IP-Whitelist¶
Öffentlicher API-Endpunkt kann auf kundenbezogene Quell-IPs eingeschränkt werden (Firewall / Load-Balancer / Cloud Security Group — je nach Betriebsmodell).
Prozess (Kunden):
- Feste Egress-/Office-/Bastion-IPs (oder CIDRs) sammeln
- Änderung über Support / vereinbarten Channel beauftragen
- ayedo setzt Whitelist um und bestätigt das Fenster
- Kunde verifiziert:
kubectl cluster-info/ Login von erlaubter und (kurz) unerlaubter Quelle
Break-Glass
Ohne erlaubte IP ist der API-Zugriff blockiert. Plane mindestens zwei unabhängige erlaubte Quellen (z. B. Office + Jump Host) und dokumentiere den Break-Glass-Pfad intern.
OIDC/RBAC bleibt parallel gültig — Whitelist ersetzt keine Authentifizierung. Details: Access Control.
k3s-server: api_access.whitelist_cidrs am Block bzw. Controlplane-Objekt — k3s-server.
Cilium LoadBalancer und BGP¶
Cilium kann kube-proxy ersetzen und Services vom Typ LoadBalancer bedienen. Block-Schalter (Auszug):
| Config | Bedeutung |
|---|---|
kube_proxy_replacement | eBPF-LB statt kube-proxy |
loadbalancer_algorithm | Default maglev |
loadbalancer_mode | snat (Default) / DSR je nach Setup |
l2announcements | L2/ARP-Announcement der VIP im lokalen Segment |
bgp_controlplane | BGP Control Plane — VIPs an ToR/Upstream announcen |
gateway_api | Cilium als Gateway-API-Implementierung (optional; SDP-Standard ist Envoy) |
hubble | Flow-Observability |
Typische Muster:
- L2 announcements — Lab, einzelnes L2, keine BGP-Peers
- BGP Control Plane — Foundation/Production: Cilium peered mit Switches, advertised
LoadBalancer-IPs (Ingress/Gateway-VIP, k3s-server dedicated LB) - k3s-server
loadbalancer.provider: ciliumsetzt die passenden Service-Annotations
IP-Pools und BGP-Peers sind Cluster-Config (Cilium CRDs / Block-Values), nicht App-YAML. Apps deklarieren Service type: LoadBalancer oder nutzen Ingress/Gateway, das auf einer Cilium-VIP hängt.
Upstream: Cilium LB-IPAM · Cilium BGP.
Egress und stabile ausgehende IPs¶
Pods verlassen das Cluster über Node-/CNI-Pfade. Für Allowlists bei Drittsystemen (SaaS, Partner-Firewalls) brauchen Kunden oft stabile Source-IPs.
| Option | Beschreibung | IP-Stabilität |
|---|---|---|
| Node-Egress (Default) | Traffic über die öffentliche/NAT-Adresse der Node | ändert sich bei Node-Replace/Scale |
| Cilium Egress Gateway | ausgewählte Pods/Namespaces über dedizierte Egress-Nodes | stabil, solange Gateway-Nodes und deren IPs festgehalten werden |
| dedizierte Egress-Nodes | Nodes mit fester öffentlicher IP, nur für ausgehenden Traffic | hoch, wenn IP nicht rotiert |
Kein AWS-NAT-Gateway-Äquivalent
Auf Hetzner und vergleichbaren Providern gibt es kein 1:1-Produkt zu „Managed NAT Gateway mit Elastic IP“ wie bei AWS. Stabile Egress-IPs sind ein plattformseitig konfiguriertes Muster (Egress Gateway / feste Nodes), kein Cloud-SKU-Button.
Bei Node-Rotation ohne Egress-Gateway müssen externe Allowlists aktualisiert werden — das ist erwartetes Verhalten, kein Incident.
VPN¶
Unterstützte Standardoption für Site-to-Site / Client-Zugriff in den Cluster- bzw. Tenant-Netzkontext:
- WireGuard — übliche, unterstützte VPN-Technologie
Weitere VPN-Stacks (IPsec, herstellerspezifische Appliances, SD-WAN) nur nach expliziter Vereinbarung und Architekturfreigabe.
WireGuard dient der Connectivity — nicht als Ersatz für Kubernetes RBAC oder Network Policies.
Multi-Tenancy FAQ (Business)¶
Geschäftliche Fragen zu Isolation und Shared Responsibility: ayedo FAQ (Multi-Tenancy / Hosting). Compliance-Controls: Network Security (Portal).
Checkliste für Kundenprojekte¶
- Erlaubte Control-Plane-Quell-IPs definiert und beauftragt
- Benötigte stabile Egress-IPs benannt (Dienste + CIDRs)
- VPN-Bedarf (WireGuard vs. Sonderlösung) geklärt
- NetworkPolicies für App-Namespaces abgestimmt
- Monitoring/Allowlist-Änderungen bei Node-Lifecycle eingeplant