|
Este documento foi traduzido usando tecnologia de tradução automática de máquina. Sempre trabalhamos para apresentar traduções precisas, mas não oferecemos nenhuma garantia em relação à integridade, precisão ou confiabilidade do conteúdo traduzido. Em caso de qualquer discrepância, a versão original em inglês prevalecerá e constituirá o texto official. |
|
Esta é uma documentação não divulgada para Admission Controller 1.34-dev. |
Criando uma nova política
Você pode criar uma política de exemplo que ajuda a entender os conceitos importantes.
|
Há um kubewarden/opa-policy-template que você pode usar para portar uma política existente. |
A política
Você vai criar uma política que avalia qualquer tipo de recurso que possua namespace.
Seu objetivo é proibir a criação de qualquer recurso se o namespace alvo for default. Caso contrário, a solicitação é aceita.
Comece criando um diretório chamado opa-policy.
Crie um diretório chamado data no diretório opa-policy.
Este diretório contém os objetos AdmissionReview registrados do servidor da API do Kubernetes.
Eles foram reduzidos para simplificar o exercício, permitindo que você se concentre nos aspectos que realmente importam.
Crie um arquivo default-ns.json com o seguinte conteúdo dentro do diretório data:
{
"apiVersion": "admission.k8s.io/v1",
"kind": "AdmissionReview",
"request": {
"uid": "1299d386-525b-4032-98ae-1949f69f9cfc",
"operation": "CREATE",
"object": {
"kind": "Pod",
"apiVersion": "v1",
"metadata": {
"name": "nginx",
"namespace": "default",
"uid": "04dc7a5e-e1f1-4e34-8d65-2c9337a43e64"
}
}
}
}
Isso simula a criação de uma operação de pod dentro do namespace default.
Agora, crie outro exemplo de solicitação em other-ns.json dentro do diretório data:
{
"apiVersion": "admission.k8s.io/v1",
"kind": "AdmissionReview",
"request": {
"uid": "1299d386-525b-4032-98ae-1949f69f9cfc",
"operation": "CREATE",
"object": {
"kind": "Pod",
"apiVersion": "v1",
"metadata": {
"name": "nginx",
"namespace": "other",
"uid": "04dc7a5e-e1f1-4e34-8d65-2c9337a43e64"
}
}
}
}
Você pode ver que isso simula outra solicitação de criação de pod, desta vez sob um namespace chamado other.
Volte para o seu diretório opa-policy e comece a escrever sua política Rego.
Neste diretório, crie um arquivo chamado request.rego no diretório opa-policy.
O nome pode ser qualquer um, mas você usará isso para este exercício.
Este é um arquivo Rego que contém código utilitário relacionado à solicitação/resposta em si.
Em particular, ele permite simplificar seu código de política e reutilizar essa parte comum em diferentes políticas.
O conteúdo é:
package policy
import data.kubernetes.admission
main = {
"apiVersion": "admission.k8s.io/v1",
"kind": "AdmissionReview",
"response": response,
}
response = {
"uid": input.request.uid,
"allowed": false,
"status": {"message": reason},
} {
reason = concat(", ", admission.deny)
reason != ""
} else = {
"uid": input.request.uid,
"allowed": true,
} {
true
}
Você não precisa, neste momento, entrar em detalhes sobre o código Rego. Você pode aprender sobre isso em seu site.
Neste caso, ele retorna allowed: true ou allowed: false.
Isso depende de se o outro pacote, data.kubernetes.admission, tem alguma declaração deny que avalia para true.
Se alguma data.kubernetes.admission.deny avaliar para true, a response aqui avalia para o primeiro bloco.
Caso contrário, ela avalia para o segundo bloco, levando à aceitação.
Como nenhum bloco deny avaliou para true, isso significa que a política está aceitando a solicitação.
Isso é apenas o shell da política, a utilidade.
Agora, você cria outro arquivo, chamado, por exemplo, policy.rego dentro do nosso diretório opa-policy com este conteúdo:
package kubernetes.admission
deny[msg] {
input.request.object.metadata.namespace == "default"
msg := "it is forbidden to use the default namespace"
}
Esta é a parte importante da sua política.
A declaração deny avalia para true se todas as declarações dentro dela avaliam para true.
Neste caso, há apenas uma declaração, verificando se o namespace é default.
Por design do Open Policy Agent,
input possui o objeto consultável com o objeto AdmissionReview,
portanto podemos inspecioná-lo de forma conveniente.
Se tudo correr bem, sua árvore deve parecer como o seguinte:
.
├── data
│ ├── default-ns.json
│ └── other-ns.json
├── policy.rego
└── request.rego
1 directory, 4 files