Crea políticas de red dentro del proyecto

En esta página, se proporcionan instrucciones para configurar políticas de red de tráfico dentro del proyecto en Google Distributed Cloud (GDC) aislado.

Las políticas de red del proyecto definen reglas de entrada o salida. Puedes definir políticas que permitan la comunicación dentro de los proyectos, entre proyectos y con direcciones IP externas.

De forma predeterminada, estas políticas se aplican a nivel global en todas las zonas. Para obtener más información sobre los recursos globales en un universo de GDC, consulta la descripción general de varias zonas.

Si se necesita la aplicación de políticas de tráfico dentro del proyecto en una sola zona, consulta Crea una política dentro del proyecto a nivel de la carga de trabajo para una sola zona.

Antes de comenzar

Para configurar políticas de red de tráfico dentro del proyecto, debes tener lo siguiente:

• Los roles de identidad y acceso necesarios Para administrar las políticas de un proyecto específico, necesitas el rol de project-networkpolicy-admin. Para los entornos de varias zonas en los que necesitas administrar políticas que abarcan todas las zonas, necesitas el rol de global-project-networkpolicy-admin. Para obtener más información, consulta Cómo preparar roles y acceso predefinidos.
• Un proyecto existente Para obtener más información, consulta Cómo crear un proyecto.

Crea una política intraproyecto

Para el tráfico dentro de un proyecto, GDC aplica una política de red del proyecto predefinida, la política intraproyecto, a cada proyecto de forma predeterminada. De forma predeterminada, las cargas de trabajo en un espacio de nombres del proyecto pueden comunicarse entre sí sin exponer nada a los recursos externos.

De forma predeterminada, no hay una política de salida, por lo que se permite el tráfico saliente para todo el tráfico dentro del proyecto. Sin embargo, cuando estableces una sola política de salida, solo se permite el tráfico que especifica la política.

Nota: Las políticas definidas en esta sección se aplican a los clústeres compartidos y estándar.

Crea una política de entrada intraproyecto

Cuando creas un proyecto, también creas de forma implícita un recurso ProjectNetworkPolicy base predeterminado que permite la comunicación dentro del proyecto. Esta política permite el tráfico entrante de otras cargas de trabajo en el mismo proyecto.

Puedes quitar la política predeterminada, pero ten en cuenta que esta acción deniega la comunicación dentro del proyecto para todos los servicios y cargas de trabajo del proyecto. Para quitar la política, usa el comando kubectl delete:

kubectl --kubeconfig GLOBAL_API_SERVER delete pnp base-policy-allow-intra-project-traffic -n PROJECT

Puedes volver a agregar la política predeterminada aplicando el siguiente manifiesto:

kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT
  name: base-policy-allow-intra-project-traffic
spec:
  policyType: Ingress
  ingress:
  - from:
    - projectSelector:
        projects:
          matchNames:
          - PROJECT
EOF

Reemplaza lo siguiente:

• GLOBAL_API_SERVER: Es la ruta de acceso de kubeconfig del servidor de la API global. Para obtener más información, consulta Servidores de API globales y zonales. Si aún no generaste un archivo kubeconfig para el servidor de la API, consulta Accede para obtener más detalles.
• PROJECT: nombre del proyecto.

Crea una política de salida intraproyecto

Cuando inhabilitas la prevención de robo de datos y aplicas una política de salida de ProjectNetworkPolicy al proyecto, como impedir el acceso a un recurso externo, usa la siguiente política obligatoria para permitir el tráfico saliente dentro del proyecto:

kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT
  name: allow-intra-project-outbound-traffic
spec:
  policyType: Egress
  egress:
  - to:
    - projectSelector:
        projects:
          matchNames:
          - PROJECT
EOF

Reemplaza lo siguiente:

• GLOBAL_API_SERVER: Es la ruta de acceso de kubeconfig del servidor de la API global. Para obtener más información, consulta Servidores de API globales y zonales. Si aún no generaste un archivo kubeconfig para el servidor de la API, consulta Accede para obtener más detalles.
• PROJECT: nombre del proyecto.

Crea una política intraproyecto a nivel de la carga de trabajo

Las políticas de red a nivel de la carga de trabajo ofrecen un control detallado sobre la comunicación entre las cargas de trabajo individuales dentro de un proyecto. Esta granularidad permite un control más estricto del acceso a la red, lo que mejora la seguridad y el uso de los recursos.

