En esta página
Propiedades de arquitectura tratadas
- P-1La carga de trabajo probabilística en su propio namespace, con salida de red solo hacia lo que necesita y sin credencial para el almacén autorizado. Un complemento de la frontera de la aplicación, nunca un sustituto.
- P-4Contexto de ejecución configurado una vez por carga de trabajo; una pipeline de trazas muestreada, separada de la traza de auditoría; procedencia de la configuración legible en cada pod.
- P-6La admisión de despliegues y las puertas de publicación de versiones como superficies de fence, con sus formas típicas de eludirlas nombradas.
- P-8Revisiones de configuración y de políticas que sobreviven a los despliegues progresivos, y un registro de decisión que nombra la revisión cuando hay dos activas a la vez.
- P-7Servicios externos alcanzados a través de una salida de red explícita, de modo que una nueva dependencia es un cambio revisado de la política, no una línea de código.
- P-2, P-3No se tratan a nivel de infraestructura: son propiedades de la aplicación, y COADF solo las publica como principios.
Intención de arquitectura
Kubernetes trae fronteras propias (namespaces, políticas de red, admisión, despliegue progresivo) y modos de fallo propios: objetos que se aceptan y no se aplican, una reconciliación que ocurre tarde o temprano, dos versiones del mismo servicio respondiendo a la vez. Este perfil hace corresponder las propiedades de COADF con esas fronteras sin tratar Kubernetes como un requisito de COADF, y sin dejar que un control del clúster ocupe el lugar de un control de la aplicación.
La regla que lo recorre: la infraestructura puede hacer que una frontera sea más difícil de cruzar, y no puede hacer que exista. Ninguna política de red repara una aplicación que escribe la salida del modelo en sus propias tablas autorizadas.
Correspondencia tecnológica
| Propiedad de arquitectura | Cloud-native y Kubernetes |
|---|---|
| Frontera probabilística | Un Deployment y un namespace separados; salida de red con NetworkPolicy; la credencial de escritura creada solo donde se ejecuta el dominio; permisos de base de datos por carga de trabajo |
| Fence de admisión | ValidatingAdmissionPolicy (CEL, dentro del proceso) u OPA Gatekeeper (Rego, con auditoría de los recursos existentes) |
| Contexto de ejecución | Configuración del SDK de OpenTelemetry por carga de trabajo; una pipeline del Collector para las trazas |
| Traza de auditoría | El propio almacén de solo inserción de la aplicación, fuera de la pipeline de telemetría |
| Procedencia de la configuración | Anotaciones de revisión, ConfigMaps inmutables nombrados por revisión, imágenes fijadas por digest; un controlador GitOps que registra la revisión sincronizada |
| Control de la publicación de versiones | Checks obligatorios que no pueden pasar por haberse omitido; entornos de despliegue; promoción por digest |
| Política | OPA como servicio o sidecar, con la revisión de su bundle en los registros de decisiones; políticas de admisión para las reglas de infraestructura |
Patrón de referencia
Tres namespaces: inference para el cliente del modelo y su frontera, model-serving para el endpoint del modelo, records para la recepción de propuestas, el núcleo de dominio y la base de datos. La página Frontera probabilística dibuja el mismo sistema como diagrama de clúster.
P-1 · Ninguna ruta hacia los registros
- Propósito
- Cuando el lado probabilístico se ejecuta como carga de trabajo propia, no darle ninguna ruta hacia el almacén autorizado.
- Propiedad de arquitectura
- El aislamiento de red como aplicación adicional, a nivel de infraestructura, de la frontera de P-1. Se suma a la frontera de la aplicación y no la sustituye.
# 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: 53Lo que omite a propósito
- El plugin de red. Sin uno que implemente NetworkPolicy, este objeto se acepta y no hace nada.
- Las reglas de entrada (ingress) y una política de denegación por defecto para el namespace.
- Las etiquetas de los pods de DNS, que varían entre clústeres.
- La salida (egress) hacia un modelo alojado fuera del clúster, que necesita una regla propia.
Cómo verificarlo
No se ejecutó para este Companion: el manifiesto se validó contra los esquemas de Kubernetes, lo que demuestra su forma y nada sobre su aplicación efectiva. Para verificar la aplicación efectiva, en un clúster de prueba con un plugin de red que la aplique, desde un pod de inferencia: el endpoint del modelo responde y la base de datos de registros no; al borrar la política, la base de datos responde, lo que demuestra que era la política la que la bloqueaba.
Modo de fallo que aborda
Una NetworkPolicy aplicada a un clúster cuyo plugin de red no la hace cumplir. El manifiesto es válido, la revisión pasa y nada queda aislado.
Se apoya en
P-6 · Un fence en el momento del despliegue
ValidatingAdmissionPolicy es estable desde Kubernetes 1.30 y se ejecuta dentro del API server, así que no necesita que haya un webhook disponible. Las mismas reglas pueden escribirse para OPA Gatekeeper, que añade una auditoría de los recursos que ya existen y acciones de aplicación como dryrun y warn; ambas opciones son válidas, y la propiedad no depende de la elección.
La regla tiene que comprobar entera la cosa que nombra. Buscar @sha256: en algún punto de la referencia de imagen admite image@sha256: sin nada detrás; esta política exige un digest SHA-256 completo. Además exige que la anotación de revisión contenga una revisión, y no solo que exista.
- Propósito
- No admitir ningún Deployment cuyas imágenes no estén fijadas por un digest bien formado, o que no pueda nombrar, en una anotación no vacía, la versión de configuración de la que procede.
- Propiedad de arquitectura
- Un estado prohibido impide la transición, aquí la creación o actualización de un Deployment (P-6), y la procedencia de la configuración se convierte en una propiedad de cada carga de trabajo en ejecución (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"Lo que omite a propósito
- La validación en la aplicación. La admisión ve objetos de la API y nunca las peticiones que atiende el servicio.
- Los objetos que ya existen. La admisión evalúa las peticiones a medida que se hacen, y añadir esta política no vuelve a comprobar nada de lo que ya está en ejecución.
- Los pods creados directamente y otros tipos de carga de trabajo (StatefulSet, Job, CronJob, DaemonSet), que necesitan cada uno su propia coincidencia.
- Si la versión nombrada existe, o si el digest es el que construyó la integración continua. La regla comprueba la forma de un digest, no su origen.
Cómo verificarlo
Contra un servidor de API de Kubernetes real (un kube-apiserver 1.37 local y desechable, sin nodos; cada caso, un dry run del lado del servidor): se admiten las imágenes fijadas por digest, también detrás de un puerto de registro y después de una etiqueta; se rechazan una imagen solo con etiqueta, un digest vacío, un digest que no es hexadecimal y un digest de longitud incorrecta, y también una anotación de versión ausente, vacía o en blanco (tests/test_admission_policy.py). Con una regla que solo comprueba la presencia, contains('@sha256:') y un in a secas, se admiten cinco de esos casos, y por eso la regla comprueba el digest entero.
Modo de fallo que aborda
Supuestos de entrega no verificados: una etiqueta movida después de la revisión, o un Deployment en ejecución que nadie puede relacionar con la configuración a partir de la cual se generó.
P-4 y P-8 · Procedencia de la configuración en el pod
- Propósito
- Hacer visible la versión de configuración en el objeto, en la plantilla del pod y en el nombre de un ConfigMap inmutable.
- Propiedad de arquitectura
- Una versión nueva es un rollout, y ningún pod ejecuta una configuración que no pueda nombrar. La versión de la plantilla del prompt que comunica la llamada al modelo (
prompt_revisionen la frontera de Python) tiene aquí una contraparte desplegable.
# 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-3f9c2d1Lo que omite a propósito
- El solapamiento del rollout. Durante una actualización gradual, los pods antiguos y los nuevos atienden a la vez, así que hay dos versiones activas al mismo tiempo; lo que tiene que nombrar la versión es el registro de decisión, no el estado del despliegue.
- Secretos, sondas, recursos y contexto de seguridad.
- La cuenta de servicio y sus permisos.
Cómo verificarlo
Editar el texto del prompt con el mismo nombre: el ConfigMap es inmutable y el cambio se rechaza. Crear un ConfigMap nuevo y actualizar el nombre y las anotaciones: le sigue un rollout, y cada pod comunica su versión como service.version.
Modo de fallo que aborda
Entornos que ejecutan configuraciones distintas sin procedencia. Un ConfigMap leído mediante variables de entorno no se recoge hasta que los pods se reinician, uno montado se recoge al cabo de un tiempo, y entre tanto nadie puede decir qué configuración produjo una respuesta determinada.
P-4 · La pipeline de trazas no es la traza de auditoría
Los SDK de OpenTelemetry leen OTEL_PROPAGATORS y usan por defecto tracecontext,baggage, así que el contexto de ejecución cruza las fronteras entre servicios sin código. La identidad de auditoría no viaja por ese camino: forma parte del contrato de cada mensaje, y las entradas de auditoría las escribe la aplicación en su propio almacén.
- Propósito
- Mostrar una pipeline de trazas normal, con muestreo, y por qué la traza de auditoría nunca pasa por una.
- Propiedad de arquitectura
- La telemetría de ejecución y la traza de auditoría son artefactos distintos, y prometen cosas distintas. Se correlacionan mediante el
trace_idde auditoría, y la traza de auditoría nunca pasa por una pipeline configurada para descartar datos (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]Lo que omite a propósito
- El tail sampling, que necesita que todos los spans de una traza lleguen a la misma instancia del Collector.
- El backend de trazas y su retención.
- Las pipelines de logs y de métricas.
- Los porcentajes. Son ajustes operativos, suministrados mediante expansión de variables de entorno, y sus valores son irrelevantes para la propiedad de arquitectura.
Cómo verificarlo
otelcol-contrib validate acepta la configuración con los dos porcentajes suministrados por el entorno, y la rechaza cuando faltan. Enviar un número conocido de trazas y contar lo que llega: con cualquier muestreo que descarte trazas, algunas no llegan, y esa es la propiedad que descalifica este camino como traza de auditoría.
Modo de fallo que aborda
Una traza presente solo en el backend de trazas: la pregunta “qué pasó con esta transacción” se responde desde un almacén al que se le permite haberla descartado.
P-6 · Controles de publicación de versiones
El workflow define los checks y hace fallar su job de resumen cuando un fence falla, se cancela o se omite. No puede hacer obligatorio ese job: eso corresponde a la protección de ramas o a un ruleset en la configuración del repositorio, y sin ello el botón de fusión ignora el resultado.
- Propósito
- Detener el merge y la entrega ante un fence fallido, con una comprobación obligatoria que sigue en rojo cuando se omite un fence.
- Propiedad de arquitectura
- Un fence fallido, cancelado u omitido hace fallar el job
fences, y la entrega no se ejecuta (P-6). El workflow no puede hacer obligatoriofences: solo la protección de ramas o un ruleset en la configuración del repositorio bloquea un merge en función de él.
# 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 }}"Lo que omite a propósito
- El propio build del sitio;
make sitelo representa. - La configuración de protección de ramas, que vive en la configuración del repositorio y no en el workflow.
- Fijar las actions a hashes de commit, la práctica más sólida. Aquí se usan etiquetas de versión mayor por legibilidad.
Cómo verificarlo
Hacer fallar un job de fence en una rama de prueba: el job fences falla y la entrega se omite. Hacer en cambio que un job de fence se omita, con un if: falso: el job fences sigue fallando, porque un job omitido comunica éxito a la protección de ramas y este job se niega a contarlo.
Modo de fallo que aborda
Una comprobación obligatoria que se pone en verde por haberse omitido. GitHub informa de un job omitido como éxito, así que un job obligatorio que depende de un fence fallido puede dejar pasar el merge.
Modos de fallo
Una NetworkPolicy que nada aplica
Una NetworkPolicy sin un plugin de red que la implemente no tiene ningún efecto. El manifiesto es válido, la revisión le da el visto bueno y nada queda aislado.
Un guion amplía la regla
Dentro de una misma entrada
to, unnamespaceSelectory unpodSelectorjuntos seleccionan esos pods en esos namespaces. Escritos como dos elementos de lista, seleccionan el namespace entero, o esos pods en el propio namespace de la política. La documentación de Kubernetes advierte exactamente de esta diferencia de YAML.La admisión tomada por validación de la aplicación
La admisión intercepta las peticiones al API server: ve Deployments y Pods, nunca las peticiones que atiende el servicio ni las respuestas que devuelve un modelo. Véase la nota técnica.
Un fence que falla en abierto
Un webhook cuya política de fallo es
Ignoredeja pasar una petición cuando no se puede llamar al webhook. El día que el webhook está caído es el día que la regla está desactivada.Objetos existentes que nunca se vuelven a comprobar
La admisión juzga las peticiones a medida que llegan. Para LimitRange, Kubernetes indica que los pods que ya se están ejecutando siguen sin cambios; del mismo modo, una nueva regla de admisión no dice nada de lo que se admitió antes que ella. La auditoría de Gatekeeper existe para cubrir ese hueco.
Una etiqueta movida después de la revisión
Los digests son inmutables; las etiquetas pueden moverse para apuntar a imágenes distintas. Una imagen revisada por etiqueta no es necesariamente la imagen que se está ejecutando.
Una deriva de configuración que no se ve
Un ConfigMap consumido a través de variables de entorno no se actualiza hasta que el pod se reinicia, uno montado se actualiza tarde o temprano, y uno montado con
subPathno se actualiza nunca. Tres pods pueden tener tres configuraciones mientras todos los manifiestos nombran una sola.Dos revisiones activas durante un despliegue progresivo
Las actualizaciones progresivas ejecutan la versión antigua y la nueva al mismo tiempo. Todo lo que tenga que nombrar una revisión (una decisión, una extracción, una respuesta) debe registrarla en el momento en que se produce, no deducirla después a partir del despliegue.
La pipeline muestreada usada como registro
Una traza que no se muestrea no se exporta. Una pipeline configurada para conservar una fracción de las trazas es correcta para el diagnóstico y no puede responder a una pregunta de auditoría.
Baggage que sale del edificio
OpenTelemetry advierte de que el baggage puede propagarse a destinatarios no previstos, incluidas API de terceros. Un identificador puesto en el baggage por comodidad viaja más lejos de lo que su dueño pretendía.
Una revisión sincronizada leída como la revisión desplegada
status.sync.revisionde Argo CD es la revisión con la que se comparó por última vez el estado en vivo; el historial de sincronización registra la revisión que aplicó realmente cada sincronización. Solo coinciden mientras la aplicación está sincronizada.Una puerta de persona con nombre que el plan no aplica
En los planes GitHub Free, Pro y Team, los revisores obligatorios en los entornos solo están disponibles para repositorios públicos. Un repositorio privado en esos planes tiene el nombre del ajuste y no su efecto.
Verificación
Prueba de despliegue o de admisión
Pasa cuando: Contra un API server local desechable, el Deployment de ejemplo se admite en un namespace que lleva la etiqueta del binding, y también los digests detrás de un puerto de registro o después de una etiqueta.
Prueba de dientes: Una imagen solo con etiqueta, un digest vacío o mal formado, y una revisión ausente, vacía o en blanco son rechazados cada uno por la política. Si las reglas del digest y de la revisión se sustituyen por comprobaciones de presencia, cinco de esos casos se admiten y las pruebas fallan.
Prueba de integración
Pasa cuando: No ejecutada en esta revisión del perfil. Desde un pod de inferencia, con un plugin de red que aplique las políticas: el endpoint del modelo y la recepción de propuestas responden, y el puerto de la base de datos no.
Prueba de dientes: Borrar la política: la base de datos responde, lo que demuestra que era la política, y no otra cosa, la que la bloqueaba.
Prueba de contrato
Pasa cuando: Los manifiestos validan contra los esquemas de Kubernetes de cada versión menor soportada, en modo estricto, de modo que un campo mal escrito es un error.
Prueba de dientes: Escribir mal
podSelector: la validación estricta falla.Prueba de contrato
Pasa cuando: La configuración del Collector valida con el binario del Collector de la versión desplegada, con los porcentajes proporcionados por el entorno.
Prueba de dientes: Escribir mal un ajuste de un procesador, o dejar sin definir los porcentajes: la validación falla.
Prueba de extremo a extremo
Pasa cuando: Un job de fence fallido hace fallar el job de resumen y omite la publicación de la versión; la protección de ramas incluye el job de resumen como obligatorio.
Prueba de dientes: Omitir un job de fence en lugar de hacerlo fallar: el job de resumen falla igualmente, porque se niega a contar un job omitido.
Evidencia manual
Pasa cuando: En cada publicación de versión se registran los digests de las imágenes y la revisión de la configuración, y se comparan con lo que informa el clúster.
Realizaciones alternativas
- Gatekeeper, Kyverno o ValidatingAdmissionPolicy para las reglas de admisión. La propiedad es que la regla detiene la transición y se la ha visto hacerlo; el motor es una elección.
- La política de autorización de una service mesh cuando la salida de red tiene que controlarse por petición y no por puerto.
- Controladores GitOps (Argo CD, Flux) como registro de qué revisión de la configuración está aplicada, además de las anotaciones en los objetos.
- Una plataforma gestionada sin Kubernetes. Cada propiedad de este perfil tiene allí un equivalente: desplegables separados, reglas de red, puertas de despliegue, revisiones de configuración. COADF no exige ninguna de las herramientas que aquí se nombran.
Compromisos
- Admisión dentro del proceso frente a un motor de políticas. ValidatingAdmissionPolicy no necesita ningún componente adicional y no puede caerse por separado del API server; Gatekeeper añade una auditoría de los recursos existentes y una aplicación escalonada, y es un sistema más que operar.
- El aislamiento de red tiene un precio: un plugin que aplique las políticas, políticas que mantener y fallos que parecen errores de la aplicación cuando una regla es demasiado estrecha.
- Los despliegues separados convierten una frontera en un contrato versionado que tiene que seguir siendo compatible a lo largo de los despliegues progresivos, en ambas direcciones.
- El muestreo ahorra costes y quita valor como evidencia. Conviene conservarlo, y conservar la traza de auditoría en otro lugar.
Limitaciones
- Los manifiestos se validaron contra los esquemas de Kubernetes para 1.35, 1.36 y 1.37; la política de admisión se aplicó a un API server local desechable sin nodos y se ejercitó con dry runs del lado del servidor; la configuración del Collector se validó y el workflow pasó por el linter. Nada se ejecutó en un clúster con nodos: no se observaron la aplicación de la política de red, los despliegues progresivos ni el comportamiento del Collector en ejecución.
- Los ejemplos omiten reglas de ingress, contextos de seguridad, recursos, sondas y secretos.
- Kubernetes es una manera de desplegar estas propiedades. COADF no lo exige.
Lo que este perfil no establece
Seguir este perfil no establece cumplimiento normativo, certificación ni evaluación de la conformidad, y COADF no exige nada de lo que aquí figura. Un clúster que admite estos manifiestos ha admitido estos manifiestos.
Entorno de referencia probado
- kubeconform 0.8.0 · validación estricta de esquemas contra Kubernetes 1.35.0, 1.36.0 y 1.37.0; no aplicado a un clúster
- Kubernetes API server (envtest release) 1.37.0 · un kube-apiserver local desechable con etcd y sin nodos: la política de admisión aplicada y diez casos ejecutados como dry runs del lado del servidor; nada planificado, sin aplicación de reglas de red
- OpenTelemetry Collector (contrib) 0.160.0 · otelcol-contrib validate
- actionlint 1.7.12 · sin shellcheck, así que el shell dentro de los pasos run no se analizó
Fuentes
- Kubernetes: Network Policies: prerequisites · documentación oficial · Kubernetes 1.37 · Comprobado el 2026-09-11
- Kubernetes: Validating Admission Policy · documentación oficial · Kubernetes 1.37 · Comprobado el 2026-09-11
- Kubernetes: Admission control: what are they · documentación oficial · Kubernetes 1.37 · Comprobado el 2026-09-11
- Kubernetes: Dynamic admission control: failure policy · documentación oficial · Kubernetes 1.37 · Comprobado el 2026-09-11
- Kubernetes: Limit Ranges: admission-time validation · documentación oficial · Kubernetes 1.37 · Comprobado el 2026-09-11
- Kubernetes: Images: image names and digests · documentación oficial · Kubernetes 1.37 · Comprobado el 2026-09-11
- Kubernetes: ConfigMaps: updates and immutability · documentación oficial · Kubernetes 1.37 · Comprobado el 2026-09-11
- Kubernetes: Deployments: rolling update · documentación oficial · Kubernetes 1.37 · Comprobado el 2026-09-11
- Kubernetes: Annotations · documentación oficial · Kubernetes 1.37 · Comprobado el 2026-09-11
- Open Policy Agent Gatekeeper: Gatekeeper: audit · documentación oficial · Gatekeeper 3.23 · Comprobado el 2026-09-11
- Open Policy Agent Gatekeeper: Gatekeeper: enforcement actions · documentación oficial · Gatekeeper 3.23 · Comprobado el 2026-09-11
- OpenTelemetry: SDK environment variables: OTEL_PROPAGATORS · especificación · Specification 1.60.0 · Comprobado el 2026-09-11
- OpenTelemetry: Sampling · documentación oficial · Comprobado el 2026-09-11
- OpenTelemetry: Tracing SDK: sampling · especificación · Specification 1.60.0 · Comprobado el 2026-09-11
- OpenTelemetry: Transforming telemetry · documentación oficial · Comprobado el 2026-09-11
- OpenTelemetry Collector Contrib: Tail sampling processor · repositorio del proyecto · Comprobado el 2026-09-11
- OpenTelemetry: Baggage: security considerations · documentación oficial · Comprobado el 2026-09-11
- Argo CD: Application CRD: status.sync.revision and status.history · repositorio del proyecto · Argo CD 3.5.2 · Comprobado el 2026-09-11
- GitHub: Workflow syntax: jobs.<job_id>.needs · documentación oficial · Comprobado el 2026-09-11
- GitHub: Control jobs with conditions · documentación oficial · Comprobado el 2026-09-11
- GitHub: Troubleshooting required status checks · documentación oficial · Comprobado el 2026-09-11
- GitHub: Deployments and environments: required reviewers · documentación oficial · Comprobado el 2026-09-11
- GitHub: About protected branches: require status checks before merging · documentación oficial · Comprobado el 2026-09-11
- Open Container Initiative: Image specification, descriptors: SHA-256 digests · especificación · Comprobado el 2026-09-11
- OpenTelemetry: Collector configuration: environment variables · documentación oficial · Comprobado el 2026-09-11