Kapitlet Sikkerhed og adgang beskriver, hvordan vores teknikere får adgang til dine systemer. Dette kapitel handler om det, platformene selv gør: KubeAid på Kubernetes-clustere og LinuxAid på Linux-servere. Alle kontroller herunder er sat op i Git, og hvor en kontrol er et tilvalg frem for slået til som standard, skriver vi det.
Hvert cloud- og bare metal-cluster, kubeaid-cli bygger, kører Cilium. kubeaid-addons-chartet kan rendere en default-deny CiliumNetworkPolicy pr. namespace, som slår indgående og udgående trafik fra for alle pods i det, bortset fra DNS til kube-dns. Har en workload brug for mere, angiver du, hvilke pods der får det. Cilium eksporterer hver droppet pakke som en Hubble-metrik.
På bare metal kan du slå Ciliums host-firewall til. Den begrænser, hvad noderne selv svarer på, og SSH udefra tager så kun imod forbindelser fra de kilder, du angiver i values-cilium.yaml. På Hetzner bare metal tilbyder kubeaid-cli at slå den til, når clusteret er bygget. På AWS og Azure klarer udbyderens security groups den opgave, og på cloud-clustere er host-firewallen slået fra.
KubeAid leverer to runtime-motorer, som er slået fra, indtil du slår én til for et cluster. Tetragon registrerer procesafvikling, indlæsning af kernemoduler og ændringer af rettigheder som kernehændelser via eBPF og følger netværks- og filadgang, når du tilføjer en politik til det. KubeArmor kan afvise en operation ved Linux Security Module-hooket, før den kører.
Når du slår sårbarhedsscanning til, scanner Trivy Operator de images, dine workloads kører, og gemmer de kritiske og høje fund, der kan rettes, som rapportobjekter i clusteret. Kubescape kan tage dens plads. Hemmeligheder ligger krypteret i clusterets Git-repository, forseglet til nøglen for det cluster, der må åbne dem, og kun controlleren inde i det cluster kan dekryptere dem. kubeaid-cli installerer controlleren, mens den bygger clusteret.
En NetworkPolicy, hvis selector ikke matcher noget, ser beskyttet ud i Git og lader poden stå åben. Derfor læser KubeAid, hvor du slår det til, det, Cilium har beregnet for hver pod, og rapporterer pr. workload:
Har Cilium ikke udfyldt endpoint-status, er svaret null, altså ukendt. Opsamleren opretter og ændrer ingenting. Hvor dit cluster rapporterer til Obmondo, sender det øjebliksbilledet over mTLS med navnene på dine workloads, deres images og fundene i dem, men ingen applikationsdata, logs eller indhold fra hemmeligheder.
Én gang i timen tjekker en OpenVox-agent på hver server, om serveren stemmer overens med sine indstillinger i Git, og rapporterer afvigelser. Installationen sætter agenten til kun at rapportere. Håndhævelse er en kontakt pr. klasse, og kørslen hver time retter de klasser, hvor den er slået til, plus nogle få filer, som LinuxAid altid holder på plads, f.eks. SSH-serverens konfiguration. Firewall-, database- og webindstillingerne har ingen sådan kontakt. De træder først i kraft, når nogen kører linuxaid-cli run-openvox --enforce.
På en fuldt driftet server skriver kørslen hver time en hærdet SSH-konfiguration, også mens LinuxAid kun rapporterer om resten, og SSH bruger den fra næste genstart:
Du kan tilføje et NetBird- eller WireGuard-VPN for at nå dine servere over et privat netværk.
Når firewallen er slået til, sætter hver håndhævende kørsel serverens iptables-regler for IPv4 ud fra Git:
Brugerkonti, grupper, SSH-nøgler og sudo-rettigheder for hver server ligger i Git sammen med hashede adgangskoder og udløbsdatoer. LinuxAid rapporterer SSH-nøgler, der ikke står i Git, og når den håndhæver, fjerner den dem fra de konti, den styrer, og fra root. pam_access kan begrænse, hvem der må logge ind og hvorfra.
Hver server sender sine målinger hvert 15. sekund over TLS til Obmondos Prometheus og identificerer sig med sit OpenVox-certifikat.
Sikkerhedstekster lyder tit, som om alle kontakter allerede var slået til. Her er, hvor vores ikke er.