github.com/cilium/cilium@v1.16.2/Documentation/security/network/identity.rst (about)

     1  .. only:: not (epub or latex or html)
     2  
     3      WARNING: You are looking at unreleased Cilium documentation.
     4      Please use the official rendered version released here:
     5      https://docs.cilium.io
     6  
     7  .. _arch_id_security:
     8  
     9  **************
    10  Identity-Based
    11  **************
    12  
    13  Container management systems such as Kubernetes deploy a networking model which
    14  assigns an individual IP address to each pod (group of containers). This
    15  ensures simplicity in architecture, avoids unnecessary network address
    16  translation (NAT) and provides each individual container with a full range of
    17  port numbers to use. The logical consequence of this model is that depending on
    18  the size of the cluster and total number of pods, the networking layer has to
    19  manage a large number of IP addresses.
    20  
    21  Traditionally security enforcement architectures have been based on IP address
    22  filters.  Let's walk through a simple example: If all pods with the label
    23  ``role=frontend`` should be allowed to initiate connections to all pods with
    24  the label ``role=backend`` then each cluster node which runs at least one pod
    25  with the label ``role=backend`` must have a corresponding filter installed
    26  which allows all IP addresses of all ``role=frontend`` pods to initiate a
    27  connection to the IP addresses of all local ``role=backend`` pods. All other
    28  connection requests should be denied. This could look like this: If the
    29  destination address is *10.1.1.2* then allow the connection only if the source
    30  address is one of the following *[10.1.2.2,10.1.2.3,20.4.9.1]*.
    31  
    32  Every time a new pod with the label ``role=frontend`` or ``role=backend`` is
    33  either started or stopped, the rules on every cluster node which run any such
    34  pods must be updated by either adding or removing the corresponding IP address
    35  from the list of allowed IP addresses. In large distributed applications, this
    36  could imply updating thousands of cluster nodes multiple times per second
    37  depending on the churn rate of deployed pods. Worse, the starting of new
    38  ``role=frontend`` pods must be delayed until all servers running
    39  ``role=backend`` pods have been updated with the new security rules as
    40  otherwise connection attempts from the new pod could be mistakenly dropped.
    41  This makes it difficult to scale efficiently.
    42  
    43  In order to avoid these complications which can limit scalability and
    44  flexibility, Cilium entirely separates security from network addressing.
    45  Instead, security is based on the identity of a pod, which is derived through
    46  labels.  This identity can be shared between pods. This means that when the
    47  first ``role=frontend`` pod is started, Cilium assigns an identity to that pod
    48  which is then allowed to initiate connections to the identity of the
    49  ``role=backend`` pod. The subsequent start of additional ``role=frontend`` pods
    50  only requires to resolve this identity via a key-value store, no action has to
    51  be performed on any of the cluster nodes hosting ``role=backend`` pods. The
    52  starting of a new pod must only be delayed until the identity of the pod has
    53  been resolved which is a much simpler operation than updating the security
    54  rules on all other cluster nodes.
    55  
    56  .. image:: _static/identity.png
    57      :align: center