Exercício - Atribuir uma política a um Cluster de Serviços Kubernetes do Azure
Agora você está pronto para configurar políticas e iniciativas do Azure para seu cluster do Serviço Kubernetes do Azure (AKS).
Nesta unidade, você implanta um pod não compatível e aplica uma Política do Azure que impõe o uso apenas de registros confiáveis. Em seguida, implante outro pod não compatível para ver o efeito da Política. Você aprende os passos para resolver problemas e compreender por que os pods não estão a ser criados. Você também implementa a iniciativa para os padrões restritos de segurança de pod no cluster Kubernetes, direcionados para cargas de trabalho baseadas em Linux.
Observação
Este exercício é opcional. Se quiser concluir este exercício, terá de criar uma subscrição do Azure antes de começar. Se você não tiver uma conta do Azure ou não quiser criar uma no momento, leia as instruções para entender as informações que estão sendo apresentadas.
Implantar um pod não compatível no cluster
Começamos implantando uma imagem diretamente do Docker Hub no cluster. A primeira etapa é entrar no cluster.
No Cloud Shell, inicie sessão no cluster AKS.
az aks get-credentials -n videogamecluster -g videogamergExecute o código a seguir para criar um pod simple-nginx do Docker Hub.
cat <<EOF | kubectl apply -f - apiVersion: apps/v1 kind: Deployment metadata: name: simple-nginx labels: app: nginx spec: selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: simple-nginx image: docker.io/library/nginx:stable resources: requests: cpu: 100m memory: 100Mi limits: cpu: 120m memory: 120Mi ports: - containerPort: 80 EOFExecute o código a seguir para implantar o serviço com o objetivo de expor a implantação.
cat <<EOF | kubectl create -f - apiVersion: v1 kind: Service metadata: name: simple-nginx labels: app: nginx spec: type: LoadBalancer ports: - port: 80 selector: app: nginx EOFListe todos os serviços implantados.
kubectl get servicesCopie o IP Externo do serviço simple-nginx e cole-o no seu navegador para verificar se o serviço funciona como esperado.
Se o IP externo estiver listado como
<pending>, execute novamente o comando. Leva tempo para alocar um endereço IP público para sua carga de trabalho.
Aplicar a Política do Azure ao cluster AKS
Você implantou com êxito sua carga de trabalho em um cluster que não tem nenhuma imposição de política nele. Agora você pode adicionar uma Política ao cluster e ver como isso o afeta.
Atribuir uma política
Você deseja garantir que apenas imagens de determinados registros sejam permitidas no cluster. Você precisa criar uma nova definição de política e, em seguida, atribuí-la a um escopo. Neste caso, o escopo é o nosso videogamerg grupo de recursos. As políticas podem ser criadas e atribuídas por meio do portal do Azure, do Azure PowerShell ou da CLI do Azure. Este exercício leva-o através da criação de uma política no portal.
Encontre as definições de política internas para gerenciar seu cluster usando o portal do Azure com as etapas a seguir. Nesse caso, você está aplicando a política "somente imagens permitidas".
No painel esquerdo da página Política do Azure, selecione Definições.
Na caixa de listagem suspensa Categoria, use Selecionar todos os para limpar o filtro e, em seguida, selecione Kubernetes.
Selecione a os contêineres de cluster do Kubernetes devem usar apenas imagens permitidas definição de política.
Selecione o botão Atribuir.
Defina o Escopo do para o grupo de recursos do cluster Kubernetes que você criou, que neste caso é o videogamerg grupo de recursos.
Insira o seguinte no campo Allowed container image regex e selecione o botão Revisar + criar
.+\.azurecr\.io/.+$
- Selecione o botão Criar.
Agora que a nova política está habilitada, pode selecionar Atribuições para ver a política atribuída e selecionar a atribuição de política que criou.
A sua atribuição de política deve assemelhar-se à imagem a seguir. O efeito é definido como negar por padrão. Isso significa que apenas imagens hospedadas no Registro de Contêiner do Azure podem ser implantadas no cluster.
Atribuir uma iniciativa de política
Agora que a sua política foi atribuída com êxito, atribua uma iniciativa antes de testar as políticas. Uma iniciativa de Política do Azure é uma coleção de definições de Política do Azure, ou regras, que são agrupadas em direção a uma meta ou finalidade específica. As iniciativas do Azure simplificam o gerenciamento de suas políticas agrupando um conjunto de políticas, logicamente, como um único item.
As iniciativas podem ser atribuídas da mesma forma que as políticas são atribuídas. Siga estas etapas para atribuir a iniciativa "Kubernetes cluster pod security restricted standards for Linux-based workloads".
- Volte à página de Política no portal Azure .
- No painel esquerdo da página Política do Azure, selecione Definições.
- Na caixa de listagem suspensa Categoria, use Selecionar todos os para limpar o filtro e, em seguida, selecione Kubernetes.
- Selecione a padrões restritos de segurança de pod de cluster do Kubernetes para cargas de trabalho baseadas em Linux definição de iniciativa. Dedique algum tempo a rever as várias políticas que fazem parte da iniciativa.
- Selecione o botão Atribuir no canto superior esquerdo da tela.
- Defina o Escopo como o grupo de recursos do cluster Kubernetes que você criou, que neste caso é o videogamerg. Preencha o restante do formulário como fez na etapa anterior e selecione Revisão + criar.
- Selecione o botão Criar.
Aqui é possível encontrar a atribuição da política novamente ao clicar em Política e selecionar Atribuições. Clicar na atribuição de política que você criou mostra que o efeito está definido como Auditoria neste caso.
Testar a Política do Azure
Agora que a Política de restrição está atribuída ao cluster, você pode executar um teste para ver se a Política funciona. Para demonstrar, vamos criar uma nova implantação e ver se a implantação funciona. Começamos criando um novo arquivo de manifesto do kubernetes e implantando-o.
Importante
Tenha em atenção que as atribuições da Política podem demorar até 30 minutos a entrar em vigor. Devido a esse atraso, nas etapas a seguir a validação da política pode ser bem-sucedida e a implantação não falhará. Se isso acontecer, permita mais tempo e tente novamente a sua implementação.
Você pode verificar se a atribuição de política está em vigor executando o seguinte comando.
kubectl get ConstraintTemplates
Você deve ver um resultado semelhante à saída abaixo. Se vir k8sazurecontainerallowedimages na lista, sabe que a sua política está em vigor.
k8sazureallowedcapabilities 40m
k8sazureallowedseccomp 20m
k8sazureallowedusersgroups 40m
k8sazureblockautomounttoken 40m
k8sazureblockdefault 40m
k8sazureblockhostnamespace 40m
k8sazurecontainerallowedimages 40m
k8sazurecontainerallowedports 40m
k8sazurecontainerlimits 40m
k8sazurecontainernoprivilege 40m
k8sazurecontainernoprivilegeescalation 40m
k8sazuredefenderblockvulnerableimages 40m
k8sazuredisallowedcapabilities 40m
k8sazureenforceapparmor 40m
k8sazurehostfilesystem 40m
k8sazurehostnetworkingports 40m
k8sazureingresshttpsonly 40m
k8sazurereadonlyrootfilesystem 40m
k8sazureserviceallowedports 40m
k8sazurevolumetypes 20m
Crie outra implementação e serviço
nginxusando o código a seguir.cat <<EOF | kubectl create -f - apiVersion: apps/v1 kind: Deployment metadata: name: second-simple-nginx labels: app: second-nginx spec: selector: matchLabels: app: second-nginx template: metadata: labels: app: second-nginx spec: containers: - name: second-simple-nginx image: docker.io/library/nginx:stable resources: requests: cpu: 100m memory: 100Mi limits: cpu: 120m memory: 120Mi ports: - containerPort: 80 EOFCriar o serviço
cat <<EOF | kubectl create -f - apiVersion: v1 kind: Service metadata: name: second-simple-nginx labels: app: second-nginx spec: type: LoadBalancer ports: - port: 80 selector: app: second-nginx EOFAgora podemos verificar se o pod foi criado.
kubectl get pods
Na saída a seguir, mesmo que pareça que a implantação foi criada, o pod não é criado. A política que você criou bloqueou a implantação. No entanto, o pod que foi criado antes da atribuição da Política não foi interrompido. A Política também não impediu que o serviço fosse criado. Se você tentar abrir o EXTERNAL-IP em um navegador, não obterá resposta, o que mostra ainda mais que a implantação não foi bem-sucedida.
NAME READY STATUS RESTARTS AGE
simple-nginx-66d884c498-msbpc 1/1 Running 0 63m
Diagnosticar por que o pod não foi implantado
Na seção anterior, notamos que o segundo pod não foi implantado. Nesta seção, usamos a linha de comando para diagnosticar o motivo.
Primeiro, vamos descrever a implantação. Vemos que o ReplicaSet foi criado, mas as réplicas falharam em ser criadas.
kubectl get replicasetsVocê deve obter uma saída semelhante ao exemplo a seguir:
NAME DESIRED CURRENT READY AGE second-simple-nginx-64969b4566 1 0 0 8m45s simple-nginx-66d884c498 1 1 1 72mEm seguida, descrevemos o ReplicaSet que falhou. Copie o nome do ReplicaSet que começa com
second-simple-nginx, atualize o seguinte comando com esse valor e execute o comando.kubectl describe replicaset <ReplicaSet name>A saída do comando mostra que as réplicas falharam devido à Política.
Warning FailedCreate 3m9s (x18 over 14m) replicaset-controller Error creating: admission webhook "validation.gatekeeper.sh" denied the request: [azurepolicy-container-allowed-images-bcfbd5e1e78f7c8b4104] Container image docker.io/library/nginx:stable for container second-simple-nginx has not been allowed.
Exclua a implantação para se preparar para a próxima etapa.
kubectl delete deployment second-simple-nginx
Redistribuir os pods usando uma imagem do Azure Container Registry
Agora que você sabe que a Política impede que imagens do hub do Docker sejam criadas em seu cluster com base em sua Política. Vamos tentar reimplantar a mesma carga de trabalho usando uma imagem do Azure Container Registry (ACR). Nesta seção, você cria um Registro de Contêiner do Azure. Em seguida, copie a imagem nginx do hub do Docker para o novo registro e tente reimplantar o pod do seu registro de contêiner. Usamos a CLI do Azure para criar o registro de contêiner.
Volte para o Shell de Nuvem no portal do Azure e insira os seguintes comandos para criar um novo registo de contêiner.
ACR_NAME=videogameacr$RANDOM az acr create --name $ACR_NAME \ --resource-group videogamerg \ --sku PremiumImporte a imagem do Docker Hub para o novo registro de contêiner.
az acr import --name $ACR_NAME --source docker.io/library/nginx:stable --image nginx:v1Verifique se a imagem foi importada. Você deve ver nginx na lista de resultados.
az acr repository list --name $ACR_NAMEVincule seu cluster AKS ao registro de contêiner que você criou.
az aks update -n videogamecluster -g videogamerg --attach-acr $ACR_NAMEAgora, crie a implantação usando seu registro de contêiner recém-criado executando o seguinte comando.
cat <<EOF | kubectl apply -f - apiVersion: apps/v1 kind: Deployment metadata: name: second-simple-nginx labels: app: second-nginx spec: selector: matchLabels: app: second-nginx template: metadata: labels: app: second-nginx spec: containers: - name: second-simple-nginx image: ${ACR_NAME}.azurecr.io/nginx:v1 resources: requests: cpu: 100m memory: 100Mi limits: cpu: 120m memory: 120Mi ports: - containerPort: 80 EOFObtenha o EXTERNAL-IP para que possas verificar se o serviço está a ser executado no cluster.
kubectl get pods kubectl get services
Copie o endereço IP externo e cole-o no navegador. Você vê que a página agora carrega.
Usar políticas para impor padrões
Nesta unidade, você viu como usar políticas para garantir que seu cluster permita que apenas Imagens do Registro de Contêiner do Azure sejam implantadas. Você também viu como adicionar uma das iniciativas internas que podem ajudar a controlar facilmente seu cluster e torná-lo mais seguro. No entanto, você viu que o pod que foi implantado antes da aplicação da política ainda está em execução. Na próxima unidade, você verá como podemos verificar a conformidade dos pods em execução no cluster.