Este documento descreve como configurar entradas DNS para encaminhar solicitações para
os domínios pkg.dev
e gcr.io
usando um IP virtual (VIP) restrito quando você
usa clusters particulares do Google Kubernetes Engine em um perímetro de serviço do
VPC Service Controls.
Esses domínios de registro normalmente resolvem para um endereço IP público no Internet. Em clusters particulares do GKE, os nós são isolados da Internet por padrão. Isso significa que as solicitações para os registros vão falhar se você não tiver configurado o roteamento de DNS para o VIP restrito.
Seus clusters particulares precisam sempre acessar o Artifact Registry ou o Container Registry com o VIP restrito para evitar a exfiltração de dados de um serviço compatível para um não compatível.
Essas etapas só serão necessárias se:
- Você está usando clusters particulares do GKE.
- Você ainda não configurou o roteamento do
Domínios de registro
pkg.dev
ougcr.io
pararestricted.googleapis.com
.
Antes de começar
Antes de criar um perímetro de serviço, configure um novo cluster privado ou identifique os clusters particulares atuais que você quer proteger.
Além disso, é preciso permitir a saída para 199.36.153.4/30 na porta 443. Normalmente, uma rede VPC tem uma regra implícita que permite todo o tráfego de saída para qualquer destino. No entanto, se você tiver uma regra que negue esse tráfego, será necessário criar uma regra de firewall de saída para permitir o tráfego TCP na porta 443 para 199.36.153.4/30.
Como configurar DNS
Configure seu servidor DNS para que as solicitações de endereços de registro sejam resolvidas
restricted.googleapis.com
, o VIP restrito. É possível fazer isso usando zonas de DNS particular do Cloud DNS.
Criar uma zona particular gerenciada
gcloud dns managed-zones create ZONE_NAME \ --visibility=private \ --networks=https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/NETWORK \ --description=DESCRIPTION \ --dns-name=REGISTRY_DOMAIN \ --project=PROJECT_ID
Em que:
ZONE_NAME é um nome para a zona que você está criando. Por exemplo,
registry
; Esse nome será usado em cada uma das etapas a seguir.PROJECT_ID é o código do projeto que hospeda seu cluster particular do GKE.
NETWORK é uma lista opcional de nomes da rede de clusters de que você quer redirecionar solicitações.
DESCRIPTION é uma descrição legível da zona gerenciada.
REGISTRY_DOMAIN é o domínio do registro:
pkg.dev
para o Artifact Registrygcr.io
para Container Registry ou Repositórios gcr.io hospedados no Artifact Registry
Inicie uma transação.
gcloud dns record-sets transaction start \ --zone=ZONE_NAME \ --project=PROJECT_ID
Em que:
ZONE_NAME é o nome da zona que você criou na primeira etapa.
PROJECT_ID é o código do projeto que hospeda seu cluster particular do GKE.
Adicione um registro CNAME ao seu registro.
gcloud dns record-sets transaction add \ --name=*.REGISTRY_DOMAIN. \ --type=CNAME REGISTRY_DOMAIN. \ --zone=ZONE_NAME \ --ttl=300 \ --project=PROJECT_ID
Em que:
ZONE_NAME é o nome da zona que você criou na primeira etapa.
PROJECT_ID é o código do projeto que hospeda seu cluster particular do GKE.
REGISTRY_DOMAIN é o domínio do registro:
pkg.dev
para o Artifact Registrygcr.io
para Container Registry ou Repositórios gcr.io hospedados no Artifact Registry
Adicione um registro A ao VIP restrito.
gcloud dns record-sets transaction add \ --name=REGISTRY_DOMAIN. \ --type=A 199.36.153.4 199.36.153.5 199.36.153.6 199.36.153.7 \ --zone=ZONE_NAME \ --ttl=300 \ --project=PROJECT_ID
Em que:
ZONE_NAME é o nome da zona que você criou na primeira etapa.
PROJECT_ID é o código do projeto que hospeda seu cluster particular do GKE.
REGISTRY_DOMAIN é o domínio do registro:
pkg.dev
para o Artifact Registrygcr.io
para o Container Registry ou os repositórios gcr.io hospedados no Artifact Registry
Execute a transação.
gcloud dns record-sets transaction execute \ --zone=ZONE_NAME \ --project=PROJECT_ID
Em que:
ZONE_NAME é o nome da zona que você criou na primeira etapa.
PROJECT_ID é o código do projeto que hospeda seu cluster particular do GKE.
Após configurar o roteamento DNS, verifique se o GKE, e outros serviços necessários estão dentro do seu VPC Service Controls perímetro de serviço. Para configurar o perímetro de serviço, consulte a próxima seção.
Como configurar o perímetro de serviço
Depois de configurar os registros DNS, crie um novo perímetro de serviço ou atualize um perímetro atual, e adicione o serviço Container Registry ou Artifact Registry à lista de serviços que você quer proteger usando o perímetro de serviço.
Além disso:
- Adicionar outros serviços com suporte usados com o registro para o perímetro de serviço, como o Cloud Build, Artifact Analysis e autorização binária.
- Para o Container Registry, também é preciso adicionar o Cloud Storage ao perímetro de serviço.
Como verificar se o perímetro funciona
Depois de configurar o perímetro de serviço, os nós nos clusters privados do GKE poderão acessar imagens de contêiner no Artifact Registry e no Container Registry, se as imagens estiverem armazenadas em projetos no perímetro de serviço.
As imagens de contêiner em projetos fora do perímetro permanecem inacessíveis, exceto para alguns repositórios públicos somente leitura específicos.
Por exemplo, se o projeto google-samples
não estiver no perímetro do serviço,
a execução do comando para criar uma implantação do contêiner hello-app
vai falhar:
Domínio pkg.dev
kubectl create deployment hello-server --image=us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0
Domínio gcr.io
kubectl create deployment hello-server --image=gcr.io/google-samples/hello-app:1.0
Verifique o status do pod com o comando:
kubectl get pods
O comando retorna uma tabela semelhante ao exemplo a seguir. O status do pod
ErrImagePull
indica que o pull falhou.
NAME READY STATUS RESTARTS AGE
hello-server-dbd86c8c4-h5wsf 1/1 ErrImagePull 0 45s
Use o comando kubectl describe pod
para ver mais detalhes sobre a
implantação. Para o pod no exemplo anterior, o comando é:
kubectl describe pod hello-server-dbd86c8c4-h5wsf