Crea una política de entrada a nivel de la carga de trabajo dentro del proyecto

Cuando creas un proyecto, también creas de forma implícita un recurso ProjectNetworkPolicy base predeterminado que permite la comunicación dentro del proyecto entre todas las cargas de trabajo. Esta política permite el tráfico entrante de otras cargas de trabajo en el mismo proyecto.

Para crear una política de ingreso a nivel de la carga de trabajo dentro del proyecto, primero se debe borrar la política base predeterminada. De lo contrario, es posible que se produzca un comportamiento inesperado.

1. Para borrar la política básica predeterminada, ejecuta el siguiente comando:

   kubectl --kubeconfig GLOBAL_API_SERVER delete pnp base-policy-allow-intra-project-traffic -n PROJECT
   

2. Para crear una política intraproyecto a nivel de la carga de trabajo de entrada, crea y aplica el siguiente recurso personalizado:

   kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
   apiVersion: networking.global.gdc.goog/v1
   kind: ProjectNetworkPolicy
   metadata:
     namespace: PROJECT
     name: allow-workload-level-intra-project-inbound-traffic
   spec:
     policyType: Ingress
     subject:
       subjectType: UserWorkload
       userWorkloadSelector:
         labelSelector:
           workloads:
             matchLabels:
               SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
     ingress:
     - from:
       - projectSelector:
           projects:
             matchNames:
             - PROJECT
           workloadSelector:
             labelSelector:
               workloads:
                 matchLabels:
                   PEER_LABEL_KEY: PEER_LABEL_VALUE
   EOF
   

   Reemplaza lo siguiente:

   • GLOBAL_API_SERVER: Es la ruta de acceso de kubeconfig del servidor de la API global. Para obtener más información, consulta Servidores de API globales y zonales. Si aún no generaste un archivo kubeconfig para el servidor de la API, consulta Acceder para obtener más detalles.
   • PROJECT: nombre del proyecto.
   • SUBJECT_LABEL_KEY: Es la clave de la etiqueta que se usa para seleccionar las cargas de trabajo del asunto. Por ejemplo, app, tier o role. Si haces referencia a etiquetas de VM, debes agregar un prefijo a esta clave. Consulta la advertencia que sigue a esta lista.
   • SUBJECT_LABEL_VALUE: Es el valor asociado con el SUBJECT_LABEL_KEY. Por ejemplo, si SUBJECT_LABEL_KEY es app y SUBJECT_LABEL_VALUE es backend, las cargas de trabajo con la etiqueta app: backend reciben el tráfico.
   • PEER_LABEL_KEY: Es la clave de la etiqueta que se usa para seleccionar las cargas de trabajo de los pares. Si haces referencia a etiquetas de VM, debes agregar un prefijo a esta clave. Consulta la advertencia que sigue a esta lista.
   • PEER_LABEL_VALUE: Es el valor asociado con el PEER_LABEL_KEY.
   Advertencia: Cuando hagas referencia a etiquetas de VM en los campos workloadSelector o workloads, debes anteponer el prefijo user-label.gpc.gke.io/ a la clave de la etiqueta. Por ejemplo, si asignas la etiqueta app: backend a una VM, debes especificarla como user-label.gpc.gke.io/app: backend para que coincida correctamente con la carga de trabajo. Este prefijo es específico para las VMs y no se aplica a ninguna otra carga de trabajo.

Crea una política de salida a nivel de la carga de trabajo dentro del proyecto

