Keine statischen Passwörter mehr zwischen den Diensten

Denken Sie darüber nach, wie Ihre Dienste sich gegenseitig und in der Cloud authentifizieren. In vielen Unternehmen ist die Antwort statische Anmeldeinformationen. Ein Zugangsschlüssel in einer Umgebungsvariablen. Ein geteiltes API-Token in einer Konfigurationsdatei. Ein Datenbankpasswort, das an fünf Orte kopiert wurde. Sie werden selten gedreht, und wenn eine undicht ist, weiß man oft nicht, wo sie sonst noch verwendet wird.

Menschen haben das vor einiger Zeit überwunden: Einfach-Anmeldevorgang, MFA, kurzlebige Sitzungen. Arbeitsaufwand verdient das Gleiche.

Das Problem mit gemeinsamen Geheimnissen

Statische Anmeldeinformationen haben drei große Schwächen:

• Sie sind langlebig. Ein durchgesickter Schlüssel funktioniert, bis jemand ihn bemerkt und dreht, was Monate dauern kann.
• Sie sind kopierbar. Jeder oder alles, was den Schlüssel bekommt, kann ihn von überall aus benutzen.
• Sie sagen nicht, wer anruft. Fünf Dienste, die ein Token teilen, sehen in den Protokollen identisch aus.

Null Vertrauen ist die Idee, dass man nichts vertrauen sollte, nur weil es in deinem Netzwerk ist. Jede Anfrage sollte beweisen, von wem sie kommt. Für Workloads bedeutet das, jedem Service eine starke, überprüfbare Identität zu geben.

Identität der Cloud-Arbeitsauflast

Der einfachste Gewinn: Lassen Sie Ihre Workloads mit ihren Plattformidentitäten anstelle von Schlüsseln an Cloud-Dienste authentifizieren.

Auf Kubernetes läuft jede Kapsel mit einem Dienstleistungskonto- Ich weiß . Cloud-Anbieter können Kubernetes-Service-Konto-Token vertrauen und gegen kurzlebige Cloud-Anmeldeinformationen tauschen:

• AWS: IAM-Rollen für Dienstleistungskonten (IRSA) oder die neuere Version Identität der EKS-Kapsel.
• Google Cloud wird: Workload Identity Federation für die GKE.
• Blau: Microsoft-Eingabe-Arbeitslast-ID.

Die Einrichtung: Verknüpfen Sie ein Kubernetes-Dienstkonto mit einer Cloud-Rolle. Pods, die dieses Dienstkonto verwenden, erhalten automatisch temporäre Anmeldeinformationen, die für sie rotiert werden, die dem Rollen zugeordnet sind. Kein Geheimnis zu speichern, nichts, das lange durchsickern kann.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: orders
  namespace: shop
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/shop-orders

Die gleiche Idee funktioniert in CI: OIDC-Föderation GitHub Actions, GitLab CI und andere können Cloud-Zugriffsdaten ohne gespeicherte Schlüssel erhalten.

Die sicherste Anmeldeurkunde ist die, die für ein paar Minuten, für eine Arbeitslast, für einen Job ausgestellt wird, und dann einfach abläuft.

SPIFFE, einfach gesagt

Cloud-Workload-Identität löst "meine Kapsel spricht mit meinem Cloud-Anbieter". Aber was ist mit Service-to-Service-Anrufen, über Cluster, Clouds und lokale Maschinen hinweg?

SPIFFE (Secure Production Identity Framework For Everyone) ist ein CNCF-Standard für die Workload-Identität, unabhängig von jeder Plattform. Es definiert:

• SPIFFE-ID: ein eindeutiger Name für eine Arbeitslast, geschrieben als URI, wie spiffe://acme.com/ns/shop/sa/orders.
• SVID (SPIFFE Verifiable Identity Document): ein kurzlebiges Dokument, das diese Identität Zertifikat X.509 oder JWT.
• Arbeitslast API: eine lokale API, wo Workloads ihre SVIDs abrufen, ohne dass zu Beginn ein Geheimnis benötigt wird.

SPIRE ist die Referenzimplementierung. Ein SPIRE-Server gibt Identitäten und Agenten an jedem Knoten aus Bescheinigung Arbeitslasten: Sie überprüfen, welche Arbeitslast tatsächlich vorhanden ist (welches Kubernetes-Dienstkonto, welcher Knoten, welcher Prozess), bevor sie eine Identität austeilen. Die Zertifikate werden automatisch, oft stündlich, umgeschaltet.

Viele Tools sprechen SPIFFE: Service-Meshes wie Istio und Linkerd verwenden intern SPIFFE-ähnliche Identitäten, und Envoy, Cilium und verschiedene Datenbanken und Proxies können SVIDs verwenden.

MTLS zwischen Diensten

Die Identität der Benutzer ist gegenseitige TLS (mTLS)Beide Seiten präsentieren Zertifikate, so dass jeder genau weiß, mit wem er spricht, und der Verkehr verschlüsselt ist.

MTLS in jeder Anwendung von Hand zu machen, ist schmerzhaft. Deshalb wird es meistens von:

• Ein Service-Mesh (Istio, Linkerd, Cilium), die automatisch mTLS zwischen allen Diensten hinzufügt.
• SPIFFE-Bibliotheken (go-spiffe und andere) für Anwendungen, die selbst mit dem

Auf der Oberseite von mTLS, können Sie schreiben Genehmigungsrichtlinien: "nur die checkout Der Dienst kann anrufen payments auf /charge"Ich bin ein Mann. Das ist echtes Nullvertrauen: Identitätsbasierter Zugriff, nicht netzwerkbasierter.

Wo soll ich anfangen?

Du brauchst SPIRE nicht am ersten Tag. Ein praktischer Weg:

1. Schlüssel zum Zugriff auf die Cloud ersetzen in Kubernetes mit der Workload-Identität Ihres Providers.
2. IC-Cloud-Tasten ersetzen mit der OIDC-Föderation.
3. - Bewegen Sie die verbleibenden Geheimnisse . in einen geheimen Manager mit kurzlebigen oder wechselnden Anmeldeinformationen.
4. MTLS zwischen Diensten hinzufügen, am einfachsten durch ein Service-Gitter.
5. Die Kommission hat die Kommission aufgefordert, Wenn Sie ein Identitätssystem über Cluster, Clouds und virtuelle Maschinen benötigen.

Ist es also die Mühe wert?

- Ja, das ist es. Das Entfernen statischer Anmeldeinformationen beseitigt eine der häufigsten Ursachen für Sicherheitsverletzungen. Die ersten Schritte, die Cloud-Workload-Identität und CI OIDC, sind überraschend einfach und bringen sofortigen Nutzen.

Meine Meinung: Dienste sollten immer beweisen, wer sie sind, mit Anmeldeinformationen, die ablaufen, bevor sie missbraucht werden können. Passwörter sind für Menschen, und selbst wir geben sie auf.

Desly