Sur cette page
Propriétés d'architecture traitées
- P-1La charge de travail probabiliste dans son propre namespace, avec une sortie réseau limitée à ce dont elle a besoin et aucun identifiant d'accès au stockage qui fait autorité. Un ajout à la frontière de l'application, jamais un remplacement.
- P-4Le contexte d'exécution configuré une fois par charge de travail ; un pipeline de traces échantillonné tenu à l'écart de la piste d'audit ; la provenance de la configuration lisible sur chaque pod.
- P-6L'admission au déploiement et les barrières de livraison comme surfaces de fence, avec leurs contournements caractéristiques nommés.
- P-8Des révisions de configuration et de politique qui survivent aux déploiements progressifs, et un enregistrement de décision qui nomme la révision quand deux sont actives en même temps.
- P-7Les services externes atteints par une sortie réseau explicite, de sorte qu'une nouvelle dépendance est une modification revue de la politique, et non une ligne de code.
- P-2, P-3Non traités au niveau de l'infrastructure : ce sont des propriétés de l'application, et COADF ne les publie que comme principes.
Intention d'architecture
Kubernetes apporte ses propres frontières (namespaces, politique réseau, admission, déploiement progressif) et ses propres modes de défaillance : des objets acceptés et non appliqués, une réconciliation qui a lieu à terme, deux versions du même service qui répondent en même temps. Ce profil rapporte les propriétés COADF à ces frontières sans faire de Kubernetes une exigence de COADF, et sans laisser un contrôle du cluster tenir lieu de contrôle de l'application.
La règle qui le traverse : l'infrastructure peut rendre une frontière plus difficile à franchir, elle ne peut pas la faire exister. Une application qui écrit la sortie d'un modèle dans ses propres tables faisant autorité n'est réparée par aucune politique réseau.
Correspondance technologique
| Propriété d'architecture | Cloud-native et Kubernetes |
|---|---|
| Frontière probabiliste | Un Deployment et un namespace séparés ; sortie réseau par NetworkPolicy ; l'identifiant d'écriture créé seulement là où tourne le domaine ; des droits de base de données par charge de travail |
| Fence d'admission | ValidatingAdmissionPolicy (CEL, dans le processus) ou OPA Gatekeeper (Rego, avec un audit des ressources existantes) |
| Contexte d'exécution | Configuration du SDK OpenTelemetry par charge de travail ; un pipeline Collector pour les traces |
| Piste d'audit | Le stockage en ajout seul propre à l'application, hors du pipeline de télémétrie |
| Provenance de la configuration | Annotations de révision, ConfigMaps immuables nommées par révision, images épinglées par digest ; un contrôleur GitOps qui enregistre la révision synchronisée |
| Contrôle des livraisons | Des checks requis qui ne peuvent pas passer en étant ignorés ; des environnements de déploiement ; une promotion par digest |
| Politique | OPA comme service ou sidecar, la révision de son bundle dans les journaux de décision ; des politiques d'admission pour les règles d'infrastructure |
Pattern de référence
Trois namespaces : inference pour le client du modèle et sa frontière, model-serving pour le point de terminaison du modèle, records pour la réception des propositions, le cœur du domaine et la base de données. La page Frontière probabiliste dessine le même système sous forme de schéma de cluster.
P-1 · Aucune route vers les enregistrements
- Objet
- Quand le côté probabiliste tourne comme une charge de travail à part, ne lui donner aucune route vers le stockage faisant autorité.
- Propriété d'architecture
- L'isolation réseau comme application supplémentaire, au niveau de l'infrastructure, de la frontière de P-1. Elle s'ajoute à la frontière applicative et ne la remplace pas.
# Illustrative reference example: the inference workloads can reach the model# endpoint, the domain's proposal intake and DNS, and nothing else. The records# database sits in the same namespace as the intake, and no rule here opens a# route to it: selecting the intake pods and port is what keeps it closed.# Enforced only by a network plugin that implements NetworkPolicy, and only as an# addition: the application boundary is still required, and this replaces none of it.apiVersion: networking.k8s.io/v1kind: NetworkPolicymetadata: name: inference-egress namespace: inferencespec: podSelector: {} # every pod in this namespace policyTypes: - Egress egress: - to: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: model-serving ports: - protocol: TCP port: 8080 - to: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: records podSelector: # same list item: this namespace AND these pods matchLabels: app: proposal-intake ports: - protocol: TCP port: 8443 - to: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: kube-system podSelector: matchLabels: k8s-app: kube-dns ports: - protocol: UDP port: 53 - protocol: TCP port: 53Ce qu'il omet délibérément
- Le plugin réseau. Sans un plugin qui met en œuvre NetworkPolicy, cet objet est accepté et ne fait rien.
- Les règles d'entrée, et une politique de refus par défaut pour le namespace.
- Les labels des pods DNS, qui varient d'un cluster à l'autre.
- La sortie vers un modèle hébergé hors du cluster, qui demande une règle à part.
Comment le vérifier
Non exécuté pour ce Companion : le manifeste a été validé au regard des schémas Kubernetes, ce qui prouve sa forme et rien quant à l'application effective. Pour vérifier l'application effective, dans un cluster de test doté d'un plugin réseau qui l'applique, depuis un pod d'inférence : le point de terminaison du modèle répond et la base de données des enregistrements ne répond pas ; supprimer la politique, et la base de données répond, ce qui prouve que c'était bien la politique qui la bloquait.
Mode de défaillance traité
Une NetworkPolicy déposée dans un cluster dont le plugin réseau ne l'applique pas. Le manifeste est valide, la revue passe, et rien n'est isolé.
S'appuie sur
P-6 · Un fence au moment du déploiement
ValidatingAdmissionPolicy est stable depuis Kubernetes 1.30 et s'exécute dans le serveur d'API, si bien qu'elle n'a besoin d'aucun webhook disponible. Les mêmes règles peuvent être écrites pour OPA Gatekeeper, qui ajoute un audit des ressources qui existent déjà et des actions d'application comme dryrun et warn ; les deux sont valables, et la propriété ne dépend pas du choix.
La règle doit contrôler la totalité de ce qu'elle nomme. Un test qui cherche @sha256: quelque part dans la référence d'image admet image@sha256: sans rien derrière ; cette politique exige un digest SHA-256 complet, et exige que l'annotation de révision contienne une révision, pas seulement qu'elle existe.
- Objet
- N'admettre aucun Deployment dont les images ne sont pas épinglées par un digest bien formé, ou qui ne peut pas nommer, dans une annotation non vide, la révision de configuration dont il provient.
- Propriété d'architecture
- Un état interdit empêche la transition, ici la création ou la mise à jour d'un Deployment (P-6), et la provenance de la configuration devient une propriété de chaque charge de travail en cours d'exécution (P-4).
# Illustrative reference example: a Deployment is admitted only if every image# reference ends in a well-formed sha256 digest and the object names, in a# non-empty annotation, the configuration revision it was rendered from.# Admission sees API objects; it never sees application data.apiVersion: admissionregistration.k8s.io/v1kind: ValidatingAdmissionPolicymetadata: name: deployments-declare-provenancespec: failurePolicy: Fail matchConstraints: resourceRules: - apiGroups: ["apps"] apiVersions: ["v1"] operations: ["CREATE", "UPDATE"] resources: ["deployments"] validations: - expression: >- object.spec.template.spec.containers.all(c, c.image.matches('^[^@]+@sha256:[0-9a-f]{64}$')) && (!has(object.spec.template.spec.initContainers) || object.spec.template.spec.initContainers.all(c, c.image.matches('^[^@]+@sha256:[0-9a-f]{64}$'))) message: "every container image must end in a sha256 digest of 64 hex characters" - expression: >- has(object.metadata.annotations) && 'refapp.example/config-revision' in object.metadata.annotations && object.metadata.annotations['refapp.example/config-revision'].matches('^[A-Za-z0-9._-]+$') message: "the Deployment must name, in a non-empty annotation, the configuration revision it was rendered from"---apiVersion: admissionregistration.k8s.io/v1kind: ValidatingAdmissionPolicyBindingmetadata: name: deployments-declare-provenancespec: policyName: deployments-declare-provenance validationActions: ["Deny"] matchResources: namespaceSelector: matchLabels: refapp.example/provenance-required: "true"Ce qu'il omet délibérément
- La validation au niveau de l'application. L'admission voit des objets d'API, et jamais les requêtes que traite le service.
- Les objets qui existent déjà. L'admission évalue les requêtes au moment où elles sont faites, et ajouter cette politique ne recontrôle rien de ce qui tourne déjà.
- Les pods créés directement, et les autres types de charge de travail (StatefulSet, Job, CronJob, DaemonSet), qui demandent chacun leur propre correspondance.
- L'existence de la révision nommée, ou le fait que le digest soit bien celui que l'intégration continue a construit. La règle contrôle la forme d'un digest, pas son origine.
Comment le vérifier
Face à un vrai serveur d'API Kubernetes (un kube-apiserver 1.37 local et jetable, sans nœuds ; chaque cas en dry run côté serveur) : les images épinglées par digest sont admises, y compris derrière un port de registre et après un tag ; une image avec un tag seul, un digest vide, un digest qui n'est pas hexadécimal et un digest de mauvaise longueur sont refusés, tout comme une annotation de révision manquante, vide ou blanche (tests/test_admission_policy.py). Avec une règle de simple présence, contains('@sha256:') et un in nu, cinq de ces cas sont admis, et c'est pourquoi la règle porte sur le digest entier.
Mode de défaillance traité
Des hypothèses de livraison non vérifiées : un tag déplacé après la revue, ou un Deployment en cours d'exécution que personne ne peut rattacher à la configuration à partir de laquelle il a été généré.
P-4 et P-8 · La provenance de la configuration au niveau du pod
- Objet
- Rendre la révision de configuration visible dans l'objet, dans le modèle de pod et dans le nom d'une ConfigMap immuable.
- Propriété d'architecture
- Une nouvelle révision est un déploiement progressif, et aucun pod n'exécute une configuration qu'il ne peut pas nommer. La révision du modèle de prompt que rapporte l'appel au modèle (
prompt_revisiondans la frontière Python) a ici un pendant déployable.
# Illustrative reference example: configuration provenance you can read off a# running pod. The revision is in the object, in the pod template and in the# name of the immutable ConfigMap, so a new revision is a new rollout and no# pod runs a configuration it cannot name.apiVersion: v1kind: ConfigMapmetadata: name: prompt-templates-3f9c2d1 namespace: inferenceimmutable: truedata: service-report.txt: | Read the service report and propose next_service_due and component_class.---apiVersion: apps/v1kind: Deploymentmetadata: name: report-extraction namespace: inference annotations: refapp.example/config-revision: "3f9c2d1"spec: replicas: 2 selector: matchLabels: app: report-extraction template: metadata: labels: app: report-extraction annotations: refapp.example/config-revision: "3f9c2d1" spec: automountServiceAccountToken: false containers: - name: worker image: registry.example/refapp/extraction@sha256:3f9c2d1e3f9c2d1e3f9c2d1e3f9c2d1e3f9c2d1e3f9c2d1e3f9c2d1e3f9c2d1e env: - name: OTEL_SERVICE_NAME value: report-extraction - name: OTEL_RESOURCE_ATTRIBUTES value: service.version=3f9c2d1 volumeMounts: - name: prompts mountPath: /etc/refapp/prompts readOnly: true volumes: - name: prompts configMap: name: prompt-templates-3f9c2d1Ce qu'il omet délibérément
- Le chevauchement pendant le déploiement progressif. Lors d'une mise à jour progressive, anciens et nouveaux pods servent en même temps, si bien que deux révisions sont actives à la fois ; c'est l'enregistrement de décision, et non l'état du déploiement, qui doit nommer la révision.
- Les secrets, les sondes, les ressources et le contexte de sécurité.
- Le compte de service et ses permissions.
Comment le vérifier
Modifier le texte du prompt sous le même nom : la ConfigMap est immuable et la modification est refusée. Créer une nouvelle ConfigMap et mettre à jour le nom et les annotations : un déploiement progressif suit, et chaque pod rapporte sa révision comme service.version.
Mode de défaillance traité
Des environnements qui exécutent des configurations différentes sans provenance. Une ConfigMap lue par des variables d'environnement n'est pas prise en compte avant le redémarrage des pods, une ConfigMap montée l'est au bout d'un certain temps, et dans l'intervalle personne ne peut dire quelle configuration a produit une réponse donnée.
P-4 · Le pipeline de traces n'est pas la piste d'audit
Les SDK OpenTelemetry lisent OTEL_PROPAGATORS, avec tracecontext,baggage par défaut, si bien que le contexte d'exécution franchit les frontières entre services sans code. L'identité d'audit ne voyage pas ainsi : elle fait partie du contrat de chaque message, et les entrées d'audit sont écrites par l'application dans son propre stockage.
- Objet
- Montrer un pipeline de traces ordinaire, échantillonné, et pourquoi la piste d'audit n'en traverse jamais un.
- Propriété d'architecture
- La télémétrie d'exécution et la piste d'audit sont des artefacts différents, qui promettent des choses différentes. Elles sont corrélées par le
trace_idd'audit, et la piste d'audit ne traverse jamais un pipeline configuré pour écarter des données (P-4).
# Illustrative reference example: an OpenTelemetry Collector pipeline for# traces. Sampling is legitimate here, and it is exactly why this pipeline is# not the audit trail: audit entries are written to their own append-only# store by the application, and never pass through this configuration.receivers: otlp: protocols: grpc: {} http: {} processors: memory_limiter: check_interval: 1s limit_percentage: ${env:MEMORY_LIMIT_PERCENTAGE} probabilistic_sampler: sampling_percentage: ${env:TRACE_SAMPLE_PERCENTAGE} batch: {} exporters: otlp: endpoint: tracing-backend.observability:4317 service: pipelines: traces: receivers: [otlp] processors: [memory_limiter, probabilistic_sampler, batch] exporters: [otlp]Ce qu'il omet délibérément
- L'échantillonnage en fin de trace (tail sampling), qui exige que chaque span d'une trace atteigne la même instance du Collector.
- Le backend de traces et sa durée de conservation.
- Les pipelines de logs et de métriques.
- Les pourcentages. Ce sont des réglages d'exploitation, fournis par expansion des variables d'environnement, et leurs valeurs sont sans incidence sur la propriété d'architecture.
Comment le vérifier
otelcol-contrib validate accepte la configuration quand les deux pourcentages sont fournis par l'environnement, et la refuse quand ils manquent. Envoyer un nombre connu de traces et compter ce qui arrive : avec tout échantillonnage qui écarte des traces, certaines n'arrivent pas, et c'est cette propriété qui disqualifie ce chemin comme piste d'audit.
Mode de défaillance traité
Une trace présente seulement dans le backend de traçage : la question « qu'est-il arrivé à cette transaction » trouve sa réponse dans un stockage qui a le droit de l'avoir écartée.
P-6 · Contrôles de livraison
Le workflow définit les checks et fait échouer son job récapitulatif quand un fence échoue, est annulé ou est ignoré. Il ne peut pas rendre ce job requis : c'est le rôle de la protection de branche ou d'un ruleset dans les paramètres du dépôt, et sans cela le bouton de fusion ignore le résultat.
- Objet
- Arrêter la fusion et la livraison sur un fence en échec, avec un seul contrôle requis qui reste rouge quand un fence est ignoré.
- Propriété d'architecture
- Un fence en échec, annulé ou ignoré fait échouer le job
fences, et la livraison ne s'exécute pas (P-6). Le workflow ne peut pas rendrefencesrequis : seule la protection de branche, ou un ruleset dans les paramètres du dépôt, bloque une fusion sur ce contrôle.
# Illustrative reference example: fences that stop a release, and one summary# check that cannot turn green by being skipped. Making it a REQUIRED check is a# repository setting (branch protection or a ruleset), not part of this file.name: releaseon: pull_request: push: branches: [main] jobs: architecture: runs-on: ubuntu-latest steps: - uses: actions/checkout@v7 - uses: actions/setup-python@v7 with: python-version: "3.12" - run: pip install -r requirements.txt - run: lint-imports tests: runs-on: ubuntu-latest steps: - uses: actions/checkout@v7 - uses: actions/setup-python@v7 with: python-version: "3.12" - run: pip install -r requirements.txt - run: pytest -q publication: runs-on: ubuntu-latest steps: - uses: actions/checkout@v7 - run: make site # writes the public build to build/ - name: Fence the built output env: PATTERNS: ${{ secrets.PUBLICATION_PATTERNS }} run: | printf '%s\n' "$PATTERNS" > "$RUNNER_TEMP/patterns.txt" python -m refapp.fence build/ "$RUNNER_TEMP/patterns.txt" # The one job branch protection requires. A skipped job reports success, # so this job runs whatever happened above and fails unless all passed. fences: if: ${{ always() }} needs: [architecture, tests, publication] runs-on: ubuntu-latest steps: - if: >- contains(needs.*.result, 'failure') || contains(needs.*.result, 'cancelled') || contains(needs.*.result, 'skipped') run: exit 1 release: if: github.event_name == 'push' needs: fences # never `if: always()` here: that would release after a failed fence runs-on: ubuntu-latest environment: production steps: - run: echo "promote the artifact built from ${{ github.sha }}"Ce qu'il omet délibérément
- Le build du site lui-même ;
make siteen tient lieu. - Les réglages de protection de branche, qui vivent dans les paramètres du dépôt et non dans le workflow.
- L'épinglage des actions sur des hashes de commit, la pratique la plus robuste. Des tags de version majeure sont utilisés ici pour la lisibilité.
Comment le vérifier
Faire échouer un job de fence sur une branche de test : le job fences échoue et la livraison est ignorée. Faire plutôt ignorer un job de fence, avec un if: faux : le job fences échoue quand même, car un job ignoré rapporte un succès à la protection de branche et ce job refuse de le compter.
Mode de défaillance traité
Un contrôle requis qui passe au vert en étant ignoré. GitHub rapporte un job ignoré comme un succès, si bien qu'un job requis qui dépend d'un fence en échec peut laisser passer la fusion.
Modes de défaillance
Une NetworkPolicy que rien n'applique
Une NetworkPolicy sans plugin réseau qui la met en œuvre n'a aucun effet. Le manifeste est valide, la revue passe, et rien n'est isolé.
Un tiret élargit la règle
Dans une même entrée
to, unnamespaceSelectoret unpodSelectorensemble sélectionnent ces pods dans ces namespaces. Écrits comme deux éléments de liste, ils sélectionnent le namespace entier, ou ces pods dans le namespace de la politique elle-même. La documentation de Kubernetes met en garde contre exactement cette différence de YAML.L'admission prise pour une validation de l'application
L'admission intercepte les requêtes adressées au serveur d'API : elle voit des Deployments et des Pods, jamais les requêtes que traite le service ni les réponses que renvoie un modèle. Voir la note technique.
Un fence qui s'ouvre en cas d'échec
Un webhook dont la politique d'échec est
Ignorelaisse passer une requête quand le webhook ne peut pas être appelé. Le jour où le webhook est en panne, la règle est désactivée.Des objets existants jamais recontrôlés
L'admission juge les requêtes à leur arrivée. Pour LimitRange, Kubernetes indique que les pods déjà en cours d'exécution continuent sans changement ; de même, une nouvelle règle d'admission ne dit rien de ce qui a été admis avant elle. L'audit de Gatekeeper existe pour combler cet écart.
Un tag déplacé après la revue
Les digests sont immuables ; les tags peuvent être déplacés pour pointer vers d'autres images. Une image revue par son tag n'est pas forcément l'image qui tourne.
Une dérive de configuration invisible
Une ConfigMap consommée par variables d'environnement n'est pas mise à jour avant le redémarrage du pod, une ConfigMap montée est mise à jour à terme, et une ConfigMap montée par
subPathne l'est jamais. Trois pods peuvent tenir trois configurations alors que chaque manifeste en nomme une.Deux révisions actives pendant un déploiement progressif
Les mises à jour progressives font tourner l'ancienne et la nouvelle version en même temps. Tout ce qui doit nommer une révision (une décision, une extraction, une réponse) doit l'enregistrer au moment où cela est produit, et non la déduire du déploiement après coup.
Le pipeline échantillonné utilisé comme enregistrement
Une trace qui n'est pas échantillonnée n'est pas exportée. Un pipeline configuré pour garder une fraction des traces convient au diagnostic et ne peut pas répondre à une question d'audit.
Du baggage qui quitte la maison
OpenTelemetry avertit que le baggage peut être propagé à des destinataires non prévus, y compris des API tierces. Un identifiant placé dans le baggage par commodité voyage plus loin que ne l'entendait son propriétaire.
Une révision synchronisée lue comme la révision déployée
Le
status.sync.revisiond'Argo CD est la révision à laquelle l'état réel a été comparé en dernier ; l'historique de synchronisation enregistre la révision que chaque synchronisation a réellement appliquée. Les deux ne coïncident que tant que l'application est synchronisée.Une barrière de personne nommée que l'offre n'applique pas
Sur les offres GitHub Free, Pro et Team, l'exigence de personnes qui vérifient (required reviewers) sur les environnements n'est disponible que pour les dépôts publics. Un dépôt privé sur ces offres a le nom du réglage, pas son effet.
Vérification
Test de déploiement ou d'admission
Réussit quand : Contre un serveur d'API local jetable, le Deployment d'exemple est admis dans un namespace portant le label de la liaison, tout comme les digests placés derrière un port de registre ou après un tag.
Preuve de dents : Une image avec seulement un tag, un digest vide ou mal formé, et une révision absente, vide ou faite d'espaces sont chacun refusés par la politique. Remplacer les règles de digest et de révision par des contrôles de présence : cinq de ces cas sont admis, et les tests échouent.
Test d'intégration
Réussit quand : Non exécuté pour cette révision. Depuis un pod d'inférence, avec un plugin réseau qui applique les règles : le point de terminaison du modèle et la réception des propositions répondent, et le port de la base de données ne répond pas.
Preuve de dents : Supprimer la politique : la base de données répond, ce qui démontre que c'est la politique, et rien d'autre, qui la bloquait.
Test de contrat
Réussit quand : Les manifestes sont validés contre les schémas Kubernetes de chaque version mineure prise en charge, en mode strict, de sorte qu'un champ mal orthographié est une erreur.
Preuve de dents : Mal orthographier
podSelector: la validation stricte échoue.Test de contrat
Réussit quand : La configuration du Collector est validée avec le binaire du Collector de la version déployée, les pourcentages étant fournis par l'environnement.
Preuve de dents : Mal orthographier un réglage de processeur, ou laisser les pourcentages non définis : la validation échoue.
Test de bout en bout
Réussit quand : Un job de fence en échec fait échouer le job récapitulatif, et la livraison est ignorée ; la protection de branche liste le job récapitulatif comme requis.
Preuve de dents : Ignorer un job de fence au lieu de le faire échouer : le job récapitulatif échoue quand même, parce qu'il refuse de compter un job ignoré.
Preuve manuelle
Réussit quand : À chaque livraison, les digests d'image et la révision de la configuration sont enregistrés, puis comparés à ce que rapporte le cluster.
Réalisations alternatives
- Gatekeeper, Kyverno ou ValidatingAdmissionPolicy pour les règles d'admission. La propriété est que la règle arrête la transition et qu'on l'a vue le faire ; le moteur est un choix.
- La politique d'autorisation d'un service mesh là où la sortie réseau doit être contrôlée par requête plutôt que par port.
- Des contrôleurs GitOps (Argo CD, Flux) comme enregistrement de la révision de configuration appliquée, en plus des annotations sur les objets.
- Une plateforme gérée sans Kubernetes. Chaque propriété de ce profil y a un équivalent : des unités déployables séparées, des règles réseau, des barrières de déploiement, des révisions de configuration. COADF n'exige aucun des outils nommés ici.
Compromis
- Admission dans le processus ou moteur de politiques. ValidatingAdmissionPolicy ne demande aucun composant supplémentaire et ne peut pas tomber en panne indépendamment du serveur d'API ; Gatekeeper ajoute un audit des ressources existantes et une application par étapes, et c'est un système de plus à exploiter.
- L'isolation réseau a un prix : un plugin qui applique les règles, des politiques à maintenir, et des défaillances qui ressemblent à des bugs de l'application quand une règle est trop stricte.
- Des déploiements séparés transforment une frontière en contrat versionné qui doit rester compatible d'un déploiement progressif à l'autre, dans les deux sens.
- L'échantillonnage réduit le coût et retire la valeur de preuve. Le garder, et tenir la piste d'audit ailleurs.
Limites
- Les manifestes ont été validés contre les schémas Kubernetes de 1.35, 1.36 et 1.37 ; la politique d'admission a été appliquée à un serveur d'API local jetable sans nœuds et mise à l'épreuve par des dry runs côté serveur ; la configuration du Collector a été validée et le workflow a été passé au linter. Rien n'a tourné sur un cluster avec des nœuds : l'application de la politique réseau, les déploiements progressifs et le comportement du Collector à l'exécution n'ont pas été observés.
- Les exemples omettent les règles d'ingress, les contextes de sécurité, les ressources, les sondes et les secrets.
- Kubernetes est une façon parmi d'autres de déployer ces propriétés. COADF ne l'exige pas.
Ce que ce profil n'établit pas
Suivre ce profil n'établit ni la conformité réglementaire, ni une certification, ni une évaluation de la conformité, et COADF n'exige rien de ce qui figure ici. Un cluster qui admet ces manifestes a admis ces manifestes.
Environnement de référence testé
- kubeconform 0.8.0 · validation stricte des schémas pour Kubernetes 1.35.0, 1.36.0 et 1.37.0 ; rien n'a été appliqué à un cluster
- Kubernetes API server (envtest release) 1.37.0 · un kube-apiserver local jetable avec etcd et sans nœuds : la politique d'admission appliquée et dix cas exécutés en dry run côté serveur ; rien de planifié, aucune application des règles réseau
- OpenTelemetry Collector (contrib) 0.160.0 · otelcol-contrib validate
- actionlint 1.7.12 · sans shellcheck, donc le shell des étapes run n'a pas été analysé
Sources
- Kubernetes: Network Policies: prerequisites · documentation officielle · Kubernetes 1.37 · Vérifié le 2026-09-11
- Kubernetes: Validating Admission Policy · documentation officielle · Kubernetes 1.37 · Vérifié le 2026-09-11
- Kubernetes: Admission control: what are they · documentation officielle · Kubernetes 1.37 · Vérifié le 2026-09-11
- Kubernetes: Dynamic admission control: failure policy · documentation officielle · Kubernetes 1.37 · Vérifié le 2026-09-11
- Kubernetes: Limit Ranges: admission-time validation · documentation officielle · Kubernetes 1.37 · Vérifié le 2026-09-11
- Kubernetes: Images: image names and digests · documentation officielle · Kubernetes 1.37 · Vérifié le 2026-09-11
- Kubernetes: ConfigMaps: updates and immutability · documentation officielle · Kubernetes 1.37 · Vérifié le 2026-09-11
- Kubernetes: Deployments: rolling update · documentation officielle · Kubernetes 1.37 · Vérifié le 2026-09-11
- Kubernetes: Annotations · documentation officielle · Kubernetes 1.37 · Vérifié le 2026-09-11
- Open Policy Agent Gatekeeper: Gatekeeper: audit · documentation officielle · Gatekeeper 3.23 · Vérifié le 2026-09-11
- Open Policy Agent Gatekeeper: Gatekeeper: enforcement actions · documentation officielle · Gatekeeper 3.23 · Vérifié le 2026-09-11
- OpenTelemetry: SDK environment variables: OTEL_PROPAGATORS · spécification · Specification 1.60.0 · Vérifié le 2026-09-11
- OpenTelemetry: Sampling · documentation officielle · Vérifié le 2026-09-11
- OpenTelemetry: Tracing SDK: sampling · spécification · Specification 1.60.0 · Vérifié le 2026-09-11
- OpenTelemetry: Transforming telemetry · documentation officielle · Vérifié le 2026-09-11
- OpenTelemetry Collector Contrib: Tail sampling processor · dépôt du projet · Vérifié le 2026-09-11
- OpenTelemetry: Baggage: security considerations · documentation officielle · Vérifié le 2026-09-11
- Argo CD: Application CRD: status.sync.revision and status.history · dépôt du projet · Argo CD 3.5.2 · Vérifié le 2026-09-11
- GitHub: Workflow syntax: jobs.<job_id>.needs · documentation officielle · Vérifié le 2026-09-11
- GitHub: Control jobs with conditions · documentation officielle · Vérifié le 2026-09-11
- GitHub: Troubleshooting required status checks · documentation officielle · Vérifié le 2026-09-11
- GitHub: Deployments and environments: required reviewers · documentation officielle · Vérifié le 2026-09-11
- GitHub: About protected branches: require status checks before merging · documentation officielle · Vérifié le 2026-09-11
- Open Container Initiative: Image specification, descriptors: SHA-256 digests · spécification · Vérifié le 2026-09-11
- OpenTelemetry: Collector configuration: environment variables · documentation officielle · Vérifié le 2026-09-11