• Para crear una política intraproyecto a nivel de la carga de trabajo de salida, crea y aplica el siguiente recurso personalizado:

  kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
  apiVersion: networking.global.gdc.goog/v1
  kind: ProjectNetworkPolicy
  metadata:
    namespace: PROJECT
    name: allow-workload-level-intra-project-outbound-traffic
  spec:
    policyType: Egress
    subject:
      subjectType: UserWorkload
      userWorkloadSelector:
        labelSelector:
          workloads
            matchLabels:
              SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
    egress:
    - to:
      - projectSelector:
          projects:
            matchNames:
            - PROJECT
          workloadSelector:
            labelSelector:
              workloads:
                matchLabels:
                  PEER_LABEL_KEY: PEER_LABEL_VALUE
  EOF
  

  Reemplaza lo siguiente:

  • GLOBAL_API_SERVER: Es la ruta de acceso de kubeconfig del servidor de la API global. Para obtener más información, consulta Servidores de API globales y zonales. Si aún no generaste un archivo kubeconfig para el servidor de la API, consulta Acceder para obtener más detalles.
  • PROJECT: nombre del proyecto.
  • SUBJECT_LABEL_KEY: Es la clave de la etiqueta que se usa para seleccionar las cargas de trabajo del asunto. Por ejemplo, app, tier o role. Si haces referencia a etiquetas de VM, debes agregar un prefijo a esta clave. Consulta la advertencia que sigue a esta lista.
  • SUBJECT_LABEL_VALUE: Es el valor asociado con el SUBJECT_LABEL_KEY. Por ejemplo, si SUBJECT_LABEL_KEY es app y SUBJECT_LABEL_VALUE es backend, las cargas de trabajo con la etiqueta app: backend envían el tráfico.
  • PEER_LABEL_KEY: Es la clave de la etiqueta que se usa para seleccionar las cargas de trabajo de los pares. Si haces referencia a etiquetas de VM, debes agregar un prefijo a esta clave. Consulta la advertencia que sigue a esta lista.
  • PEER_LABEL_VALUE: Es el valor asociado con el PEER_LABEL_KEY.
  Advertencia: Cuando hagas referencia a etiquetas de VM en los campos workloadSelector o workloads, debes anteponer el prefijo user-label.gpc.gke.io/ a la clave de la etiqueta. Por ejemplo, si asignas la etiqueta app: backend a una VM, debes especificarla como user-label.gpc.gke.io/app: backend para que coincida correctamente con la carga de trabajo. Este prefijo es específico para las VMs y no se aplica a ninguna otra carga de trabajo.

Crea una política intraproyecto a nivel de la carga de trabajo de una sola zona

Las políticas de red a nivel de la carga de trabajo pueden aplicar PNP a lo largo de una sola zona. Se pueden agregar etiquetas específicas a las cargas de trabajo dentro de una sola zona, lo que te permite controlar la comunicación entre cargas de trabajo individuales dentro de un proyecto o en diferentes proyectos para esa zona.

Crea una política intraproyecto a nivel de la carga de trabajo de entrada de una sola zona

Cuando creas un proyecto, también creas de forma implícita un recurso ProjectNetworkPolicy base predeterminado que permite la comunicación dentro del proyecto entre todas las cargas de trabajo. Esta política permite el tráfico entrante de otras cargas de trabajo en el mismo proyecto.

Para crear una política intraproyecto a nivel de la carga de trabajo de entrada de una sola zona, primero se debe borrar la política básica predeterminada. De lo contrario, es posible que se produzca un comportamiento inesperado.

1. Para borrar la política básica predeterminada, ejecuta el siguiente comando:

   kubectl --kubeconfig GLOBAL_API_SERVER delete pnp base-policy-allow-intra-project-traffic -n PROJECT
   

