Nesta página
Propriedades de arquitetura tratadas
- P-1A carga de trabalho probabilística em seu próprio namespace, com egress de rede apenas para o que ela precisa e sem nenhuma credencial para o armazenamento com autoridade. Um acréscimo à fronteira da aplicação, nunca um substituto dela.
- P-4Contexto de execução configurado uma vez por carga de trabalho; uma pipeline de traces amostrada, mantida separada da trilha de auditoria; procedência da configuração legível em cada pod.
- P-6Admissão no deploy e controles de liberação como superfícies de fence, com seus contornos característicos nomeados.
- P-8Revisões de configuração e de política que sobrevivem a rollouts, e um registro de decisão que nomeia a revisão quando duas estão ativas ao mesmo tempo.
- P-7Serviços externos alcançados por egress explícito, de modo que uma nova dependência é uma mudança de política que passa por revisão, e não uma linha de código.
- P-2, P-3Não tratados no nível da infraestrutura: são propriedades da aplicação, e o COADF os publica apenas como princípios.
Intenção de arquitetura
O Kubernetes traz fronteiras próprias (namespaces, network policy, admissão, rollout) e modos de falha próprios: objetos aceitos e não aplicados, reconciliação que acontece em algum momento posterior, duas versões do mesmo serviço respondendo ao mesmo tempo. Este perfil mapeia as propriedades do COADF sobre essas fronteiras sem tratar o Kubernetes como exigência do COADF, e sem deixar que um controle do cluster tome o lugar de um controle da aplicação.
A regra que atravessa todo o perfil: a infraestrutura pode tornar uma fronteira mais difícil de cruzar, e não pode fazê-la existir. Uma aplicação que grava a saída do modelo nas suas próprias tabelas com autoridade não é consertada por nenhuma network policy.
Correspondência tecnológica
| Propriedade de arquitetura | Cloud-native e Kubernetes |
|---|---|
| Fronteira probabilística | Um Deployment e um namespace separados; egress por NetworkPolicy; a credencial de escrita criada apenas onde o domínio roda; grants do banco de dados por carga de trabalho |
| Fence de admissão | ValidatingAdmissionPolicy (CEL, no próprio processo) ou OPA Gatekeeper (Rego, com auditoria dos recursos existentes) |
| Contexto de execução | Configuração do SDK do OpenTelemetry por carga de trabalho; uma pipeline do Collector para os traces |
| Trilha de auditoria | O armazenamento somente de inserção da própria aplicação, fora da pipeline de telemetria |
| Procedência da configuração | Anotações de revisão, ConfigMaps imutáveis nomeados pela revisão, imagens fixadas por digest; um controlador GitOps que registra a revisão sincronizada |
| Controle de liberação | Checks obrigatórios que não podem passar por terem sido pulados; ambientes de deploy; promoção por digest |
| Política | OPA como serviço ou sidecar, com a revisão do bundle nos logs de decisão; políticas de admissão para regras de infraestrutura |
Padrão de referência
Três namespaces: inference para o cliente do modelo e sua fronteira, model-serving para o endpoint do modelo, records para a entrada de propostas, o núcleo de domínio e o banco de dados. A página Fronteira probabilística desenha o mesmo sistema como um diagrama de cluster.
P-1 · Nenhuma rota até os registros
- Propósito
- Quando o lado probabilístico roda como carga de trabalho própria, não lhe dar rota alguma até o armazenamento com autoridade.
- Propriedade de arquitetura
- Isolamento de rede como imposição adicional, no nível da infraestrutura, da fronteira do P-1. Ele se soma à fronteira da aplicação e não a substitui.
# 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: 53O que ele omite de propósito
- O plugin de rede. Sem um que implemente NetworkPolicy, este objeto é aceito e não faz nada.
- Regras de ingress, e uma política de negação padrão para o namespace.
- Os rótulos dos pods de DNS, que variam entre clusters.
- Egress para um modelo hospedado fora do cluster, que precisa de uma regra própria.
Como verificar
Não executado para este Companion: o manifesto foi validado contra os esquemas do Kubernetes, o que prova sua forma e nada sobre a imposição. Para verificar a imposição, num cluster de teste com um plugin de rede que imponha a política, a partir de um pod de inferência: o endpoint do modelo responde e o banco de dados de registros não; apagada a política, o banco de dados responde, o que prova que foi a política que o bloqueou.
Modo de falha tratado
Uma NetworkPolicy aplicada a um cluster cujo plugin de rede não a impõe. O manifesto é válido, a revisão passa, e nada fica isolado.
Apoia-se em
P-6 · Um fence no momento do deploy
O ValidatingAdmissionPolicy é estável desde o Kubernetes 1.30 e roda dentro do API server, portanto não depende de nenhum webhook disponível. As mesmas regras podem ser escritas para o OPA Gatekeeper, que acrescenta uma auditoria dos recursos que já existem e ações de aplicação como dryrun e warn; os dois são válidos, e a propriedade não depende da escolha.
A regra precisa checar por inteiro aquilo que nomeia. Um teste que procura @sha256: em algum ponto da referência da imagem admite image@sha256: sem nada depois; esta política casa com um digest SHA-256 completo, e exige que a anotação de revisão contenha uma revisão, e não apenas que exista.
- Propósito
- Não admitir nenhum Deployment cujas imagens não estejam fixadas por um digest bem formado, ou que não consiga nomear, numa anotação não vazia, a versão da configuração de que veio.
- Propriedade de arquitetura
- Um estado proibido impede a transição, aqui a criação ou a atualização de um Deployment (P-6), e a procedência da configuração passa a ser uma propriedade de toda carga de trabalho em execução (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"O que ele omite de propósito
- Validação na aplicação. A admissão vê objetos da API e nunca as requisições que o serviço atende.
- Objetos que já existem. A admissão avalia as requisições à medida que são feitas, e acrescentar esta política não reavalia nada do que já está rodando.
- Pods criados diretamente, e outros tipos de carga de trabalho (StatefulSet, Job, CronJob, DaemonSet), que precisam, cada um, de um match próprio.
- Se a versão nomeada existe, ou se o digest é o que a integração contínua construiu. A regra verifica a forma de um digest, não sua origem.
Como verificar
Contra um servidor de API do Kubernetes real (um kube-apiserver 1.37 local e descartável, sem nós; cada caso, um dry run no lado do servidor): imagens fixadas por digest são admitidas, inclusive atrás de uma porta de registry e depois de uma tag; uma imagem só com tag, um digest vazio, um digest que não é hexadecimal e um digest de comprimento errado são recusados, assim como uma anotação de versão ausente, vazia ou em branco (tests/test_admission_policy.py). Com uma regra que só exige presença, contains('@sha256:') e um in simples, cinco desses casos são admitidos, e é por isso que a regra casa com o digest inteiro.
Modo de falha tratado
Premissas de liberação não verificadas: uma tag movida depois da revisão, ou um Deployment em execução que ninguém consegue associar à configuração a partir da qual foi renderizado.
P-4 e P-8 · Procedência da configuração no pod
- Propósito
- Tornar a versão da configuração visível no objeto, no template do pod e no nome de um ConfigMap imutável.
- Propriedade de arquitetura
- Uma nova versão é um rollout, e nenhum pod roda uma configuração que não consiga nomear. A versão do template de prompt que a chamada ao modelo informa (
prompt_revisionna fronteira em Python) tem aqui uma contraparte implantável.
# 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-3f9c2d1O que ele omite de propósito
- Sobreposição no rollout. Durante uma atualização gradual, pods antigos e novos atendem ao mesmo tempo, então duas versões ficam ativas simultaneamente; é o registro da decisão, e não o estado do deploy, que precisa nomear a versão.
- Secrets, probes, recursos e contexto de segurança.
- A service account e suas permissões.
Como verificar
Editar o texto do prompt sob o mesmo nome: o ConfigMap é imutável e a mudança é recusada. Criar um novo ConfigMap e atualizar o nome e as anotações: segue-se um rollout, e cada pod informa sua versão como service.version.
Modo de falha tratado
Ambientes rodando configurações diferentes sem procedência. Um ConfigMap lido por variáveis de ambiente só é aplicado quando os pods reiniciam, um montado como volume é aplicado em algum momento, e nesse intervalo ninguém consegue dizer qual configuração produziu uma dada resposta.
P-4 · A pipeline de traces não é a trilha de auditoria
Os SDKs do OpenTelemetry leem OTEL_PROPAGATORS e usam tracecontext,baggage por padrão, de modo que o contexto de execução atravessa as fronteiras entre serviços sem código. A identidade de auditoria não viaja assim: ela faz parte do contrato de cada mensagem, e as entradas de auditoria são escritas pela aplicação no seu próprio armazenamento.
- Propósito
- Mostrar uma pipeline de traces normal, com amostragem, e por que a trilha de auditoria nunca passa por uma.
- Propriedade de arquitetura
- A telemetria de execução e a trilha de auditoria são artefatos diferentes e prometem coisas diferentes. Elas se correlacionam pelo
trace_idde auditoria, e a trilha de auditoria nunca passa por uma pipeline configurada para descartar dados (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]O que ele omite de propósito
- Tail sampling, que exige que todos os spans de um trace cheguem à mesma instância do Collector.
- O backend de traces e sua retenção.
- Pipelines de logs e de métricas.
- Os percentuais. São configurações operacionais, fornecidas por expansão de variáveis de ambiente, e seus valores são irrelevantes para a propriedade de arquitetura.
Como verificar
otelcol-contrib validate aceita a configuração com os dois percentuais fornecidos pelo ambiente e a recusa quando eles faltam. Enviar um número conhecido de traces e contar o que chega: com qualquer amostragem que descarte traces, alguns não chegam, e é essa propriedade que desqualifica este caminho como trilha de auditoria.
Modo de falha tratado
Um trace presente apenas no backend de tracing: a pergunta “o que aconteceu com esta transação” é respondida a partir de um armazenamento que tem permissão para tê-lo descartado.
P-6 · Controles de liberação
O workflow define os checks e faz o seu job de resumo falhar quando um fence falha, é cancelado ou é pulado. Ele não consegue tornar esse job obrigatório: isso cabe à proteção de branch ou a um ruleset nas configurações do repositório, e sem isso o botão de merge ignora o resultado.
- Propósito
- Interromper o merge e a liberação quando um fence falha, com uma verificação obrigatória que continua vermelha quando um fence é pulado.
- Propriedade de arquitetura
- Um fence que falhou, foi cancelado ou foi pulado faz o job
fencesfalhar, e a liberação não roda (P-6). O workflow não consegue tornarfencesobrigatório: só a proteção de branch ou um ruleset nas configurações do repositório bloqueia um merge com base nele.
# 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 }}"O que ele omite de propósito
- O build do site em si;
make sitefaz as vezes dele. - As configurações de proteção de branch, que ficam nas configurações do repositório e não no workflow.
- Fixar actions por hash de commit, a prática mais forte. Aqui se usam tags de versão major, por legibilidade.
Como verificar
Fazer um job de fence falhar num branch de teste: o job fences falha e a liberação é pulada. Fazer um job de fence ser pulado, com um if: falso: o job fences falha mesmo assim, porque um job pulado reporta sucesso à proteção de branch e este job se recusa a contá-lo.
Modo de falha tratado
Uma verificação obrigatória que fica verde por ser pulada. O GitHub reporta um job pulado como sucesso, então um job obrigatório que depende de um fence com falha pode deixar o merge passar.
Modos de falha
Uma NetworkPolicy que nada aplica
Uma NetworkPolicy sem um plugin de rede que a implemente não tem efeito. O manifesto é válido, a revisão passa, e nada fica isolado.
Um hífen amplia a regra
Dentro de uma única entrada
to, umnamespaceSelectore umpodSelectorjuntos selecionam aqueles pods naqueles namespaces. Escritos como dois itens de lista, eles selecionam o namespace inteiro, ou aqueles pods no próprio namespace da política. A documentação do Kubernetes alerta exatamente para essa diferença de YAML.Admissão confundida com validação na aplicação
A admissão intercepta requisições ao API server: ela vê Deployments e Pods, nunca as requisições que o serviço atende nem as respostas que um modelo devolve. Ver a nota técnica.
Um fence que falha aberto
Um webhook cuja failure policy é
Ignoredeixa uma requisição passar quando o webhook não pode ser chamado. O dia em que o webhook está fora do ar é o dia em que a regra está desligada.Objetos existentes nunca checados de novo
A admissão julga as requisições à medida que chegam. Para LimitRange, o Kubernetes afirma que os pods já em execução continuam inalterados; da mesma forma, uma nova regra de admissão não diz nada sobre o que foi admitido antes dela. A auditoria do Gatekeeper existe para essa lacuna.
Uma tag movida depois da revisão
Digests são imutáveis; tags podem ser movidas para apontar para imagens diferentes. Uma imagem revisada pela tag não é necessariamente a imagem em execução.
Desvio de configuração que não se vê
Um ConfigMap consumido por variáveis de ambiente não é atualizado até o pod reiniciar, um ConfigMap montado é atualizado em algum momento, e um montado por
subPathnunca é atualizado. Três pods podem ter três configurações enquanto todos os manifestos nomeiam uma só.Duas revisões ativas durante um rollout
Rolling updates executam as versões antiga e nova ao mesmo tempo. Tudo o que precisa nomear uma revisão (uma decisão, uma extração, uma resposta) deve registrá-la no momento em que é produzido, e não deduzi-la do deployment depois.
A pipeline amostrada usada como registro
Um trace que não é amostrado não é exportado. Uma pipeline configurada para manter uma fração dos traces é correta para diagnóstico e não consegue responder a uma pergunta de auditoria.
Baggage que sai de casa
O OpenTelemetry alerta que o baggage pode ser propagado a destinatários não pretendidos, inclusive APIs de terceiros. Um identificador posto no baggage por conveniência viaja mais longe do que seu dono pretendia.
Uma revisão sincronizada lida como a revisão implantada
O
status.sync.revisiondo Argo CD é a revisão com a qual o estado ativo foi comparado pela última vez; o histórico de sincronização registra a revisão que cada sincronização de fato aplicou. As duas só coincidem enquanto a aplicação está sincronizada.Um controle por pessoa nomeada que o plano não aplica
Nos planos GitHub Free, Pro e Team, revisores obrigatórios em ambientes só estão disponíveis para repositórios públicos. Um repositório privado nesses planos tem o nome da configuração, e não o seu efeito.
Verificação
Teste de implantação ou de admissão
Passa quando: Contra um API server local descartável, o Deployment de exemplo é admitido em um namespace que carrega o label do binding, e o mesmo vale para digests atrás de uma porta de registry ou depois de uma tag.
Prova de dentes: Uma imagem só com tag, um digest vazio ou malformado, e uma revisão ausente, vazia ou em branco são, cada um, recusados pela política. Substituir as regras de digest e de revisão por checagens de presença: cinco desses casos são admitidos, e os testes falham.
Teste de integração
Passa quando: Não executado nesta revisão. A partir de um pod de inferência, com um plugin de rede que aplica as políticas: o endpoint do modelo e a entrada de propostas respondem, e a porta do banco de dados não.
Prova de dentes: Apagar a política: o banco de dados responde, o que prova que era a política, e não outra coisa, que o bloqueava.
Teste de contrato
Passa quando: Os manifestos são validados contra os esquemas do Kubernetes de cada versão minor suportada, em modo estrito, de modo que um campo grafado errado é um erro.
Prova de dentes: Grafar
podSelectorerrado: a validação estrita falha.Teste de contrato
Passa quando: A configuração do Collector é validada com o binário do Collector da versão implantada, com as porcentagens fornecidas pelo ambiente.
Prova de dentes: Grafar errado uma configuração de processor, ou deixar as porcentagens sem valor: a validação falha.
Teste de ponta a ponta
Passa quando: Um job de fence que falha faz o job de resumo falhar e pula a liberação; a proteção de branch lista o job de resumo como obrigatório.
Prova de dentes: Pular um job de fence em vez de fazê-lo falhar: o job de resumo falha mesmo assim, porque se recusa a contar um job pulado.
Evidência manual
Passa quando: A cada liberação, os digests das imagens e a revisão da configuração são registrados e comparados com o que o cluster informa.
Realizações alternativas
- Gatekeeper, Kyverno ou ValidatingAdmissionPolicy para regras de admissão. A propriedade é que a regra impede a transição e já foi vista fazendo isso; o motor é uma escolha.
- A política de autorização de um service mesh onde o egress precisa ser controlado por requisição, e não por porta.
- Controladores GitOps (Argo CD, Flux) como registro de qual revisão de configuração está aplicada, além das anotações nos objetos.
- Uma plataforma gerenciada sem Kubernetes. Toda propriedade deste perfil tem um equivalente ali: artefatos implantáveis separados, regras de rede, controles de deploy, revisões de configuração. O COADF não exige nenhuma das ferramentas citadas aqui.
Escolhas de compromisso
- Admissão no próprio processo versus um motor de políticas. O ValidatingAdmissionPolicy não precisa de componente extra e não pode ficar fora do ar separadamente do API server; o Gatekeeper acrescenta uma auditoria dos recursos existentes e aplicação em etapas, e é mais um sistema a operar.
- O isolamento de rede tem um preço: um plugin que aplique as políticas, políticas a manter, e falhas que parecem bugs da aplicação quando uma regra é restritiva demais.
- Deployments separados transformam uma fronteira em um contrato versionado que precisa continuar compatível ao longo dos rollouts, nas duas direções.
- A amostragem economiza custo e retira o valor de evidência. Convém mantê-la, e manter a trilha de auditoria em outro lugar.
Limitações
- Os manifestos foram validados contra os esquemas do Kubernetes para 1.35, 1.36 e 1.37; a política de admissão foi aplicada a um API server local descartável, sem nós, e exercitada por dry runs no servidor; a configuração do Collector foi validada e o workflow passou por lint. Nada rodou em um cluster com nós: a aplicação da network policy, os rollouts e o comportamento do Collector em execução não foram observados.
- Os exemplos omitem regras de ingress, security contexts, recursos, probes e secrets.
- O Kubernetes é uma forma de implantar essas propriedades. O COADF não o exige.
O que este perfil não estabelece
Seguir este perfil não estabelece conformidade regulatória, certificação nem avaliação da conformidade, e nada aqui é exigido pelo COADF. Um cluster que admite estes manifestos admitiu estes manifestos.
Ambiente de referência testado
- kubeconform 0.8.0 · validação estrita de esquema contra Kubernetes 1.35.0, 1.36.0 e 1.37.0; não aplicado a um cluster
- Kubernetes API server (envtest release) 1.37.0 · um kube-apiserver local descartável, com etcd e sem nós: a política de admissão aplicada e dez casos executados como dry runs no servidor; nada agendado, nenhuma aplicação de regras de rede
- OpenTelemetry Collector (contrib) 0.160.0 · otelcol-contrib validate
- actionlint 1.7.12 · sem shellcheck, portanto o shell dentro dos passos run não passou por lint
Fontes
- Kubernetes: Network Policies: prerequisites · documentação oficial · Kubernetes 1.37 · Verificado em 2026-09-11
- Kubernetes: Validating Admission Policy · documentação oficial · Kubernetes 1.37 · Verificado em 2026-09-11
- Kubernetes: Admission control: what are they · documentação oficial · Kubernetes 1.37 · Verificado em 2026-09-11
- Kubernetes: Dynamic admission control: failure policy · documentação oficial · Kubernetes 1.37 · Verificado em 2026-09-11
- Kubernetes: Limit Ranges: admission-time validation · documentação oficial · Kubernetes 1.37 · Verificado em 2026-09-11
- Kubernetes: Images: image names and digests · documentação oficial · Kubernetes 1.37 · Verificado em 2026-09-11
- Kubernetes: ConfigMaps: updates and immutability · documentação oficial · Kubernetes 1.37 · Verificado em 2026-09-11
- Kubernetes: Deployments: rolling update · documentação oficial · Kubernetes 1.37 · Verificado em 2026-09-11
- Kubernetes: Annotations · documentação oficial · Kubernetes 1.37 · Verificado em 2026-09-11
- Open Policy Agent Gatekeeper: Gatekeeper: audit · documentação oficial · Gatekeeper 3.23 · Verificado em 2026-09-11
- Open Policy Agent Gatekeeper: Gatekeeper: enforcement actions · documentação oficial · Gatekeeper 3.23 · Verificado em 2026-09-11
- OpenTelemetry: SDK environment variables: OTEL_PROPAGATORS · especificação · Specification 1.60.0 · Verificado em 2026-09-11
- OpenTelemetry: Sampling · documentação oficial · Verificado em 2026-09-11
- OpenTelemetry: Tracing SDK: sampling · especificação · Specification 1.60.0 · Verificado em 2026-09-11
- OpenTelemetry: Transforming telemetry · documentação oficial · Verificado em 2026-09-11
- OpenTelemetry Collector Contrib: Tail sampling processor · repositório do projeto · Verificado em 2026-09-11
- OpenTelemetry: Baggage: security considerations · documentação oficial · Verificado em 2026-09-11
- Argo CD: Application CRD: status.sync.revision and status.history · repositório do projeto · Argo CD 3.5.2 · Verificado em 2026-09-11
- GitHub: Workflow syntax: jobs.<job_id>.needs · documentação oficial · Verificado em 2026-09-11
- GitHub: Control jobs with conditions · documentação oficial · Verificado em 2026-09-11
- GitHub: Troubleshooting required status checks · documentação oficial · Verificado em 2026-09-11
- GitHub: Deployments and environments: required reviewers · documentação oficial · Verificado em 2026-09-11
- GitHub: About protected branches: require status checks before merging · documentação oficial · Verificado em 2026-09-11
- Open Container Initiative: Image specification, descriptors: SHA-256 digests · especificação · Verificado em 2026-09-11
- OpenTelemetry: Collector configuration: environment variables · documentação oficial · Verificado em 2026-09-11