Kubernetes policies allow you to have restricted access to the Kubernetes clusters in addition to the following:
  • Determine the privileges required for a CNF instantiation and LCM operation.
  • Assign global Kubernetes privileges to CNF templates or CNF instances.
  • Run HELM operations with a limited service account.

A service account provides non-interactive and non-human access to services within the Kubernetes cluster. Application Pods, system components, and entities, whether internal or external to the cluster, use specific service account credentials. TCA uses service accounts to communicate with Kubernetes.

The service accounts are generated in TCA during the Kubernetes VIM registration process or during the workload cluster creation.

The following diagram illustrates the usage of service accounts for accessing the Kubernetes API.
Figure 1. Diagram 1
TCA uses the service account provided during VIM registration for the following purposes: 
  • Interact with Kubernetes APIs
  • Create resources such as PODs, operators, and custom resource instances

    The PODs might use the service account to access the APIs.

    Operators are software extensions to Kubernetes that use custom resources to manage applications and their components. Operators follow Kubernetes principles, mainly the control loop principle. Custom resource models the Kubernetes application, which has a desired state and an actual state. The operator implements a custom controller to ensure that the desired state is equal to the actual state.

    The controller resides in a pod and interacts with Kubernetes API in a control loop to move the actual state to the desired state. The operator may perform (based on the designed CNF) scheduled jobs on the application. For example, it creates consistent backups. Operators are shipped in helm charts, including the custom resource definitions and the associated controllers.

    After the HELM resource construction phase is completed, TCA is not aware of what the operator does on the Kubernetes cluster, similar to a POD with access to the Kubernetes API.

The purpose of the Kubernetes policy in TCA is to control the access level of each of these entities to Kubernetes. Kubernetes prevents privilege escalation for their clients, which means that a service account cannot create another service account with a higher level of privilege than it already has. TCA builds on this principle by providing these entities with a restricted service account instead of the unrestricted service account. Kubernetes policy controls the level of restriction.

The level of restriction is defined through the permission model within TCA, which is illustrated in the following diagram.
Figure 2. Diagram 2
The following CNF-level permissions control access to the resources:
  • CNF LCM / READ: Controls lifecycle operation execution, deletion, and read access to a CNF instance. See Diagram 1.
  • VIM: Controls the VIM instance to which you can deploy network functions. See Diagram 2.
  • Namespace: Controls which namespaces you can use in the clusterIf the CNF is restricted to contain Kubernetes resources that reside in a namespace, then the application of namespace-based RBAC is sufficient. However, if the CNF needs to read (get, list, watch) or manage resources (create, update, patch, and delete) outside its namespaces, then Kubernetes policies need to be applied. See Diagram 3.
    Figure 3. Diagram 3