Cuando implemente NCP, es importante que realice los pasos pertinentes para asegurar los entornos de Kubernetes y de NSX-T Data Center.

Restringir NCP para que solo se ejecute en nodos designados

NCP tiene acceso al plano de administración de NSX-T Data Center y se debe limitar para que solo se ejecute en nodos de infraestructura designados. Puede identificar estos nodos con una etiqueta apropiada. Se debe aplicar un nodeSelector de esta etiqueta a la especificación ReplicationController de NCP. Por ejemplo,

  nodeSelector:
      nsx-infra: True

También puede usar otros mecanismos, como la afinidad, para asignar pods a nodos. Para obtener más información, consulte https://kubernetes.io/docs/concepts/configuration/assign-pod-node.

Asegurarse de que Docker Engine esté actualizado

Docker publica periódicamente actualizaciones de seguridad. Se debe implementar un procedimiento automatizado para aplicar esas actualizaciones.

No permitir las funciones NET_ADMIN y NET_RAW de contenedores sin confianza

Los atacantes pueden aprovechar las funciones NET_ADMIN y NET_RAW de Linux para poner en peligro la red de pods. Debe deshabilitar estas dos funciones de contenedores en los que no confía. De forma predeterminada, la función NET_ADMIN no se otorga a un contenedor sin privilegios. Tenga en cuenta que una especificación de pod puede habilitarla o establecer el contenedor en modo privilegiado. Además, en los contenedores que no son de confianza, deshabilite NET_RAW especificando este valor en la lista de funciones descartadas en la configuración SecurityContext de la especificación del contenedor. Por ejemplo,

    securityContext:
       capabilities:
          drop:
            - NET_RAW
            - ...

Control de acceso basado en funciones

Kubernetes usa la API del Control de acceso basado en funciones (Role-Based Access Control, RBAC) para tomar decisiones de autorización, permitiendo que los administradores configuren directivas. Para obtener más información, consulte https://kubernetes.io/docs/admin/authorization/rbac.

Por lo general, el administrador de clústeres es el único usuario con funciones y acceso privilegiados. Para las cuentas del servicio y de usuarios, se debe seguir el principio de mínimo privilegio al otorgar acceso.

Se recomienda seguir las siguientes instrucciones:

  • Restringir el acceso a los tokens de la API de Kubernetes de los pods que los necesiten.
  • Restringir el acceso a ConfigMap de NCP y a los secretos TLS del certificado cliente de NSX API al pod de NCP.
  • Bloquear el acceso a la API de redes de Kubernetes desde pods que no requieran dicho acceso.
  • Agregar una directiva RBAC de Kubernetes para especificar los pods que tienen acceso a la API de Kubernetes.

Directiva de RBAC recomendada para el pod de NCP

Cree el pod de NCP en un ServiceAccount y otorgue un conjunto mínimo de privilegios a esta cuenta. Además, no permita que otros pods ni ReplicationControllers accedan a ConfigMap ni a los secretos TLS que se montan como volúmenes para ReplicationController de NCP y el agente del nodo de NSX.

El siguiente ejemplo muestra cómo se especifican funciones y enlaces de funciones de NCP:

  # Create a ServiceAccount for NCP namespace
  apiVersion: v1
  kind: ServiceAccount
  metadata:
   name: ncp-svc-account
   namespace: nsx-system
  
  ---
  
  # Create ClusterRole for NCP
  kind: ClusterRole
  # Set the apiVersion to v1 while using OpenShift
  apiVersion: rbac.authorization.k8s.io/v1beta1
  metadata:
   name: ncp-cluster-role
  rules:
   - apiGroups:
     - ""
     - extensions
     - networking.k8s.io
     resources:
       - deployments
       - endpoints
       - pods
       - pods/log
       - namespaces
       - networkpolicies
       # Move 'nodes' to ncp-patch-role when hyperbus is disabled.
       - nodes
       - replicationcontrollers
       # Remove 'secrets' if not using Native Load Balancer.
       - secrets
     verbs:
       - get
       - watch
       - list
  
  ---
  
  # Create ClusterRole for NCP to edit resources
  kind: ClusterRole
  # Set the apiVersion to v1 while using OpenShift
  apiVersion: rbac.authorization.k8s.io/v1beta1
  metadata:
   name: ncp-patch-role
  rules:
   - apiGroups:
     - ""
     - extensions
     resources:
       - ingresses
       - services
     verbs:
       - get
       - watch
       - list
       - update
       - patch
   - apiGroups:
     - ""
     - extensions
     resources:
       - ingresses/status
       - services/status
     verbs:
       - replace
       - update
       - patch
  ---
  
  # Bind ServiceAccount created for NCP to its ClusterRole
  kind: ClusterRoleBinding
  # Set the apiVersion to v1 while using OpenShift
  apiVersion: rbac.authorization.k8s.io/v1beta1
  metadata:
   name: ncp-cluster-role-binding
  roleRef:
   # Comment out the apiGroup while using OpenShift
   apiGroup: rbac.authorization.k8s.io
   kind: ClusterRole
   name: ncp-cluster-role
  subjects:
   - kind: ServiceAccount
     name: ncp-svc-account
     namespace: nsx-system
  
  ---
  
  # Bind ServiceAccount created for NCP to the patch ClusterRole
  kind: ClusterRoleBinding
  # Set the apiVersion to v1 while using OpenShift
  apiVersion: rbac.authorization.k8s.io/v1beta1
  metadata:
   name: ncp-patch-role-binding
  roleRef:
   # Comment out the apiGroup while using OpenShift
   apiGroup: rbac.authorization.k8s.io
   kind: ClusterRole
   name: ncp-patch-role
  subjects:
   - kind: ServiceAccount
     name: ncp-svc-account
     namespace: nsx-system
Nota: Todos los pods que tengan acceso al servidor API de Kubernetes deben tener acceso al secreto TLS que se crea usando la API de Kubernetes para el certificado cliente de NSX-T Data Center y el par de claves privadas. De forma similar, cuando un pod se crea sin cuenta del servicio, se asigna automáticamente la predeterminada en el mismo espacio de nombres que monta automáticamente el token para acceder a la API de Kubernetes. Por ello, el acceso a los tokens debe estar limitado únicamente a los pods que los necesitan.