1. Cloud Native Core Security Guide
  2. 4G/5G Core Network Function Security Recommendations and Procedures
  3. Cloud Native Core - Ingress/Egress Gateways - Security Recommendations / Procedures

Cloud Native Core - Ingress/Egress Gateways - Security Recommendations / Procedures

Enabling TLS and Ciphers in Ingress/Egress Gateway

Step Description
1 Helm Configuration to enable TLS:

To open Https port in Ingress gateway: configure in helm enableIncomingHttps: true

To have a Https client configured in Egress gateway: configure in helm enableOutgoingHttps: true
2 Create following files:
  1. RSA or ECDSA Private key (For example: rsa_private_key_pkcs1.pem)
  2. Trust store password (For example: trust.txt)
  3. Key store password(For example: key.txt)
  4. Certificate chain for trust store (For example: caroot.cer)
  5. Signed server certificate (For example: ocingress.cer) or Signed client certificate (For example: ocegress.cer)
Note: How to do the Creation of keys, certificates, password is on discretion of user or operator.
3 Create secret

Command :

$ kubectl create secret generic ocingress-secret --from-file=rsa_private_key_pkcs1.pem --from-file=trust.txt --from-file=key.txt --from-file=ocingress.cer --from-file=caroot.cer -n ocingress
4 Enable cipher suites:

# Cipher Suites to be enabled on Server side (Ingress Gateway),

# Cipher Suites to be enabled on Client side (Egress Gateway),

cipherSuites:

-TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

- TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256

- TLS_DHE_RSA_WITH_AES_256_GCM_SHA384

- TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

Note: The above list is the allowed cipher list as per Verizon requirement, this also coincides with the allowed list of ciphers as per Oracle standards. Helm deployment may fail due to invalid configuration or cipher suite mismatch. Manual restart of pod is required if there is update in cipher configuration during run time.

Certificate Management and Dynamic reload of certificates in Gateways

Whenever certificates gets compromised or a new certificate chain is required to be added to the truststore, we can update the key and truststore used by the application.

To update the key and the truststore, update or replace the secret:

Command:

$ kubectl create secret generic ocingress-secret --from-file=rsa_private_key_pkcs1.pem --from-file=trust.txt --from-file=key.txt --from-file=tmp.cer --from-file=caroot.cer --dry-run -o yaml -n ocingress| kubectl replace -f - -n ocingress

Whenever there is an update in the certificate chain or signed certificate placed in secret, kubernetes watcher which is implemented in update container will check for change in file state and replace the key and truststore accordingly in the mounted shared volume.

Dynamic reload of certificates is not supported in Ingress Gateway as of now, so a manual restart of pod is required when any update in the configuration is made with respect to https.

In case of Egress Gateway update container will trigger the rest end point to dynamically reload key and truststore. Then egress gateway will pickup new store files from shared volume and reload trust and key managers. Egress gateway will use the replaced store to establish new connections and gracefully terminate existing connections by sending a GOAWAY frame.