In Antrea, a Tier consists of certain network policies that are grouped in a hierarchical way. An Antrea-native NetworkPolicy
or a ClusterNetworkPolicy
custom resource definition (CRD) includes an optional reference to the Tier that it belongs to. During the filtering of network traffic, Antrea NetworkPolicies that are associated with higher-ordered Tiers (which have a low numerical priority value) are enforced first. For more information on the various types of Tiers in Antrea, see Antrea Network Policy CRDs.
The role-based access to a Tier is designed to ensure that only the authorized users can reference a Tier in the Antrea-native policies. It lets a cluster admin attach Antrea NetworkPolicies to a high priority Tier and prevents a normal user from attaching Antrea NetworkPolicies to the Tier. This feature helps the cluster admin enforce security policies in a cluster, which cannot be overridden by a normal user.
Antrea provides six Tiers with static priorities. By default, only the Kubernetes administrators can create custom Tiers in Antrea. To provide users permissions to create new Tiers and edit the Tier priorities, configure the ClusterRole
and the ClusterRoleBinding
settings in the workload cluster context.
Switch to the workload cluster context:
kubectl config use-context *WORKLOAD-CLUSTER-CONTEXT*
Create a ClusterRoleBinding
YAML file, as shown in the following example (The securityops
user has been provided the ability to read, create, delete, and update the Tier resources):
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
Apply the definitions:
kubectl apply -f ClusterRoleBinding.yaml
By default, any user can attach an Antrea Network Policy to any Tier. To provide permissions to a set of users to reference a Tier in an Antrea Network Policy, and block all the other users, create a TierEntitlement
CRD, and assign the entitlement to the allowed users through a TierEntitlementBinding
CRD.
Switch to the workload cluster context:
kubectl config use-context *WORKLOAD-CLUSTER-CONTEXT*
Create a TierEntitlement
CRD YAML file, as shown in the following example:
apiVersion: crd.antrea.tanzu.vmware.com/v1alpha1
kind: TierEntitlement
metadata:
name: emergency-edit
spec:
tiers: ["emergency"]
permission: "edit"
Note
Edit
is the only permission that is valid here. It allows the entitled users to create, delete, update, and patch the Antrea-native policies that belong to the listed Tiers.
Apply the CRD:
kubectl apply -f TierEntitlement.yaml
Create a TierEntitlementBinding
CRD YAML file to associate the entitlement to the users, as shown in this example:
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
In this example, the emergency-edit
Tier entitlement has been assigned to the users that are specified under the subjects
field. Supported users that can be specified under subjects
are User, Group and ServiceAccount. For more information, see Using RBAC Authorization.
Apply the CRD:
kubectl apply -f TierEntitlementBinding.yaml
In the two sample YAML files above, the emergency
Tier is controlled by the emergency-edit
Tier entitlement. The users that are assigned the emergency-edit
entitlement are granted certain permissions, while other users (referred to as normalUser
) cannot perform certain actions. For instance:
securityops
user can create an Antrea ClusterNetworkPolicy (ACNP) or an Antrea NetworkPolicy (ANP), which has a reference to the emergency
Tier in its spec.securityops
user can update or patch an existing ACNP or an ANP, and add a reference to the emergency
Tier in its spec (If the securityops
user has the permission to edit a reference to the existing Tier).securityops
user can update or patch an existing ACNP or an ANP, and remove the reference to the emergency
Tier from its spec.securityops
user can delete an existing ACNP or an ANP, which has a reference to the emergency
Tier in its spec.securityops
user can get the details of an existing ACNP or an ANP, which has a reference to the emergency
Tier in its spec.normalUser
, who attempts to create an ACNP or an ANP, which has a reference to the emergency
Tier in its spec, is denied permission.normalUser
, who attempts to delete an ACNP or an ANP, which has a reference to the emergency
Tier in its spec, is denied permission.normalUser
, who attempts to update or patch an ACNP or an ANP, which has a reference to the emergency
Tier in its spec, is denied permission.NoteTo know how to set cluster network policies for Antrea, see Set Cluster Network Policies for Antrea.