|
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. |
Configurando políticas
Ignorando namespaces para uma política específica
Por padrão, as políticas se aplicam a todos os namespaces para os quais o PolicyServer está configurado.
Se você quiser que uma política tenha como alvo apenas namespaces específicos, pode implantar vários AdmissionPolicies em cada namespace.
Outra opção é configurar ClusterAdmissionPolicies definindo seu spec.namespaceSelector (veja documentos do CRD). O spec.namespaceSelector decide se deve executar a política em um objeto, com base em se o namespace desse objeto corresponde ao seletor.
Por exemplo, aqui está uma política que tem como alvo apenas os namespaces kube-system e my-namespace:
---
apiVersion: policies.kubewarden.io/v1
kind: ClusterAdmissionPolicy
metadata:
name: psa-enforcer-privileged-namespaces
spec:
module: registry://ghcr.io/kubewarden/policies/psa-label-enforcer:v1.0.3
rules:
- apiGroups: [""]
apiVersions: ["v1"]
resources: ["namespaces"]
operations:
- CREATE
- UPDATE
mutating: true
namespaceSelector:
matchExpressions:
- key: "kubernetes.io/metadata.name"
operator: In
values: [kube-system, my-namespace]
settings:
modes:
enforce: "privileged"Aqui está uma política que tem como alvo todos os namespaces, exceto os kube-system e my-namespace:
---
apiVersion: policies.kubewarden.io/v1
kind: ClusterAdmissionPolicy
metadata:
name: psa-enforcer-default-mode
spec:
module: registry://ghcr.io/kubewarden/policies/psa-label-enforcer:v1.0.3
rules:
- apiGroups: [""]
apiVersions: ["v1"]
resources: ["namespaces"]
operations:
- CREATE
- UPDATE
mutating: true
namespaceSelector:
matchExpressions:
- key: "kubernetes.io/metadata.name"
operator: NotIn
values: [kube-system, my-namespace]
settings:
modes:
enforce: "restricted"Mensagem de rejeição personalizada
Quando uma política rejeita um recurso, a mensagem exibida ao usuário é a que foi escrita pelo autor da política. Às vezes, os operadores de cluster podem querer definir uma mensagem de rejeição personalizada. Por exemplo, isso pode ser usado para apontar para uma wiki interna ou para fornecer um código de erro mais específico.
O campo message nos tipos ClusterAdmissionPolicy e AdmissionPolicy pode ser usado para alcançar isso.
|
|
O campo message permite que os operadores de cluster definam uma mensagem de rejeição personalizada que substitui a retornada pela política. Ao usar esta configuração, a mensagem de rejeição original pode ser encontrada no campo causes da resposta.
apiVersion: policies.kubewarden.io/v1
kind: ClusterAdmissionPolicy
metadata:
name: pod-privileged-with-message
spec:
module: registry://ghcr.io/kubewarden/policies/pod-privileged:1.0.2
policyServer: default
mode: protect
message: "Nops! You cannot do that"
settings: {}
rules:
- apiGroups:
- ""
apiVersions:
- v1
resources:
- "*"
operations:
- CREATE
mutating: falseVocê pode obter os detalhes completos de um pedido de admissão rejeitado aumentando o nível de verbosidade do kubectl:
$ kubectl -v4 run pod-privileged2 --image=registry.k8s.io/pause --privileged
I0612 16:32:43.647601 48424 cert_rotation.go:137] Starting client certificate rotation controller
I0612 16:32:43.662550 48424 helpers.go:246] server response object: [{
"metadata": {},
"status": "Failure",
"message": "admission webhook \"clusterwide-pod-privileged-with-message.kubewarden.admission\" denied the request: Nops! You cannot do that",
"details": {
"causes": [
{
"message": "Privileged container is not allowed"
}
]
},
"code": 400
}]
Negando um resultado de política ao envolvê-lo em um PolicyGroup
Às vezes, ao usar uma política, ela ainda não implementa a lógica inversa do que você precisa.
Por exemplo, você quer usar o priority-class política para rejeitar um conjunto de classes de prioridade. Mas no momento da escrita, a priority-class política suporta apenas listas de permissão, não listas de negação.
Um padrão comum, então, é envolver sua política em um AdmissionPolicyGroup ou ClusterAdmissionPolicyGroup, e negar o resultado da política em seu spec.expression.
Por exemplo, vamos supor que queremos que os usuários usem todas as classes de prioridade definidas dentro do cluster, exceto por uma das seguintes: low-priority, med-priority e high-priority.
Atualmente, as configurações da política permitem expressar apenas a lista de classes de prioridade permitidas. A seguinte política de grupo supera essa limitação.
apiVersion: policies.kubewarden.io/v1
kind: AdmissionPolicyGroup
metadata:
name: priority-class-denylist
namespace: your-namespace # or use a CLusterAdmissionPolicyGroup and set spec.namespaceSelector
spec:
rules:
- apiGroups: [""]
apiVersions: ["v1"]
resources: ["pods"]
operations: ["CREATE", "UPDATE"]
- apiGroups: [""]
apiVersions: ["v1"]
resources: ["replicationcontrollers"]
operations: ["CREATE", "UPDATE"]
- apiGroups: ["apps"]
apiVersions: ["v1"]
resources: ["deployments", "replicasets", "statefulsets", "daemonsets"]
operations: ["CREATE", "UPDATE"]
- apiGroups: ["batch"]
apiVersions: ["v1"]
resources: ["jobs", "cronjobs"]
operations: ["CREATE", "UPDATE"]
policies:
is_a_denied_priority_class:
module: ghcr.io/kubewarden/policies/priority-class-policy:v1.0.4
settings:
allowed_priority_classes:
- low-priority
- med-priority
- high-priority
expression: "!is_a_denied_priority_class()" # negated result
message: "the Pod is using a priorityClass that is not allowed"