Versions Compared

Old Version 1

changes.mady.by.user Ribbon Communications

Saved on

compared with

New Version Current

changes.mady.by.user Ribbon Communications

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

 

Add_workflow_for_techpubs
AUTH1UserResourceIdentifier{userKey=8a00a0c86e9b2550016ec54396b5000a, userName='null'}
JIRAIDAUTHSBX-130579131910
REV5UserResourceIdentifier{userKey=8a00a02355cd1c2f0155cd26cb8305e9, userName='null'}
REV6UserResourceIdentifier{userKey=8a00a02355cd1c2f0155cd26cd5909df, userName='null'}
REV3UserResourceIdentifier{userKey=8a00a02355cd1c2f0155cd26c95c02598a00a0c87aff3cc3017b370aaf8b005a, userName='null'}
REV1UserResourceIdentifier{userKey=8a00a02355cd1c2f0155cd26c95c02598a00a0c87aff3cc3017b370aaf8b005a, userName='null'}

Available_since
TypeAvailable Since
Release12.1.2


Excerpt

The Transport Layer Security (TLS) certificates secure the communication between components within the cluster. The TLS offers trust, data integrity, and encryption, preventing unauthorized access to and tampering with sensitive data. As the number of cloud-native workloads and applications increases in modern communication environments, managing the TLS certificates for each application exposed to the SBC and SBC-RAMP deployment workloads is challenging since security is a high-priority concern for organizations.

Possessing a tool that makes certificate management easier is critical to operationalizing TLS implementation in cloud-native applications. The Mutual Transport Layer installs the certificate Security (mTLS) between the pods and protects workloads against attacks from within. The SBC exposes the certificates to the pod in two ways: 

  1. Embedded certificate inside the Docker container (Not a recommended method since compromising occurs at the pod)
  2. The cluster operator creates the certificates and installs them in the pod or exposes them through the environment variables or Kubernetes secrets.

To resolve these issues, the SBC CNe is enhanced to support centralized certificate management. The Cert Manager and the CSI Driver bring solutions to mitigate these issues and improve security management.

Cert-Manager

The Cert-Manager is a Kubernetes or OpenShift add-on designed to assist in creating and managing TLS X.509 certificates. It issues certificates from various certificate issuers, including Let's Encrypt, HashiCorp Vault, and Venafi. The Cert-Manager adds certificates and certificate issuers as resource types in the Kubernetes cluster, simplifying obtaining, renewing, and using those certificates. It ensures certificates are valid and up to date and attempts to renew certificates at a configured time before the expiry date.

CSI Driver

The Container Storage Interface (CSI) is a standard for exposing arbitrary block and file storage systems to containerized workloads on Container Orchestration Systems (COs) such as Kubernetes. The CSI-driver is a plugin designed for Kubernetes that works alongside the cert-manager. The Pods that mount the cert-manager CSI-driver request certificates from the cert-manager without a requirement to create a certificate resource. These certificates are mounted directly into the Pod without creating an intermediate secret. For more information, refer to https://cert-manager.io/docs/usage/csi-driver/.

Certificate Object

Configure the Certificate Object for certificate requests. Once this is configured, every deployment (For example, SC, SLB, OAM, and so on) will hold its own certificate, and all the replicas (Pods of that deployment) will share that certificate. For more information, refer to https://cert-manager.io/docs/usage/certificate/#creating-certificate-resources.

Info
titleNote

When you upgrade the deployment using the cert-object with an incorrect issuer, the Secret type remains as Opaque until you perform an upgrade with the correct issuer.

User Provided Secret

The user can use third-party certificates to place inside a Kubernetes secret and configure it (The Cert-Manager is not involved in this scenario).

Info
titleNote

Ribbon does not recommend using public certificate authorities, that hold strict rate limits on the number of certificates you can issue for a single domain. Similar to pods, these certificate key pairs are non-immutable, and you can create and destroy them anytime during regular operation. Using self-signed issuers with the CSI Driver is impossible because self-signed issuers are a particular case.