|
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. |
Políticas brutas
A partir de v1.9.0, SUSE Security Admission Controller suporta a capacidade de escrever e executar políticas fora de um cluster Kubernetes, como um mecanismo genérico de avaliação de políticas.
O Policy Server expõe o endpoint /validate_raw que pode ser usado para validar documentos JSON arbitrários contra uma política Admission Controller.
Para este guia, usaremos as seguintes políticas brutas:
|
Por favor, certifique-se de que o autor da política marcou a política como |
Executando o servidor de políticas fora do Kubernetes
O Policy Server pode ser executado fora do Kubernetes como um contêiner autônomo.
Primeiro, crie um arquivo policies.yml com o seguinte conteúdo:
raw-validation:
module: ghcr.io/kubewarden/tests/raw-validation-policy:v0.1.0
settings:
validUsers:
- alice
- bob
validActions:
- read
- write
validResources:
- orders
- products
raw-mutation:
module: ghcr.io/kubewarden/tests/raw-mutation-policy:v0.1.0
allowedToMutate: true
settings:
forbiddenResources:
- privateResource
- secretResource
defaultResource: publicResourcePara iniciar o servidor de políticas:
# Create a docker volume to store the policies
docker volume create --driver local \
--opt type=tmpfs \
--opt device=tmpfs \
--opt o=ui=65533 \
policy-store
# Start the policy server
docker run --rm -it \
-p 3000:3000 \
-v $(pwd)/policies.yml:/policies.yml \
-v policy-store:/registry \
ghcr.io/kubewarden/policy-server:1.9.0 \
--ignore-kubernetes-connection-failure=true
a flag --ignore-kubernetes-connection-failure=true é necessária para iniciar o servidor de políticas sem o Kubernetes.
No entanto, é possível iniciar o Policy Server com/dentro do Kubernetes e usar o endpoint de validação bruta.
Políticas brutas podem acessar capacidades sensíveis ao contexto, como políticas padrão.
|
Executando um Policy Server dentro do Kubernetes sem o controlador Admission Controller
Não é possível usar uma instância do Policy Server gerenciada pelo controlador Admission Controller para hospedar políticas brutas. O controlador não permitirá que o usuário altere o ConfigMap do Policy Server para adicionar uma política bruta, pois tentará reconciliá-la revertendo as alterações. Por causa disso, um servidor de políticas dedicado deve ser iniciado.
Crie um arquivo policy-server.yaml com o seguinte conteúdo:
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: policy-server-deployment
spec:
replicas: 1
selector:
matchLabels:
app: policy-server
template:
metadata:
labels:
app: policy-server
spec:
containers:
- name: policy-server
image: ghcr.io/kubewarden/policy-server:v1.9.0
ports:
- containerPort: 3000
volumeMounts:
- name: policy-store
mountPath: /registry
- name: policies-config
mountPath: /policies.yml
subPath: policies.yml
volumes:
- name: policy-store
emptyDir: {}
- name: policies-config
configMap:
name: policies-configmap
---
apiVersion: v1
kind: Service
metadata:
name: policy-server-service
spec:
selector:
app: policy-server
ports:
- protocol: TCP
port: 3000
targetPort: 3000
---
apiVersion: v1
kind: ConfigMap
metadata:
name: policies-configmap
data:
policies.yml: |
raw-validation:
module: ghcr.io/kubewarden/tests/raw-validation-policy:v0.1.0
settings:
validUsers:
- alice
- bob
validActions:
- read
- write
validResources:
- orders
- products
raw-mutation:
module: ghcr.io/kubewarden/tests/raw-mutation-policy:v0.1.0
allowedToMutate: true
settings:
forbiddenResources:
- privateResource
- secretResource
defaultResource: publicResourceAplique a configuração:
kubectl apply -f policy-server.yaml|
A instância do Policy Server implantada terá acesso aos recursos do Kubernetes que podem ser usados por políticas contextuais. O nível de acesso aos recursos do Kubernetes é determinado pela conta de serviço usada para executar a carga de trabalho do servidor de políticas. No exemplo anterior, nenhuma conta de serviço é definida dentro da especificação de implantação; portanto, a conta de serviço |
Usando o endpoint validate_raw
Validação
O endpoint de validação bruta está exposto em /validate_raw e aceita requisições POST.
Como implantamos um serviço, podemos configurar um port-forward para acessá-lo com kubectl port-forward service/policy-server-service 3000:3000 -n default.
Vamos tentar validar um documento JSON contra a política raw-validation:
curl -X POST \
http://localhost:3000/validate_raw/raw-validation \
-H 'Content-Type: application/json' \
-d '{
"request": {
"user": "alice",
"action": "read",
"resource": "customers"
}
}'A requisição não será aceita, uma vez que alice não recebeu acesso ao recurso customers:
{
"response": {
"uid": "",
"allowed": false,
"auditAnnotations": null,
"warnings": null
}
}Vamos tentar novamente com um recurso válido:
curl -X POST \
http://localhost:3000/validate_raw/raw-validation \
-H 'Content-Type: application/json' \
-d '{
"request": {
"user": "alice",
"action": "read",
"resource": "orders"
}
}'Desta vez, a requisição será aceita:
{
"response": {
"uid": "",
"allowed": true,
"auditAnnotations": null,
"warnings": null
}
}|
Se o campo |
Mutação
Agora, vamos tentar mutar um documento JSON contra a política raw-mutation:
curl -X POST \
http://localhost:3000/validate_raw/raw-mutation \
-H 'Content-Type: application/json' \
-d '{
"request": {
"user": "alice",
"action": "read",
"resource": "privateResource"
}
}'A requisição será mutada e a resposta conterá um JSONPatch:
{
"response": {
"uid": "",
"allowed": true,
"patchType": "JSONPatch",
"patch": "W3sib3AiOiJyZXBsYWNlIiwicGF0aCI6Ii9yZXNvdXJjZSIsInZhbHVlIjoicHVibGljUmVzb3VyY2UifV0=",
"auditAnnotations": null,
"warnings": null
}
}