Use Network Policy in ACK Serverless clusters - Container Service for Kubernetes: Central de Documentação do Alibaba Cloud

Ative a Network Policy em ACK Serverless clusters para controlar o tráfego no nível de pod com o add-on Poseidon.

Pré-requisitos

Um ACK managed cluster ou ACK dedicated cluster deve estar criado. Consulte Create an ACK managed cluster ou Create an ACK dedicated cluster (Discontinued).
Importante
Em clusters ACK managed cluster Pro e ACK Serverless Pro, a Network Policy é implementada por add-ons diferentes.
- Em um ACK managed cluster Pro (para nós que não são elastic container instances), a Network Policy é implementada pelo plugin de rede Terway. Consulte Enable Network Policy in ACK clusters.
- Em elastic container instances (ECIs) de ACK Serverless clusters e ACK managed Pro clusters, a Network Policy é implementada pelo add-on Poseidon.
O add-on ACK Virtual Node deve estar atualizado para a versão v2.10.0 ou posterior. Consulte Manage components.
Um security group is configured for the cluster.
kubectl access to the cluster is configured.

Limitações

A Network Policy é compatível apenas com clusters ACK Serverless Pro e ACK managed cluster Pro.
A Network Policy não oferece suporte a endereços IPv6.
O campo endPort em uma NetworkPolicy não é compatível.
As regras de NetworkPolicy usam seletores de rótulo para fazer correspondência com namespaces ou pods. Uma quantidade excessiva de recursos NetworkPolicy torna a propagação de regras mais lenta e dificulta o gerenciamento e a solução de problemas. Limite os recursos NetworkPolicy a menos de 40 por cluster.

Etapa 1: Ativar a Network Policy

Instale o add-on Poseidon para ativar a Network Policy em um ACK Serverless Pro cluster.

Instale o add-on Poseidon.
1. Faça logon no console do ACK. No painel de navegação à esquerda, clique em Clusters.
2. Na página Clusters, clique em o nome do seu cluster. No painel de navegação à esquerda, clique em Components and Add-ons .
3. Na página Components and Add-ons, clique em Install. Na aba Networking, localize o cartão Poseidon e clique em Next.
4. Na caixa de diálogo Install Component, selecione Enable NetworkPolicy for ACS/ECI Instances, clique em Next e depois clique em OK.
  
  Após a instalação, Installed aparece no cartão.

Etapa 2: Criar e testar uma aplicação nginx

Usar o console

Faça logon no console do ACK. No painel de navegação à esquerda, clique em Clusters.
Na página Clusters, clique em o nome do cluster de destino e, no painel de navegação à esquerda, escolha Workloads > Deployments.

Na página Deployments, clique em Create from Image. No assistente Create, crie uma aplicação chamada nginx e exponha-a usando um Service. Após configurar a aplicação, clique em Create.

Para este exemplo, configure apenas os itens a seguir para a aplicação Nginx e mantenha as configurações padrão dos demais parâmetros. Para mais informações sobre as configurações, consulte Create a stateless workload (Deployment).

Item de configuração		Descrição	Valor de exemplo
Basic Information	Name	Um nome personalizado.	nginx
Basic Information	Replicas	Defina conforme necessário.	1
Container	Image Name	O nome da imagem usada para iniciar o contêiner.	nginx:latest
Advanced	Services	À direita de Services, clique em Create para definir os itens de configuração do service.	Name: nginx
			Service Type: Cluster IP SLB Node Port
			Port Mapping: Name: nginx Service Port: 80 Container Port: 80 Protocol: TCP

Na página Deployments, clique em Create from Image. No assistente Create, crie uma aplicação cliente chamada busybox para testar o acesso ao Service nginx criado na etapa anterior.

Para este exemplo, configure apenas os itens a seguir para a aplicação cliente busybox e mantenha as configurações padrão dos demais parâmetros. Para mais informações sobre as configurações, consulte Create a stateless workload (Deployment).

Item de configuração		Descrição	Valor de exemplo
Basic Information	Name	Um nome personalizado.	busybox
Basic Information	Replicas	Defina um valor conforme necessário.	1
Container	Image Name	O nome da imagem usada para iniciar o contêiner.	busybox:latest
Container	Container Start Parameter	Nenhum	Selecione stdin e tty

Verifique se a aplicação cliente busybox consegue acessar o Service Nginx.
1. Na página Deployments, clique em o nome da aplicação busybox.
2. Na aba Pods, localize o pod busybox-{valor de hash} e clique em Terminal na coluna Actions.
3. No terminal de linha de comando do busybox, execute o comando wget nginx para testar o acesso ao Nginx.
  
  A saída indica que o busybox consegue acessar o Service Nginx.

Usar a CLI

Execute os comandos a seguir para criar uma aplicação Nginx e expô-la usando um Service chamado nginx.

Crie uma aplicação Nginx:

kubectl run nginx --image=nginx

Saída esperada:

pod/nginx created

Verifique se o pod foi iniciado:

kubectl get pod

Saída esperada:

NAME                     READY   STATUS    RESTARTS   AGE
nginx                    1/1     Running   0          45s

Crie um Service chamado nginx:

kubectl expose pod nginx --port=80

Saída esperada:

service/nginx exposed

Visualize o Service:

kubectl get service

Saída esperada:

NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   172.XX.XX.1     <none>        443/TCP   30m
nginx        ClusterIP   172.XX.XX.48    <none>        80/TCP    12s

Execute o comando a seguir para criar um pod chamado busybox e acessar o Service chamado nginx.

kubectl run busybox --rm -ti --image=busybox /bin/sh

Saída esperada:

If you don't see a command prompt, try pressing enter.
/ #
/ #

Acesse o nginx:

If you don't see a command prompt, try pressing enter.
/ #
/ # wget nginx  # Enter wget nginx here.

Saída esperada:

Connecting to nginx (172.XX.XX.48:80)
saving to 'index.html'
index.html           100% |****************************************************************************************************************************************************|   612  0:00:00 ETA
'index.html' saved

Etapa 3: Usar uma network policy

Aplique recursos NetworkPolicy para restringir o tráfego de pods por rótulo, bloco CIDR, destino de saída ou acesso à rede pública.

Cenário 1: Restringir o acesso a um service apenas para aplicações com rótulos específicos usando uma network policy

Execute o comando vim policy.yaml para criar um arquivo chamado policy.yaml e preencha-o com o seguinte modelo YAML.

vim policy.yaml

A seguir está o conteúdo do arquivo YAML.

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: access-nginx
spec:
  podSelector:
    matchLabels:
      run: nginx
  ingress:
  - from:
    - podSelector:
        matchLabels:
          access: "true"

Execute o comando a seguir para criar uma network policy a partir do arquivo policy.yaml.
```
kubectl apply -f policy.yaml 
```
Saída esperada:
```
networkpolicy.networking.k8s.io/access-nginx created
```
Execute os comandos a seguir para testar o acesso ao service do nginx. Como nenhum rótulo de acesso está definido, a requisição expira por timeout.
```
kubectl run busybox --rm -ti --image=busybox /bin/sh
```
Teste o acesso ao service do nginx:
```
wget nginx
```
Saída esperada:
```
Connecting to nginx (172.19.XX.XX:80)
wget: can't connect to remote host (172.19.XX.XX): Connection timed out
```

Execute os comandos a seguir para definir o rótulo de acesso.

kubectl run busybox --rm -ti --labels="access=true" --image=busybox /bin/sh

Teste o acesso ao service do Nginx:

wget nginx

Saída esperada:

Connecting to nginx (172.21.XX.XX:80)
saving to 'index.html'
index.html           100% |****************************************************************************************************************************************************|   612  0:00:00 ETA
'index.html' saved

A saída indica que o progresso da conexão é 100%. Isso significa que a requisição foi bem-sucedida e o service do Nginx pode ser acessado.

Cenário 2: Restringir os blocos CIDR de origem que podem acessar um service exposto à Internet usando uma network policy

Execute o comando a seguir para criar uma instância Alibaba Cloud SLB para a aplicação nginx. Especifique type=LoadBalancer para expor o service do nginx à Internet.

vim nginx-service.yaml

A seguir está o modelo para o arquivo nginx-service.yaml.

# Paste the following YAML content into nginx-service.yaml.
apiVersion: v1
kind: Service
metadata:
  labels:
    run: nginx
  name: nginx-slb
spec:
  externalTrafficPolicy: Local
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    run: nginx
  type: LoadBalancer

Execute o comando a seguir para criar uma network policy a partir do arquivo nginx-service.yaml.

kubectl apply -f nginx-service.yaml

Saída esperada:

service/nginx-slb created

Verifique se a aplicação expôs o service do Nginx:

kubectl get service nginx-slb

Saída esperada:

NAME        TYPE           CLUSTER-IP      EXTERNAL-IP      PORT(S)        AGE
nginx-slb   LoadBalancer   172.19.xx.xxx   47.110.xxx.xxx   80:32240/TCP   8m

Execute o comando a seguir para acessar o endereço IP da instância SLB recém-criada, 47.110.xxx.xxx. O acesso falha.
```
wget 47.110.xxx.xxx
```
Saída esperada:
```
--2018-11-21 11:46:05--  http://47.110.xx.xxx/
Connecting to 47.110.XX.XX:80... failed: Connection refused.
```
Nota
O acesso falha pelos seguintes motivos:

O service do nginx configurado só pode ser acessado por aplicações com o rótulo específico access=true.

Acessar o endereço IP da instância SLB é considerado acesso externo ao Kubernetes. Isso difere do cenário de restringir o acesso ao service apenas para aplicações com rótulos específicos.
Solução: modifique a network policy para adicionar o bloco CIDR de origem permitido.

Execute o comando a seguir para visualizar seu endereço IP local.

curl myip.ipip.net

Saída esperada:

Current IP: 10.0.x.x From: China Beijing Beijing        # This is an example. Use the actual device information.

Execute o comando a seguir para modificar o arquivo policy.yaml.

vim policy.yaml

Modifique o arquivo policy.yaml para incluir o seguinte conteúdo:

# The following is the content of the YAML file.
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: access-nginx
spec:
  podSelector:
    matchLabels:
      run: nginx
  ingress:
  - from:
    - podSelector:
        matchLabels:
          access: "true"
    - ipBlock:
        cidr: 100.64.0.0/10
    - ipBlock:
        cidr: 10.0.0.1/24      # Local IP address. This is an example. Use the actual device information.

Execute o comando a seguir para criar uma network policy a partir do arquivo policy.yaml.

kubectl apply -f policy.yaml

Saída esperada:

networkpolicy.networking.k8s.io/access-nginx unchanged

Nota

Algumas redes possuem múltiplos endereços IP de saída. Recomenda-se utilizar um intervalo de endereços /24.
Os endereços de health check do SLB estão no bloco CIDR 100.64.0.0/10. Portanto, é necessário adicionar 100.64.0.0/10 à lista de permissões.

Execute o comando a seguir para acessar o service do Nginx.

kubectl run busybox --rm -ti --labels="access=true" --image=busybox /bin/sh

Acesse o service do nginx:

wget 47.110.XX.XX

Saída esperada:

Connecting to 47.110.XX.XX (47.110.XX.XX:80)
index.html           100% |***********************************************************|   612  0:00:00 ETA

A saída indica que o progresso da conexão é 100%. Isso significa que o acesso ao service do Nginx foi realizado com sucesso.

Cenário 3: Restringir um pod a acessar apenas um endereço específico usando uma network policy

Execute o comando a seguir para obter a lista de endereços IP para os quais o domínio www.aliyun.com resolve.

dig +short www.aliyun.com

Saída esperada:

www-jp-de-intl-adns.aliyun.com.
www-jp-de-intl-adns.aliyun.com.gds.alibabadns.com.
v6wagbridge.aliyun.com.
v6wagbridge.aliyun.com.gds.alibabadns.com.
106.XX.XX.21
140.XX.XX.4
140.XX.XX.13
140.XX.XX.3

Crie um arquivo chamado busybox-policy.yaml.

vim busybox-policy.yaml

Utilize o modelo a seguir para o arquivo busybox-policy.yaml:

# The following is the content of the YAML file.
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: busybox-policy
spec:
  podSelector:
    matchLabels:
      run: busybox
  egress:
  - to:
    - ipBlock:
        cidr: 106.XX.XX.21/32
    - ipBlock:
        cidr: 140.XX.XX.4/32
    - ipBlock:
        cidr: 140.XX.XX.13/32
    - ipBlock:
        cidr: 140.XX.XX.3/32
  - to:
    - ipBlock:
        cidr: 0.0.0.0/0
    - namespaceSelector: {}
    ports:
    - protocol: UDP
      port: 53

Nota

No arquivo busybox-policy.yaml, regras de saída (egress) são configuradas para restringir o acesso de saída da aplicação. É necessário configurar as regras para permitir requisições UDP. Caso contrário, a resolução DNS falhará.

Execute o comando a seguir para criar uma network policy a partir do arquivo busybox-policy.yaml.
```
kubectl apply -f busybox-policy.yaml 
```
Saída esperada:
```
networkpolicy.networking.k8s.io/busybox-policy created
```
Execute o comando a seguir para criar um pod busybox e testar o acesso.
```
kubectl run busybox --rm -ti --image=busybox /bin/sh
```
Acesse um site diferente de www.aliyun.com, como www.taobao.com:
```
wget www.taobao.com
```
Saída esperada:
```
Connecting to www.taobao.com (64.13.XX.XX:80)
wget: can't connect to remote host (64.13.XX.XX): Connection timed out
```
A mensagem can't connect to remote host indica que o acesso falhou.

Execute o comando a seguir para acessar www.aliyun.com.

wget www.aliyun.com

Saída esperada:

Connecting to www.aliyun.com (140.205.XX.XX:80)
Connecting to www.aliyun.com (140.205.XX.XX:443)
wget: note: TLS certificate validation not implemented
index.html           100% |***********************************************************|  462k  0:00:00 ETA

A saída indica que o progresso da conexão é 100%. Isso significa que o acesso ao service foi realizado com sucesso.

Cenário 4: Controlar o acesso à rede pública para pods em um namespace usando uma network policy

Importante

Esta operação pode afetar serviços em produção que estejam acessando a rede pública. Recomenda-se realizar as operações a seguir em um namespace vazio.

Execute o comando a seguir para criar um namespace de teste.
Crie um namespace chamado test-np.
```
kubectl create ns test-np
```
Saída esperada:
```
namespace/test-np created
```

Execute o comando a seguir para criar uma network policy padrão para o namespace que permita apenas acesso de saída a redes privadas.

vim default-deny.yaml

A seguir está um modelo de exemplo para o arquivo default-deny.yaml:

# The following is the content of the YAML file.
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  namespace: test-np
  name: deny-public-net
spec:
  podSelector: {}
  ingress:
  - from:
    - ipBlock:
        cidr: 0.0.0.0/0
  egress:
  - to:
    - ipBlock:
        cidr: 192.168.0.0/16
    - ipBlock:
        cidr: 172.16.0.0/12
    - ipBlock:
        cidr: 10.0.0.0/8

Verifique se o arquivo default-deny.yaml foi criado.

kubectl apply -f default-deny.yaml

Saída esperada:

networkpolicy.networking.k8s.io/deny-public-net created

Visualize a network policy:

kubectl get networkpolicy -n test-np

Saída esperada:

NAME                              POD-SELECTOR          AGE
deny-public-net                   <none>                1m

Execute o comando a seguir para criar uma network policy que permita que pods com um rótulo específico acessem a rede pública.

vim allow-specify-label.yaml

Neste exemplo, o rótulo é public-network=true.

# The following is the content of the YAML file.
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-public-network-for-labels
  namespace: test-np
spec:
  podSelector:
    matchLabels:
      public-network: "true"
  ingress:
  - from:
    - ipBlock:
        cidr: 0.0.0.0/0
  egress:
  - to:
    - ipBlock:
        cidr: 0.0.0.0/0
    - namespaceSelector:
        matchLabels:
          ns: kube-system  # Allows pods to access key services in kube-system (such as CoreDNS). This is an example. Configure as needed.

Execute o comando a seguir para criar a network policy:

kubectl apply -f allow-specify-label.yaml

Saída esperada:

networkpolicy.networking.k8s.io/allow-public-network-for-labels created

Visualize a network policy:

kubectl get networkpolicy -n test-np

Saída esperada:

NAME                              POD-SELECTOR          AGE
allow-public-network-for-labels   public-network=true    1m
deny-public-net                   <none>                 3m

Execute os comandos a seguir para verificar se um pod sem o rótulo especial não consegue acessar a rede pública.
```
kubectl run -it --namespace test-np --rm --image registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/busybox:1.28 busybox-intranet
```
```
ping aliyun.com
```
Saída esperada:
```
PING aliyun.com (106.11.2xx.xxx): 56 data bytes
^C
--- aliyun.com ping statistics ---
9 packets transmitted, 0 packets received, 100% packet loss
```
A mensagem 0 packets received indica que o acesso falhou.

Nota
O acesso falhou porque a network policy deny-public-net restringe, por padrão, o acesso à rede pública para pods no namespace test-np. Portanto, pods iniciados nesse namespace com rótulos padrão não conseguem acessar a rede pública.

Execute o comando a seguir para verificar se um pod com o rótulo public-network=true consegue acessar a rede pública.

kubectl run -it --namespace test-np --labels public-network=true --rm --image registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/busybox:1.28 busybox-internet

ping aliyun.com

Saída esperada:

PING aliyun.com (106.11.1xx.xx): 56 data bytes
64 bytes from 106.11.1xx.xx: seq=0 ttl=47 time=4.235 ms
64 bytes from 106.11.1xx.xx: seq=1 ttl=47 time=4.200 ms
64 bytes from 106.11.1xx.xx: seq=2 ttl=47 time=4.182 ms
^C
--- aliyun.com ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 4.182/4.205/4.235 ms

A mensagem 0% packet loss indica que o acesso ao service foi realizado com sucesso.

Nota

O acesso é bem-sucedido porque a network policy allow-public-network-for-labels permite o acesso à rede pública para pods com o rótulo public-network=true. Portanto, o pod busybox-internet, que possui esse rótulo, consegue acessar a rede pública.