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

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

Pré-requisitos

Crie um cluster gerenciado pelo ACK ou um cluster dedicado do ACK. Consulte Criar um cluster gerenciado pelo ACK ou Criar um cluster dedicado do ACK (Descontinuado).
Importante
Em clusters ACK managed cluster Pro e ACK Serverless Pro, componentes diferentes implementam a Network Policy.
- Em um ACK managed cluster Pro (para nós que não são elastic container instances), o plugin de rede Terway implementa a Network Policy. Consulte Ativar Network Policy em clusters ACK.
- Nas elastic container instances (ECIs) em clusters ACK Serverless e clusters ACK managed Pro, o componente Poseidon implementa a Network Policy.
Atualize o componente ACK Virtual Node para a versão v2.10.0 ou posterior. Consulte Gerenciar componentes.
Configure um grupo de segurança para o cluster.
Configure o acesso ao cluster via kubectl.

Limitações

A Network Policy tem suporte apenas em 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 tem suporte.
As regras de NetworkPolicy usam seletores de rótulo para corresponder a namespaces ou pods. O excesso de recursos de NetworkPolicy retarda a propagação das regras e dificulta o gerenciamento e a solução de problemas. Limite os recursos de NetworkPolicy a menos de 40 por cluster.

Etapa 1: Ativar Network Policy

Instale o componente Poseidon para ativar a Network Policy em um cluster ACK Serverless Pro.

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

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

Usar o console

Faça login no console do ACK. No painel de navegação à esquerda, clique em Clusters.
Na página Clusters, clique no nome do cluster desejado. 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.

Neste exemplo, configure apenas os itens a seguir para a aplicação Nginx e mantenha as configurações padrão para os demais parâmetros. Para obter mais informações sobre as configurações, consulte Criar uma carga de trabalho sem estado (Deployment).

Item de configuração		Descrição	Valor de exemplo
Basic Information	Name	Um nome personalizado.	nginx
Basic Information	Replicas	Selecione conforme necessário.	1
Container	Image Name	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 serviço.	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 resultante, crie uma aplicação cliente chamada busybox para testar o acesso ao Service nginx criado na etapa anterior.

Neste exemplo, configure apenas os itens a seguir para a aplicação cliente busybox e mantenha as configurações padrão para os demais parâmetros. Para obter mais informações sobre as configurações, consulte Criar uma carga de trabalho sem estado (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	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 no nome da aplicação busybox.
2. Na aba Pods, localize o pod busybox-{valor 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 de 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 ao serviço a 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 modelo YAML a seguir.

vim policy.yaml

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 nginx. Como nenhum rótulo de acesso está definido, a solicitação expira.
```
kubectl run busybox --rm -ti --image=busybox /bin/sh
```
Teste o acesso ao Service 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 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 é de 100%. Isso significa que a solicitação foi bem-sucedida e o serviço Nginx pode ser acessado.

Cenário 2: Restringir os blocos CIDR de origem que podem acessar um serviço voltado para a Internet usando uma network policy

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

vim nginx-service.yaml

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õe o serviço 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 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 restrição de acesso ao serviço a 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 vários endereços IP de saída. Recomendamos usar um intervalo de endereços /24.
Os endereços de verificação de integridade do SLB estão no bloco CIDR 100.64.0.0/10. Portanto, adicione 100.64.0.0/10 à lista de permissões.

Execute o comando a seguir para acessar o serviço Nginx.

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

Acesse o serviço 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 é de 100%. Isso significa que você acessou o serviço Nginx com êxito.

Cenário 3: Restringir um pod para acessar apenas um endereço especificado usando uma network policy

Execute o comando a seguir para obter a lista de endereços IP aos quais o nome de 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

Use 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, as regras de saída restringem o acesso de saída da aplicação. Configure as regras para permitir solicitaçõ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 é de 100%. Isso significa que o serviço foi acessado com êxito.

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 online que acessam a rede pública. Recomendamos 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

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 o acesso à rede pública para pods no namespace test-np por padrão. Portanto, pods iniciados neste 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 serviço foi acessado com êxito.

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.