2. Para crear una política de red de tráfico interno del proyecto a nivel de la carga de trabajo de entrada de una sola zona, crea y aplica el siguiente recurso personalizado:

   kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
   apiVersion: networking.global.gdc.goog/v1
   kind: ProjectNetworkPolicy
   metadata:
     namespace: PROJECT
     name: allow-single-zone-intra-project-inbound-traffic
   spec:
     policyType: Ingress
     subject:
       subjectType: UserWorkload
       userWorkloadSelector:
         labelSelector:
           workloads:
             matchLabels:
               SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
               ZONE_SUBJECT_LABEL_KEY: ZONE_SUBJECT_LABEL_VALUE
     ingress:
     - from:
       - projectSelector:
           projects:
             matchNames:
             - PROJECT
           workloadSelector:
             labelSelector:
               workloads:
                 matchLabels:
                   PEER_LABEL_KEY: PEER_LABEL_VALUE
                   ZONE_PEER_LABEL_KEY: ZONE_PEER_LABEL_VALUE
   EOF
   

   Nota: Los recursos deben tener etiquetas que coincidan exactamente. Para garantizar que esta política se aplique dentro de una sola zona, las cargas de trabajo del sujeto y del par deben tener la misma etiqueta de zona.

   Reemplaza lo siguiente:

   • GLOBAL_API_SERVER: Es la ruta de acceso de kubeconfig del servidor de la API global. Para obtener más información, consulta Servidores de API globales y zonales. Si aún no generaste un archivo kubeconfig para el servidor de la API, consulta Acceder para obtener más detalles.
   • PROJECT: nombre del proyecto.
   • SUBJECT_LABEL_KEY: Es la clave de la etiqueta que se usa para seleccionar las cargas de trabajo del asunto. Por ejemplo, app, tier o role. Si haces referencia a etiquetas de VM, debes agregar un prefijo a esta clave. Consulta la advertencia que sigue a esta lista.
   • SUBJECT_LABEL_VALUE: Es el valor asociado con el SUBJECT_LABEL_KEY. Por ejemplo, si SUBJECT_LABEL_KEY es app y SUBJECT_LABEL_VALUE es backend, las cargas de trabajo con la etiqueta app: backend reciben el tráfico.
   • PEER_LABEL_KEY: Es la clave de la etiqueta que se usa para seleccionar las cargas de trabajo de los pares. Si haces referencia a etiquetas de VM, debes agregar un prefijo a esta clave. Consulta la advertencia que sigue a esta lista.
   • PEER_LABEL_VALUE: Es el valor asociado con el PEER_LABEL_KEY.
   • ZONE_SUBJECT_LABEL_KEY: Es la clave de la etiqueta que se usa para seleccionar la zona del sujeto. Por ejemplo, zone o region. Si haces referencia a etiquetas de VM, debes agregar un prefijo a esta clave. Consulta la advertencia que sigue a esta lista.
   • ZONE_SUBJECT_LABEL_VALUE: Es el valor asociado con el ZONE_SUBJECT_LABEL_KEY. Por ejemplo, si ZONE_SUBJECT_LABEL_KEY es zone y ZONE_SUBJECT_LABEL_VALUE es us-central1-a, las cargas de trabajo con la etiqueta zone: us-central1-a reciben el tráfico.
   • ZONE_PEER_LABEL_KEY: Es la clave de la etiqueta que se usa para seleccionar la zona asociada con el par. Si haces referencia a etiquetas de VM, debes agregar un prefijo a esta clave. Consulta la advertencia que sigue a esta lista.
   • ZONE_PEER_LABEL_VALUE: Es el valor asociado con el ZONE_PEER_LABEL_KEY.
   Advertencia: Cuando hagas referencia a etiquetas de VM en los campos workloadSelector o workloads, debes anteponer el prefijo user-label.gpc.gke.io/ a la clave de la etiqueta. Por ejemplo, si asignas la etiqueta app: backend a una VM, debes especificarla como user-label.gpc.gke.io/app: backend para que coincida correctamente con la carga de trabajo. Este prefijo es específico para las VMs y no se aplica a ninguna otra carga de trabajo.

Crea una política intraproyecto a nivel de la carga de trabajo de salida de una sola zona

• Para crear una política intraproyecto a nivel de la carga de trabajo de salida de una sola zona, crea y aplica el siguiente recurso personalizado:

  kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
  apiVersion: networking.global.gdc.goog/v1
  kind: ProjectNetworkPolicy
  metadata:
    namespace: PROJECT
    name: allow-single-zone-intra-project-outbound-traffic
  spec:
    policyType: Egress
    subject:
      subjectType: UserWorkload
      userWorkloadSelector:
        labelSelector:
          workloads:
            matchLabels:
              SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
              ZONE_SUBJECT_LABEL_KEY: ZONE_SUBJECT_LABEL_VALUE
    egress:
    - to:
      - projectSelector:
          projects:
            matchNames:
            - PROJECT
          workloadSelector:
            labelSelector:
              workloads:
                matchLabels:
                  PEER_LABEL_KEY: PEER_LABEL_VALUE
                  ZONE_PEER_LABEL_KEY: ZONE_PEER_LABEL_VALUE
  EOF
  

  Nota: Los recursos deben tener etiquetas que coincidan exactamente. Para garantizar que esta política se aplique dentro de una sola zona, las cargas de trabajo del sujeto y del par deben tener la misma etiqueta de zona.

  Reemplaza lo siguiente:

  • GLOBAL_API_SERVER: Es la ruta de acceso de kubeconfig del servidor de la API global. Para obtener más información, consulta Servidores de API globales y zonales. Si aún no generaste un archivo kubeconfig para el servidor de la API, consulta Acceder para obtener más detalles.
  • PROJECT: nombre del proyecto.
  • SUBJECT_LABEL_KEY: Es la clave de la etiqueta que se usa para seleccionar las cargas de trabajo del asunto. Por ejemplo, app, tier o role. Si haces referencia a etiquetas de VM, debes agregar un prefijo a esta clave. Consulta la advertencia que sigue a esta lista.
  • SUBJECT_LABEL_VALUE: Es el valor asociado con el SUBJECT_LABEL_KEY. Por ejemplo, si SUBJECT_LABEL_KEY es app y SUBJECT_LABEL_VALUE es backend, las cargas de trabajo con la etiqueta app: backend reciben el tráfico.
  • PEER_LABEL_KEY: Es la clave de la etiqueta que se usa para seleccionar las cargas de trabajo de los pares. Si haces referencia a etiquetas de VM, debes agregar un prefijo a esta clave. Consulta la advertencia que sigue a esta lista.
  • PEER_LABEL_VALUE: Es el valor asociado con el PEER_LABEL_KEY.
  • ZONE_SUBJECT_LABEL_KEY: Es la clave de la etiqueta que se usa para seleccionar la zona del sujeto. Por ejemplo, zone o region. Si haces referencia a etiquetas de VM, debes agregar un prefijo a esta clave. Consulta la advertencia que sigue a esta lista.
  • ZONE_SUBJECT_LABEL_VALUE: Es el valor asociado con el ZONE_SUBJECT_LABEL_KEY. Por ejemplo, si ZONE_SUBJECT_LABEL_KEY es zone y ZONE_SUBJECT_LABEL_VALUE es us-central1-a, las cargas de trabajo con la etiqueta zone: us-central1-a reciben el tráfico.
  • ZONE_PEER_LABEL_KEY: Es la clave de la etiqueta que se usa para seleccionar la zona asociada con el par. Si haces referencia a etiquetas de VM, debes agregar un prefijo a esta clave. Consulta la advertencia que sigue a esta lista.
  • ZONE_PEER_LABEL_VALUE: Es el valor asociado con el ZONE_PEER_LABEL_KEY.
  Advertencia: Cuando hagas referencia a etiquetas de VM en los campos workloadSelector o workloads, debes anteponer el prefijo user-label.gpc.gke.io/ a la clave de la etiqueta. Por ejemplo, si asignas la etiqueta app: backend a una VM, debes especificarla como user-label.gpc.gke.io/app: backend para que coincida correctamente con la carga de trabajo. Este prefijo es específico para las VMs y no se aplica a ninguna otra carga de trabajo.

Crea una política dentro del proyecto para clústeres estándar

Los clústeres estándar son clústeres de Kubernetes con alcance para el proyecto que proporcionan mayor control, flexibilidad y permisos de administrador del clúster. Cuando creas una política dentro del proyecto, los clústeres estándar la heredan de forma predeterminada. Esta política permite toda la comunicación dentro de los clústeres estándar que residen en el mismo proyecto.

Crea una política de entrada dentro del proyecto para clústeres estándar

Cuando creas un proyecto, también creas de forma implícita un recurso ProjectNetworkPolicy base predeterminado que permite la comunicación dentro del proyecto entre todas las cargas de trabajo. Esta política permite el tráfico entrante de otras cargas de trabajo en el mismo proyecto y también permite la comunicación dentro del clúster entre todas las cargas de trabajo en los clústeres estándar dentro del proyecto.

Para crear una política de entrada entre proyectos para clústeres estándar, primero se debe borrar la política base predeterminada. De lo contrario, es posible que se produzca un comportamiento inesperado.

1. Para borrar la política básica predeterminada, ejecuta el siguiente comando:

   kubectl --kubeconfig GLOBAL_API_SERVER delete pnp base-policy-allow-intra-project-traffic -n PROJECT
   

   Puedes volver a agregar la política predeterminada aplicando el siguiente manifiesto:

   kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
   apiVersion: networking.global.gdc.goog/v1
   kind: ProjectNetworkPolicy
   metadata:
     namespace: PROJECT
     name: base-policy-allow-intra-project-traffic
   spec:
     policyType: Ingress
     ingress:
     - from:
       - projectSelector:
           projects:
             matchNames:
             - PROJECT
   EOF
   

   Reemplaza lo siguiente:

   • GLOBAL_API_SERVER: Es la ruta de acceso de kubeconfig del servidor de la API global. Para obtener más información, consulta Servidores de API globales y zonales. Si aún no generaste un archivo kubeconfig para el servidor de la API, consulta Acceder para obtener más detalles.
   • PROJECT: nombre del proyecto.

2. Para crear una política de ingreso de pod a pod dentro del clúster en clústeres estándar, crea y aplica el siguiente recurso personalizado:

   kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
   apiVersion: networking.global.gdc.goog/v1
   kind: ProjectNetworkPolicy
   metadata:
     namespace: STANDARD_CLUSTER_PROJECT
     name: allow-ingress-from-intra-cluster-traffic
   spec:
     policyType: Ingress
     subject:
       subjectType: UserWorkload
       userWorkloadSelector:
         labelSelector:
           clusters:
             matchLabels:
               kubernetes.io/metadata.name: STANDARD_CLUSTER_NAME
           namespaces:
             matchLabels:
               kubernetes.io/metadata.name: SUBJECT_NAMESPACE
           workloads:
             matchLabels:
               SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
     ingress:
     - from:
       - projectSelector:
           projects:
             matchNames:
             - STANDARD_CLUSTER_PROJECT
           workloadSelector:
             labelSelector:
               clusters:
                 matchLabels:
                   kubernetes.io/metadata.name: STANDARD_CLUSTER_NAME
               namespaces:
                 matchLabels:
                   kubernetes.io/metadata.name: PEER_NAMESPACE
               workloads:
                 matchLabels:
                   PEER_LABEL_KEY: PEER_LABEL_VALUE
   EOF
   

   Reemplaza lo siguiente:

   • GLOBAL_API_SERVER: Es la ruta de acceso de kubeconfig del servidor de la API global. Para obtener más información, consulta Servidores de API globales y zonales. Si aún no generaste un archivo kubeconfig para el servidor de la API, consulta Acceder para obtener más detalles.
   • STANDARD_CLUSTER_PROJECT: Es el nombre del proyecto del clúster estándar.
   • STANDARD_CLUSTER_NAME: Es el nombre del clúster estándar.
   • SUBJECT_NAMESPACE: Es el espacio de nombres del sujeto en el clúster estándar.
   • PEER_NAMESPACE: Es el espacio de nombres del par en el clúster estándar.
   • SUBJECT_LABEL_KEY: Es la clave de la etiqueta que se usa para seleccionar las cargas de trabajo del asunto. Por ejemplo, app, tier o role. Si haces referencia a etiquetas de VM, debes agregar un prefijo a esta clave. Consulta la advertencia que sigue a esta lista.
   • SUBJECT_LABEL_VALUE: Es el valor asociado con el SUBJECT_LABEL_KEY. Por ejemplo, si SUBJECT_LABEL_KEY es app y SUBJECT_LABEL_VALUE es backend, las cargas de trabajo con la etiqueta app: backend reciben el tráfico.
   • PEER_LABEL_KEY: Es la clave de la etiqueta que se usa para seleccionar las cargas de trabajo de los pares. Si haces referencia a etiquetas de VM, debes agregar un prefijo a esta clave. Consulta la advertencia que sigue a esta lista.
   • PEER_LABEL_VALUE: Es el valor asociado con el PEER_LABEL_KEY.
   Advertencia: Cuando hagas referencia a etiquetas de VM en los campos workloadSelector o workloads, debes anteponer el prefijo user-label.gpc.gke.io/ a la clave de la etiqueta. Por ejemplo, si asignas la etiqueta app: backend a una VM, debes especificarla como user-label.gpc.gke.io/app: backend para que coincida correctamente con la carga de trabajo. Este prefijo es específico para las VMs y no se aplica a ninguna otra carga de trabajo.

