Security Recommendations

    To report a vulnerability in Antrea, please refer to SECURITY.md.

    For information about securing Antrea control-plane communications, refer to this .

    Like all other K8s Network Plugins, Antrea runs an agent (the Antrea Agent) on every Node on the cluster, using a K8s DaemonSet. And just like for other K8s Network Plugins, this agent requires a specific set of permissions which grant it access to the K8s API using RBAC. These permissions are required to implement the different features offered by Antrea. If any Node in the cluster happens to become compromised (e.g., by an escaped container) and the token for the ServiceAccount is harvested by the attacker, some of these permissions can be leveraged to negatively affect other workloads running on the cluster. In particular, the Antrea Agent is granted the following permissions:

    • patch the pods/status resources: a successful attacker could abuse this permission to re-label Pods to facilitate against built-in controllers. For example, making a Pod match a Service selector in order to man-in-the-middle (MITM) the Service traffic, or making a Pod match a ReplicaSet selector so that the ReplicaSet controller deletes legitimate replicas.

    In both cases, the Antrea Agent only requires the ability to mutate the annotations field for all Pods and Nodes, but with K8s RBAC, the lowest permission level that we can grant the Antrea Agent to satisfy this requirement is the patch verb for the status subresource for Pods and Nodes (which also provides the ability to mutate labels).

    Please ensure that the ValidatingWebhookConfiguration for your Gatekeeper installation enables policies to be applied on the pods/status and nodes/status subresources, which may not be the case by default.

    As a reference, the following ValidatingWebhookConfiguration rule will cause policies to be applied to all resources and their subresources:

    while the following rule will cause policies to be applied to all resources, but not their subresources:

    Antrea Controller

    The Antrea Controller, which runs as a single-replica Deployment, enjoys higher level permissions than the Antrea Agent. We recommend for production clusters running Antrea to schedule the Pod on a “secure” Node, which could for example be the Node (or one of the Nodes) running the K8s control-plane.

    Protecting Access to Antrea Configuration Files

    If a malicious Pod can gain read access to this file, or, prior to Antrea v0.10, if an attacker can gain access to the host, they can potentially access sensitive information stored in the database, most notably the Pre-Shared Key (PSK) used to configure IPsec tunnels, which is stored in plaintext in the database. If a PSK is leaked, an attacker can mount a man-in-the-middle attack and intercept tunnel traffic.

    If a malicious Pod can gain write access to this file, it can modify the contents of the database, and therefore impact network functions.

    Administrators of multi-tenancy clusters running Antrea should take steps to restrict the access of Pods to . One way to achieve this is to use a and restrict the set of allowed volumes to exclude hostPath. This guidance applies to all multi-tenancy clusters and is not specific to Antrea. To quote the K8s documentation: