[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC):2025-08-18。"],[[["\u003cp\u003eThis guide outlines how to configure DNS entries for \u003ccode\u003epkg.dev\u003c/code\u003e and \u003ccode\u003egcr.io\u003c/code\u003e domains to use a restricted virtual IP (VIP) in Google Kubernetes Engine (GKE) private clusters within a VPC Service Controls service perimeter.\u003c/p\u003e\n"],["\u003cp\u003eGKE private clusters, being isolated from the internet, require specific DNS configurations to ensure requests to registry domains are routed to the restricted VIP, \u003ccode\u003erestricted.googleapis.com\u003c/code\u003e, preventing data exfiltration.\u003c/p\u003e\n"],["\u003cp\u003eThe DNS configuration process involves creating a managed private zone in Cloud DNS, starting a transaction, adding CNAME and A records for the registry domain and the restricted VIP, then executing the transaction.\u003c/p\u003e\n"],["\u003cp\u003eAfter setting up the DNS, you must create or update your service perimeter, add services like Container Registry or Artifact Registry, and include other necessary services like Cloud Storage, if needed.\u003c/p\u003e\n"],["\u003cp\u003eVerifying the setup involves confirming that GKE private cluster nodes can only access container images within the defined service perimeter, while images outside remain inaccessible.\u003c/p\u003e\n"]]],[],null,["# Configure restricted access for GKE private clusters\n\nThis document describes how to configure DNS entries to route requests to the `pkg.dev` and `gcr.io` domains using a restricted virtual IP (VIP) when you use [Google Kubernetes Engine private clusters](/kubernetes-engine/docs/how-to/private-clusters) in a VPC Service Controls service perimeter.\n\nRegistry domains normally resolve to a public IP address on the\ninternet. In GKE private clusters, nodes are isolated from the\ninternet by default. This means that requests to registry domains will fail when\nyou have not configured DNS routing to the restricted VIP.\nYour private clusters should always access Artifact Registry or Container Registry with the restricted VIP to prevent data exfiltration from a supported service to an unsupported one.\n\nConfigure restricted access for GKE private clusters when all of\nthe following are true:\n\n- You're using GKE private clusters.\n- You haven't already configured routing of the `pkg.dev` or `gcr.io` registry domains to `restricted.googleapis.com`.\n\nBefore you begin\n----------------\n\nBefore you create a service perimeter,\n[set up a new private cluster](/kubernetes-engine/docs/how-to/private-clusters)\nor identify the existing private clusters that you want to protect.\n\nAlso, you must permit egress to 199.36.153.4/30 on port 443. Normally, a\nVPC network has an implied rule that allows all egress traffic to\nany destination. However, if you have a rule denying such traffic, you must\ncreate an egress firewall rule to allow TCP traffic on port 443 to\n199.36.153.4/30.\n\nConfiguring DNS\n---------------\n\nConfigure your DNS server so that requests to registry addresses resolve to\n`restricted.googleapis.com`, the restricted VIP. You can do so using\nCloud DNS private DNS zones.\n\n1. Create a managed private zone.\n\n gcloud dns managed-zones create \u003cvar translate=\"no\"\u003eZONE_NAME\u003c/var\u003e \\\n --visibility=private \\\n --networks=https://www.googleapis.com/compute/v1/projects/\u003cvar translate=\"no\"\u003ePROJECT_ID\u003c/var\u003e/global/networks/\u003cvar translate=\"no\"\u003eNETWORK\u003c/var\u003e \\\n --description=\u003cvar translate=\"no\"\u003eDESCRIPTION\u003c/var\u003e \\\n --dns-name=\u003cvar translate=\"no\"\u003eREGISTRY_DOMAIN\u003c/var\u003e \\\n --project=\u003cvar translate=\"no\"\u003ePROJECT_ID\u003c/var\u003e\n\n Where:\n - \u003cvar translate=\"no\"\u003eZONE_NAME\u003c/var\u003e is a name for the zone you are creating. For example, `registry`. This name will be used in each of the following steps.\n - \u003cvar translate=\"no\"\u003ePROJECT_ID\u003c/var\u003e is the ID of the project that hosts your GKE private cluster.\n - \u003cvar translate=\"no\"\u003eNETWORK\u003c/var\u003e is an optional list of names of the cluster network that you want to redirect requests from.\n - \u003cvar translate=\"no\"\u003eDESCRIPTION\u003c/var\u003e is a human-readable description of the managed zone.\n - \u003cvar translate=\"no\"\u003eREGISTRY_DOMAIN\u003c/var\u003e is the domain for your registry:\n - `pkg.dev` for Artifact Registry\n - `gcr.io` for Container Registry or `gcr.io` repositories hosted in Artifact Registry\n2. Start a transaction.\n\n gcloud dns record-sets transaction start \\\n --zone=\u003cvar translate=\"no\"\u003eZONE_NAME\u003c/var\u003e \\\n --project=\u003cvar translate=\"no\"\u003ePROJECT_ID\u003c/var\u003e\n\n Where:\n - \u003cvar translate=\"no\"\u003eZONE_NAME\u003c/var\u003e is the name of the zone you created in the first\n step.\n\n - \u003cvar translate=\"no\"\u003ePROJECT_ID\u003c/var\u003e is the ID of the project that hosts your\n GKE private cluster.\n\n3. Add a CNAME record for your registry.\n\n gcloud dns record-sets transaction add \\\n --name=*.\u003cvar translate=\"no\"\u003eREGISTRY_DOMAIN\u003c/var\u003e. \\\n --type=CNAME \u003cvar translate=\"no\"\u003eREGISTRY_DOMAIN\u003c/var\u003e. \\\n --zone=\u003cvar translate=\"no\"\u003eZONE_NAME\u003c/var\u003e \\\n --ttl=300 \\\n --project=\u003cvar translate=\"no\"\u003ePROJECT_ID\u003c/var\u003e\n\n Where:\n - \u003cvar translate=\"no\"\u003eZONE_NAME\u003c/var\u003e is the name of the zone you created in the first step.\n - \u003cvar translate=\"no\"\u003ePROJECT_ID\u003c/var\u003e is the ID of the project that hosts your GKE private cluster.\n - \u003cvar translate=\"no\"\u003eREGISTRY_DOMAIN\u003c/var\u003e is the domain for your registry:\n - `pkg.dev` for Artifact Registry\n - `gcr.io` for Container Registry or `gcr.io` repositories hosted in Artifact Registry\n4. Add an A record for the restricted VIP.\n\n gcloud dns record-sets transaction add \\\n --name=\u003cvar translate=\"no\"\u003eREGISTRY_DOMAIN\u003c/var\u003e. \\\n --type=A 199.36.153.4 199.36.153.5 199.36.153.6 199.36.153.7 \\\n --zone=\u003cvar translate=\"no\"\u003eZONE_NAME\u003c/var\u003e \\\n --ttl=300 \\\n --project=\u003cvar translate=\"no\"\u003ePROJECT_ID\u003c/var\u003e\n\n Where:\n - \u003cvar translate=\"no\"\u003eZONE_NAME\u003c/var\u003e is the name of the zone you created in the first step.\n - \u003cvar translate=\"no\"\u003ePROJECT_ID\u003c/var\u003e is the ID of the project that hosts your GKE private cluster.\n - \u003cvar translate=\"no\"\u003eREGISTRY_DOMAIN\u003c/var\u003e is the domain for your registry:\n - `pkg.dev` for Artifact Registry\n - `gcr.io` for Container Registry or `gcr.io` repositories hosted in Artifact Registry\n5. Execute the transaction.\n\n gcloud dns record-sets transaction execute \\\n --zone=\u003cvar translate=\"no\"\u003eZONE_NAME\u003c/var\u003e \\\n --project=\u003cvar translate=\"no\"\u003ePROJECT_ID\u003c/var\u003e\n\n Where:\n - \u003cvar translate=\"no\"\u003eZONE_NAME\u003c/var\u003e is the name of the zone you created in the first\n step.\n\n - \u003cvar translate=\"no\"\u003ePROJECT_ID\u003c/var\u003e is the ID of the project that hosts your\n GKE private cluster.\n\nAfter you have configured DNS routing, ensure that your GKE, the\nregistry, and other required services are inside your VPC Service Controls\nservice perimeter. To configure your service perimeter, see the following\nsection.\n\nConfiguring the service perimeter\n---------------------------------\n\nAfter [configuring the DNS records](#configure-dns), do the following:\n\n1. [Create a new service perimeter](/vpc-service-controls/docs/create-service-perimeters) or [update an existing perimeter](/vpc-service-controls/docs/manage-service-perimeters).\n2. Add the Container Registry or Artifact Registry service to the list of services you want to protect using the service perimeter.\n3. Add other [supported services](/vpc-service-controls/docs/supported-products) that you use with the registry to the service perimeter, such as Cloud Build, Artifact Analysis, and Binary Authorization.\n4. If you need to access Container Registry, then you must also add Cloud Storage to the service perimeter.\n\nVerifying the perimeter works\n-----------------------------\n\nAfter [configuring the service perimeter](#configure-perimeter), your nodes in GKE private clusters can access container images in Artifact Registry and Container Registry if the images are stored in projects that are in your service perimeter.\n\nContainer images in projects outside the perimeter remain inaccessible, except\nfor some [specific read-only public repositories](/vpc-service-controls/docs/supported-products#table_artifacts).\n\nFor example, if the `google-samples` project is not in your service perimeter,\nrunning the command to create a deployment from the `hello-app` container\nwill fail: \n\n### pkg.dev domain\n\n kubectl create deployment hello-server --image=us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0\n\n### gcr.io domain\n\n kubectl create deployment hello-server --image=gcr.io/google-samples/hello-app:1.0\n\nCheck the status of the pod with the command: \n\n kubectl get pods\n\nThe command returns a table similar to the following example. The pod status\n`ErrImagePull` indicates that the pull failed. \n\n NAME READY STATUS RESTARTS AGE\n hello-server-dbd86c8c4-h5wsf 1/1 ErrImagePull 0 45s\n\nYou can use the `kubectl describe pod` command to see more details about the\ndeployment. For the pod in the previous example, the command is: \n\n kubectl describe pod hello-server-dbd86c8c4-h5wsf"]]