3. Para crear una política de ingreso de nodo a Pod dentro del clúster en clústeres estándar, crea y aplica el siguiente recurso personalizado:

   kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
   apiVersion: networking.global.gdc.goog/v1
   kind: ProjectNetworkPolicy
   metadata:
     namespace: STANDARD_CLUSTER_PROJECT
     name: allow-ingress-from-node-to-pod-traffic
   spec:
     policyType: Ingress
     subject:
       subjectType: UserWorkload
       userWorkloadSelector:
         labelSelector:
           clusters:
             matchLabels:
               kubernetes.io/metadata.name: STANDARD_CLUSTER_NAME
           namespaces:
             matchLabels:
               kubernetes.io/metadata.name: SUBJECT_NAMESPACE
           workloads:
             matchLabels:
               SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
     ingress:
     - from:
       - ipBlocks:
         - cidr: NODE_IP
       ports:
       - protocol: TCP
         port: PORT
   EOF
   

   Reemplaza lo siguiente:

   • GLOBAL_API_SERVER: Es la ruta de acceso de kubeconfig del servidor de la API global. Para obtener más información, consulta Servidores de API globales y zonales. Si aún no generaste un archivo kubeconfig para el servidor de la API, consulta Acceder para obtener más detalles.
   • STANDARD_CLUSTER_PROJECT: Es el nombre del proyecto del clúster estándar.
   • STANDARD_CLUSTER_NAME: Es el nombre del clúster estándar.
   • SUBJECT_LABEL_KEY: Es la clave de la etiqueta que se usa para seleccionar las cargas de trabajo del asunto. Por ejemplo, app, tier o role. Si haces referencia a etiquetas de VM, debes agregar un prefijo a esta clave. Consulta la advertencia que sigue a esta lista.
   • SUBJECT_LABEL_VALUE: Es el valor asociado con el SUBJECT_LABEL_KEY. Por ejemplo, si SUBJECT_LABEL_KEY es app y SUBJECT_LABEL_VALUE es backend, las cargas de trabajo con la etiqueta app: backend reciben el tráfico.
   • NODE_IP: Es la dirección IP del nodo.
   • PORT: Es el puerto de la carga de trabajo del asunto en el que se permite el tráfico.
   Advertencia: Cuando hagas referencia a etiquetas de VM en los campos workloadSelector o workloads, debes anteponer el prefijo user-label.gpc.gke.io/ a la clave de la etiqueta. Por ejemplo, si asignas la etiqueta app: backend a una VM, debes especificarla como user-label.gpc.gke.io/app: backend para que coincida correctamente con la carga de trabajo. Este prefijo es específico para las VMs y no se aplica a ninguna otra carga de trabajo.

Crea una política de salida dentro del proyecto para clústeres estándar

