Technologie-Notizen

OpenTelemetry zeichnet Ausführungskontext auf und gibt ihn weiter: welche Aufrufe eine Anfrage ausgelöst hat, wie lange sie dauerten, wo sie scheiterten. Es ist darauf ausgelegt, auf dem Weg zu einem Backend gesampelt, gefiltert und transformiert zu werden, und ein Trace, der nicht gesampelt wird, wird nicht exportiert; der Filter-Processor des Collectors verwirft passende Telemetrie per Konfiguration. Seine Identität ist eine einzelne Ausführung, getragen im W3C-Header traceparent. Eine Prüfspur beantwortet eine andere Frage über eine andere Einheit: was mit einem Geschäftsvorgang geschehen ist, wer gehandelt hat und gestützt auf welche Nachweise, vollständig und ohne nachträgliche Änderungen.

• Prüfspureinträge werden nie gesampelt, gefiltert oder durch eine Telemetrie-Pipeline geleitet.
• Beides wird korreliert: Die trace_id der Prüfspur wird als Attribut auf Spans festgehalten. Ein Identifikator verteilter Traces wird nicht als Identität der Prüfspur wiederverwendet.
• Was zur Korrelation dient, wird klassifiziert. Ein Span-Attribut verlässt den Speicher der Prüfspur in Richtung Exporter, Anbieter und einer eigenen Aufbewahrung: eine opake Referenz, niemals personenbezogene Daten oder ein Geheimnis.
• Zu erwarten ist, dass sich ein Geschäftsvorgang über mehrere verteilte Traces erstreckt: die Aufnahmeanfrage, einen asynchronen Job, eine Entscheidung, die Tage später fällt.

Open Policy Agent wertet Regeln, die jemand geschrieben hat, gegen Eingaben aus, die jemand geliefert hat. Es entkoppelt die Entscheidung von ihrer Durchsetzung, und genau das macht Regeln als Daten handhabbar. Es weiß nicht, was eine Rechtsvorschrift verlangt, und eine in Rego geschriebene Regel ist genau so richtig wie die Lesart des Textes, den sie abbildet. Die Antwort der Engine belegt, dass eine Regel angewendet wurde, niemals, dass die Regel richtig war.

• Jede Regel braucht eine verantwortliche Person, eine Quelle und eine Prüfung, wie jede andere Auslegung eines Textes.
• Mit jeder Entscheidung wird die Revision festgehalten, damit sich eine spätere Korrektur der Regel von den Entscheidungen unterscheiden lässt, die unter der alten getroffen wurden.
• Eine bestandene Testsuite für eine Policy belegt, dass sich die Regel so verhält, wie ihr Autor es beabsichtigt hat, und nichts darüber, ob der Autor den Text richtig gelesen hat.

Admission Control fängt Anfragen an den Kubernetes-API-Server nach Authentifizierung und Autorisierung ab, bevor das Objekt persistiert wird. Sie sieht Deployments, Pods und ConfigMaps, und Anfragen, die diese nur lesen, umgehen sie vollständig. Sie sieht nie die HTTP-Anfragen, die ein Dienst bearbeitet, die Nachrichten, die er konsumiert, oder die Antworten, die ein Modell liefert. Sie beurteilt Anfragen, wenn sie eintreffen, was Kubernetes für ein Admission-Plugin ausdrücklich festhält: Wird eine LimitRange hinzugefügt, bleiben die bereits bestehenden Pods unverändert.

• Admission dient Eigenschaften von Workloads: per Digest fixierte Images, benannte Revisionen, fehlende Zugangsdaten dort, wo sie fehlen müssen.
• Die Validierung an der Grenze bleibt in der Anwendung, an jedem ihrer Eintrittspunkte.
• Bestehende Objekte werden gesondert auditiert, wie es das Audit von Gatekeeper tut; Admission sieht immer nur Änderungen.

