5G consists of CNFs in the form of container images and Helm charts from 5G network vendors. This section outlines the recommendations to deploy and maintain a secure container image registry using VMware Harbor.
5G consists of CNFs in the form of container images and Helm charts from 5G network vendors. Container images and Helm charts must be stored in registries that are always available and easily accessible. Public or cloud-based registries lack critical security compliance features to operate and maintain carrier-class deployments. Harbor solves those challenges by delivering trust, compliance, performance, and interoperability.
-
Image registry allows users to pull container images and the admins to publish new container images. Different categories of images are required to support Telco Applications. Some CNF images are required by all Tanzu Kubernetes users, while others are required only by specific Tanzu Kubernetes users. To maintain image consistency, Cloud admins might require the ability to ingest a set of golden CNF public images that all tenants can consume. Kubernetes admins might also require the images not offered by the cloud admin and may upload private CNF images or charts.
To support Telco applications, it is important to organize CNF images or helm charts into various projects and assign different access permissions for CNF images or Helm charts using RBAC. Integration with a federated identity provider is also important. Federated identity simplifies user management while providing enhanced security.
-
Container image scanning is important in maintaining and building container images. Irrespective of whether the image is built from source or from VNF vendors, it is important to discover any known vulnerabilities and mitigate them before the Tanzu Kubernetes cluster deployment.
-
Image signing establishes the image trust, ensuring that the image you run in your cluster is the image you intended to run. Notary digitally signs images using keys that allow service providers to securely publish and verify content.
-
Container image replication is essential for backup, disaster recovery, multi-datacenter, and edge scenarios. It allows a Telco operator to ensure image consistency and availability across many data centers based on a predefined policy.
Images that are not required for production must be bounded to a retention policy, so that obsoleted CNF images do not remain in the registry. To avoid a single tenant consuming all available storage resources, the resource quota must be set per tenant project.
| Design Recommendation |
Design Justification |
Design Implication |
|---|---|---|
| Integrate Harbor into existing User authentication providers such as OIDC or external LDAP/Active Directory server. |
|
Requires coordination between Harbor administrator and authentication provider. |
| Use Harbor projects to isolate container images between different users and groups. Within a Harbor project, map the users to roles based on the TCA persona. |
Role-based access control ensures that private container images can be accessed only by authorized users. |
None |
| Use quotas to control resource usage. Set a default project quota that applies to all projects and use project-level override to increase quota limits upon approval. |
Quota system is an efficient way to manage and control system utilization. |
None |
| Enable Harbor image Vulnerability Scanning. Images must be scanned during the container image ingest and daily as part of a scheduled task. |
|
None |
| Enable Harbor image signing. |
Establishes the image trust, ensuring that the image you run in your Kubernetes cluster is the image you intended to run. |
None |
|
|
None |