1. Para crear una política de pod a pod intra-clúster de salida en clústeres estándar, crea y aplica el siguiente recurso personalizado

   kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
   apiVersion: networking.global.gdc.goog/v1
   kind: ProjectNetworkPolicy
   metadata:
     namespace: STANDARD_CLUSTER_PROJECT
     name: allow-egress-to-intra-cluster-traffic
   spec:
     policyType: Egress
     subject:
       subjectType: UserWorkload
       userWorkloadSelector:
         labelSelector:
           clusters:
             matchLabels:
               kubernetes.io/metadata.name: STANDARD_CLUSTER_NAME
           namespaces:
             matchLabels:
               kubernetes.io/metadata.name: SUBJECT_NAMESPACE
           workloads:
             matchLabels:
               SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
     egress:
     - to:
       - projectSelector:
           projects:
             matchNames:
             - STANDARD_CLUSTER_PROJECT
           workloadSelector:
             labelSelector:
               clusters:
                 matchLabels:
                   kubernetes.io/metadata.name: STANDARD_CLUSTER_NAME
               namespaces:
                 matchLabels:
                   kubernetes.io/metadata.name: PEER_NAMESPACE
               workloads:
                 matchLabels:
                   PEER_LABEL_KEY: PEER_LABEL_VALUE
   EOF
   

   Reemplaza lo siguiente:

   • GLOBAL_API_SERVER: Es la ruta de acceso de kubeconfig del servidor de la API global. Para obtener más información, consulta Servidores de API globales y zonales. Si aún no generaste un archivo kubeconfig para el servidor de la API, consulta Acceder para obtener más detalles.
   • STANDARD_CLUSTER_PROJECT: Es el nombre del proyecto del clúster estándar.
   • STANDARD_CLUSTER_NAME: Es el nombre del clúster estándar.
   • SUBJECT_NAMESPACE: Es el espacio de nombres del sujeto en el clúster estándar.
   • PEER_NAMESPACE: Es el espacio de nombres del par en el clúster estándar.
   • SUBJECT_LABEL_KEY: Es la clave de la etiqueta que se usa para seleccionar las cargas de trabajo del asunto. Por ejemplo, app, tier o role. Si haces referencia a etiquetas de VM, debes agregar un prefijo a esta clave. Consulta la advertencia que sigue a esta lista.
   • SUBJECT_LABEL_VALUE: Es el valor asociado con el SUBJECT_LABEL_KEY. Por ejemplo, si SUBJECT_LABEL_KEY es app y SUBJECT_LABEL_VALUE es backend, las cargas de trabajo con la etiqueta app: backend envían el tráfico.
   • PEER_LABEL_KEY: Es la clave de la etiqueta que se usa para seleccionar las cargas de trabajo de los pares. Si haces referencia a etiquetas de VM, debes agregar un prefijo a esta clave. Consulta la advertencia que sigue a esta lista.
   • PEER_LABEL_VALUE: Es el valor asociado con el PEER_LABEL_KEY.
   Advertencia: Cuando hagas referencia a etiquetas de VM en los campos workloadSelector o workloads, debes anteponer el prefijo user-label.gpc.gke.io/ a la clave de la etiqueta. Por ejemplo, si asignas la etiqueta app: backend a una VM, debes especificarla como user-label.gpc.gke.io/app: backend para que coincida correctamente con la carga de trabajo. Este prefijo es específico para las VMs y no se aplica a ninguna otra carga de trabajo.
   1. Para crear una política de pod a nodo dentro del clúster de salida en clústeres estándar, crea y aplica el siguiente recurso personalizado:

   kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
   apiVersion: networking.global.gdc.goog/v1
   kind: ProjectNetworkPolicy
   metadata:
     namespace: STANDARD_CLUSTER_PROJECT
     name: allow-egress-from-pod-to-node-traffic
   spec:
     policyType: Egress
     subject:
       subjectType: UserWorkload
       userWorkloadSelector:
         labelSelector:
           clusters:
             matchLabels:
               kubernetes.io/metadata.name: STANDARD_CLUSTER_NAME
           namespaces:
             matchLabels:
               kubernetes.io/metadata.name: SUBJECT_NAMESPACE
           workloads:
             matchLabels:
               SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
     egress:
     - to:
       - ipBlocks:
         - cidr: NODE_IP
       ports:
       - protocol: TCP
         port: PORT
   EOF
   

   Reemplaza lo siguiente:

   • GLOBAL_API_SERVER: Es la ruta de acceso de kubeconfig del servidor de la API global. Para obtener más información, consulta Servidores de API globales y zonales. Si aún no generaste un archivo kubeconfig para el servidor de la API, consulta Acceder para obtener más detalles.
   • STANDARD_CLUSTER_PROJECT: Es el nombre del proyecto del clúster estándar.
   • STANDARD_CLUSTER_NAME: Es el nombre del clúster estándar.
   • SUBJECT_LABEL_KEY: Es la clave de la etiqueta que se usa para seleccionar las cargas de trabajo del asunto. Por ejemplo, app, tier o role. Si haces referencia a etiquetas de VM, debes agregar un prefijo a esta clave. Consulta la advertencia que sigue a esta lista.
   • SUBJECT_LABEL_VALUE: Es el valor asociado con el SUBJECT_LABEL_KEY. Por ejemplo, si SUBJECT_LABEL_KEY es app y SUBJECT_LABEL_VALUE es backend, las cargas de trabajo con la etiqueta app: backend envían el tráfico.
   • NODE_IP: Es la dirección IP del nodo.
   • PORT: Es el puerto de la IP del nodo al que se permite el tráfico.
   Advertencia: Cuando hagas referencia a etiquetas de VM en los campos workloadSelector o workloads, debes anteponer el prefijo user-label.gpc.gke.io/ a la clave de la etiqueta. Por ejemplo, si asignas la etiqueta app: backend a una VM, debes especificarla como user-label.gpc.gke.io/app: backend para que coincida correctamente con la carga de trabajo. Este prefijo es específico para las VMs y no se aplica a ninguna otra carga de trabajo.