Event Sourcing macht ein Append-only-Protokoll von Ereignissen zum führenden System und leitet den Zustand daraus ab. Das ergibt konstruktionsbedingt eine vollständige Historie, zu einem erheblichen Preis: Jedes Lesemodell ist eine Projektion, und jede Änderung an der Struktur eines Ereignisses ist eine Migration der Historie. Eine Append-only-Prüfspur neben gewöhnlichem Zustand liefert, was COADF P-4 verlangt (eine Historie, die ergänzt und nie umgeschrieben wird und sich mit einer Abfrage rekonstruieren lässt), ohne zu ändern, wie der Rest des Systems seinen Zustand hält. Berechtigungen pro Operation und ablehnende Trigger genügen, um eine solche Spur in PostgreSQL aufzubauen.

• Event Sourcing wird aus Gründen der Domäne gewählt, nicht um eine Prüfspur zu erhalten.
• Eine Append-only-Tabelle mit einer Rolle, die nur einfügen darf, ablehnenden Triggern und idempotenten Schreibvorgängen verwirklicht Append-only-Nachweise ohne Event Sourcing, innerhalb der eigenen Vertrauensgrenze der Datenbank.
• In beiden Fällen wird der Eintrag in derselben Transaktion geschrieben wie die Änderung, die er festhält.

Die probabilistische Grenze ist eine Eigenschaft von Codepfaden: Kein Pfad lässt eine Modellausgabe ohne einen expliziten, festgehaltenen Schritt zu einem maßgeblichen Objekt werden. Eine Modulgrenze, die der Build durchsetzt, hält diese Eigenschaft innerhalb eines Prozesses, mit Import-Verträgen in Python oder Architekturregeln als Unit-Tests in Java. Eine Netzwerkgrenze ergänzt eine Durchsetzung durch die Infrastruktur und bringt Vertragsversionierung, Teilausfälle, Wiederholungen und Kontextweitergabe über mehrere Hops mit sich, also neue Stellen, an denen die Eigenschaft verloren gehen kann.

• Die probabilistische Komponente wird getrennt deployt, wenn Skalierung, die Isolierung einer Anbieterbibliothek oder unabhängige Releases es verlangen, nicht weil ein Prinzip es verlangt.
• In beiden Fällen wird die Modulgrenze mit einem Architekturtest durchgesetzt.
• Ist die Grenze ein Netzwerk, wird auf der empfangenden Seite erneut validiert.

Ein Typsystem prüft den Code gegen sich selbst. An einer externen Grenze kommen die Daten von außerhalb des Codes: von einem Modell, einem Client, einer Queue. Die Typannotationen von TypeScript werden vor der Ausführung des Programms entfernt, und JSON.parse ist mit dem Rückgabetyp any deklariert; die Python-Laufzeit setzt Typannotationen nicht durch; und ein Java-Typ beschreibt, was ein Deserialisierer erzeugen sollte, nicht, was der Absender geschickt hat. Der Typ ist ein Versprechen, das die Grenze zur Laufzeit mit einem Schema einlösen muss.

• Der statische Typ wird aus dem Laufzeitschema abgeleitet, wo immer die Sprache das erlaubt.
• Validiert wird auf jeder empfangenden Seite, nicht nur am Web-Eintrittspunkt.
• Casts gehören nicht in Code an der Grenze: Ein Cast ist die Stelle, an der das Typsystem aufhört zu prüfen.

Eine grüne Pipeline belegt, dass die Prüfungen, die sie ausgeführt hat, bestanden wurden. Sie sagt nichts über Prüfungen, die übersprungen und als erfolgreich gemeldet wurden, über Auswahlen, auf die kein Test passte, über Fences am falschen Pfad oder über Eigenschaften, für die niemand eine Prüfung geschrieben hat. Das Modell des COADF-Kontrollberichts formuliert dieselbe Regel von der anderen Seite: Eine Kontrolle gilt nur dann als durchgesetzt, wenn ihr Nachweis im identifizierten Lauf ausgeführt wurde und bestanden hat.

• Für jeden Lauf wird festgehalten, welche Prüfungen gelaufen sind und wie viele Assertions ausgeführt wurden.
• Der Zahnbeweis jedes Fence wird auf seinem echten Pfad erbracht, und erneut, wenn sich der Pfad ändert.
• Was nicht geprüft wird, verdient dieselbe ernsthafte Prüfung wie das, was geprüft wird.