En Antrea, un nivel consta de ciertas directivas de red que se agrupan de forma jerárquica. Una NetworkPolicy
nativa de Antrea o una definición de recursos personalizada (CRD) ClusterNetworkPolicy
incluye una referencia opcional al nivel al que pertenece. Durante el filtrado del tráfico de red, las directivas de red de Antrea que están asociadas con niveles de mayor orden (que tienen un valor de prioridad numérica bajo) se aplican en primer lugar. Para obtener más información sobre los diversos tipos de niveles en Antrea, consulte CRD de directiva de red de Antrea.
El acceso basado en funciones a un nivel está diseñado para garantizar que solo los usuarios autorizados puedan hacer referencia a un nivel en las directivas nativas de Antrea. Permite que un administrador de clústeres asocie NetworkPolicies de Antrea a un nivel de prioridad alta e impide que un usuario normal asocie NetworkPolicies de Antrea al nivel. Esta función ayuda al administrador de clústeres a aplicar directivas de seguridad en un clúster, que un usuario normal no puede anular.
Antrea proporciona seis niveles con prioridades estáticas. De forma predeterminada, solo los administradores de Kubernetes pueden crear niveles personalizados en Antrea. Para proporcionar a los usuarios permisos para crear nuevos niveles y editar las prioridades de nivel, configure los ajustes ClusterRole
y ClusterRoleBinding
en el contexto del clúster de carga de trabajo.
Cambie al contexto del clúster de carga de trabajo:
kubectl config use-context *WORKLOAD-CLUSTER-CONTEXT*
Cree un archivo YAML ClusterRoleBinding
, como se muestra en el siguiente ejemplo (al usuario securityops
se le proporcionó la capacidad de leer, crear, eliminar y actualizar los recursos de nivel):
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: tier-edit
rules:
- apiGroups: ["crd.antrea.io"]
resources: ["tiers"]
verbs: ["get", "list", "create", "patch", "update", "delete"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: tier-bind
subjects:
- kind: User
name: securityops # Name is case sensitive
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: tier-edit
apiGroup: rbac.authorization.k8s.io
Aplique las definiciones:
kubectl apply -f ClusterRoleBinding.yaml
De forma predeterminada, cualquier usuario puede asociar una directiva de red de Antrea a cualquier nivel. Para proporcionar permisos a un conjunto de usuarios para hacer referencia a un nivel en una directiva de red de Antrea y bloquear todos los demás usuarios, cree un CRD TierEntitlement
y asigne la autorización a los usuarios permitidos a través de un CRD TierEntitlementBinding
.
Cambie al contexto del clúster de carga de trabajo:
kubectl config use-context *WORKLOAD-CLUSTER-CONTEXT*
Cree un archivo YAML de CRD TierEntitlement
, como se muestra en el siguiente ejemplo:
apiVersion: crd.antrea.tanzu.vmware.com/v1alpha1
kind: TierEntitlement
metadata:
name: emergency-edit
spec:
tiers: ["emergency"]
permission: "edit"
Nota
Edit
es el único permiso válido aquí. Permite a los usuarios autorizados crear, eliminar, actualizar y aplicar revisiones a las directivas nativas de Antrea que pertenecen a los niveles enumerados.
Aplique el CRD:
kubectl apply -f TierEntitlement.yaml
Cree un archivo YAML de CRD TierEntitlementBinding
para asociar la autorización a los usuarios, como se muestra en este ejemplo:
apiVersion: crd.antrea.tanzu.vmware.com/v1alpha1
kind: TierEntitlementBinding
metadata:
name: emergency-sec-bind
spec:
subjects:
- kind: User
name: securityops
apiGroup: rbac.authorization.k8s.io
- kind: Group
name: security-admins
apiGroup: rbac.authorization.k8s.io
- kind: ServiceAccount
name: network-admins
namespace: kube-system
tierEntitlement: emergency-edit
En este ejemplo, la autorización de nivel emergency-edit
se asignó a los usuarios especificados en el campo subjects
. Los usuarios compatibles que se pueden especificar en subjects
son Usuario (User), Grupo (Group) y Cuenta de servicio (ServiceAccount). Para obtener más información, consulte Usar autorización RBAC.
Aplique el CRD:
kubectl apply -f TierEntitlementBinding.yaml
En los dos archivos YAML de ejemplo anteriores, el nivel emergency
se controla mediante la autorización de nivel emergency-edit
. A los usuarios a los que se asigna la autorización emergency-edit
se les conceden ciertos permisos, mientras que otros usuarios (denominados normalUser
) no pueden realizar ciertas acciones. Por ejemplo:
securityops
puede crear una instancia ClusterNetworkPolicy (ACNP) de Antrea o una instancia NetworkPolicy de Antrea (ANP), que tiene una referencia al nivel emergency
en sus especificaciones.securityops
puede actualizar o aplicar revisiones a un ACNP o un ANP existentes, y agregar una referencia al nivel emergency
en sus especificaciones (si el usuario securityops
tiene permiso para editar una referencia al nivel existente).securityops
puede actualizar o aplicar revisiones a un ACNP o ANP existente, y eliminar la referencia al nivel emergency
de sus especificaciones.securityops
puede eliminar un ACNP o un ANP existente, que tiene una referencia al nivel emergency
en sus especificaciones.securityops
puede obtener los detalles de un ACNP o un ANP existente, que tiene una referencia al nivel emergency
en sus especificaciones.normalUser
que intenta crear un ACNP o un ANP, que tiene una referencia al nivel emergency
en sus especificaciones.normalUser
que intenta eliminar un ACNP o un ANP, que tiene una referencia al nivel emergency
en sus especificaciones.normalUser
que intenta actualizar o aplicar revisiones a un ACNP o ANP, que tiene una referencia al nivel emergency
en sus especificaciones.NotaPara saber cómo establecer directivas de red de clúster para Antrea, consulte Establecer directivas de red de clúster para Antrea.