Securing ECE Communications

Enabling SSL Communication When BRM and ECE Run in Separate Clusters

If BRM and ECE run in different Kubernetes clusters or cloud native environments, configure SSL communication between BRM and the External Manager (EM) Gateway.

To enable SSL communication:

In the CM configuration file (BRM_home/sys/cm/pin.conf), set the em_pointer parameter to the host name and port of either the emgateway service or the load balancer:
```
- cm em_pointer ece ip hostname port
```
where hostname is the worker node IP or LoadBalancer IP, and port is the emgateway service node port or LoadBalancer exposed port.
In your override-values.yaml file for oc-cn-ece-helm-chart, set the emgateway.serviceFqdn key to the dedicated worker node IP or load balancer IP.

You can use nodeSelector to schedule the EM Gateway pod on specific worker nodes.
Provide the BRM client and server wallets that ECE requires for secure communication with BRM.

You can provide each wallet in either of the following ways:
- Add the complete client wallet to oc-cn-ece-helm-chart/secrets/brmwallet/client/.
  
  Add the complete server wallet to oc-cn-ece-helm-chart/secrets/brmwallet/server/.
- Create Kubernetes secrets that contain the complete client and server wallets. In override-values.yaml, set charging.extBRMClientWalletSecret and charging.extBRMServerWalletSecret to the names of the corresponding secrets.
If you use external Kubernetes secrets, create them in the namespace in which you install the ECE Helm chart. Each secret must contain all of the files required by its wallet.
Configure SSL and the BRM wallet settings in override-values.yaml. For example:
```
emgateway:
  emGatewayList:
    - coherenceMemberName: "emgateway1"
      emGatewayConfiguration:
        sslEnabled: "1"

charging:
  extBRMClientWalletSecret: "client-wallet-secret"
  extBRMServerWalletSecret: "server-wallet-secret"
  brmWalletServerLocation: "cwallet.sso"
  connectionConfigurations:
    BRMConnectionConfiguration:
      sslEnabled: "1"
      brmwallet: "cwallet.sso"
```
If you provide wallet files through the Helm chart instead of external Kubernetes secrets, omit the corresponding extBRMClientWalletSecret or extBRMServerWalletSecret setting.

Specify only the wallet file name, such as cwallet.sso. Do not specify an absolute or relative wallet path. The ECE Helm chart constructs the complete runtime path and mounts the selected wallets in the appropriate pods.

When you enable SSL for BRMConnectionConfiguration, the ECE Helm chart mounts the client wallet read-only in BRM Gateway. When you enable SSL for at least one EM Gateway, the chart mounts the server wallet read-only in the EM Gateway pods. ECE does not create or generate BRM client or server wallets at runtime.

Note:

RADIUS Gateway retrieves the BRM root-key wallet from the BRM database. You do not provide or configure a BRM root-key wallet for RADIUS Gateway in the ECE Helm deployment.
Provide the ECE wallet password and BRM Gateway password by using the supported secret configuration. In override-values.yaml, configure the required secretEnv settings, including:
- secretEnv.walletPassword: Specifies the password for the ECE wallet.
- secretEnv.BRMGATEWAYPASSWORD: Specifies the BRM Gateway password that ECE uses to connect to CM.
If you use a precreated external Kubernetes secret for the ECE secret configuration, set secretEnv.extECESecret to the name of the secret. Ensure that the secret contains the values required by the ECE deployment.

Note:

The ECE secret configured by secretEnv.extECESecret is separate from the BRM client and server wallet secrets configured by charging.extBRMClientWalletSecret and charging.extBRMServerWalletSecret.

If you are deploying ECE for the first time, install the ECE Helm chart:

helm install ECEReleaseName oc-cn-ece-helm-chart --namespace BRMNamespace --values overrideValuesFile

If ECE is already deployed, update the applicable wallet secrets or wallet files and run a Helm upgrade. Restart the affected ECE pods as required so that they use the updated wallet and secret data. See "Rolling Restart of ECE Pods" for more information.

Using Customer-Provided TLS Certificates for BRM Communication

You can use customer-provided TLS certificates to secure communication between ECE and BRM. ECE does not include or generate BRM client or server wallets. You provide the complete wallets that ECE uses for TLS communication.

You can provide each BRM wallet by adding the wallet files to the ECE Helm chart or by using an existing Kubernetes secret.

To configure customer-provided TLS certificates for BRM communication:

Create the BRM client and server wallets that your deployment requires.

The client wallet contains the certificates that BRM Gateway uses when it connects to BRM. The server wallet contains the certificates that EM Gateway uses for its TLS listener.
Provide the wallets by using one of the following methods:
- To provide wallet files through the ECE Helm chart, add the complete wallets to these directories:
```
oc-cn-ece-helm-chart/secrets/brmwallet/client/
oc-cn-ece-helm-chart/secrets/brmwallet/server/
```
- To use existing Kubernetes secrets, create separate secrets for the client and server wallets. Each secret must contain all files required by its wallet and must exist in the namespace in which you install the ECE Helm chart.
If you use existing Kubernetes secrets, specify their names in the override-values.yaml file for oc-cn-ece-helm-chart:
```
charging:
  extBRMClientWalletSecret: "client-wallet-secret"
  extBRMServerWalletSecret: "server-wallet-secret"
```
If you provide a wallet through the Helm chart instead, omit the corresponding external secret setting.

Configure the wallet file names and enable TLS for the ECE components that use the wallets. The following example uses existing Kubernetes secrets for both wallets:

emgateway:
  emGatewayList:
    - coherenceMemberName: "emgateway1"
      emGatewayConfiguration:
        sslEnabled: "1"

charging:
  extBRMClientWalletSecret: "client-wallet-secret"
  extBRMServerWalletSecret: "server-wallet-secret"
  brmWalletServerLocation: "cwallet.sso"
  connectionConfigurations:
    BRMConnectionConfiguration:
      sslEnabled: "1"
      brmwallet: "cwallet.sso"

Install or upgrade the ECE Helm chart.

When you enable TLS for BRMConnectionConfiguration, the Helm chart mounts the BRM client wallet read-only in BRM Gateway. When you enable TLS for at least one EM Gateway, the chart mounts the BRM server wallet read-only in the EM Gateway pods. ECE does not generate either wallet at runtime.

Note:

RADIUS Gateway retrieves the BRM root-key wallet from the BRM database. You do not provide a root-key wallet or configure a root-wallet path for RADIUS Gateway in the ECE Helm deployment.

Securing Communication Between the CHF and NRF, PCF, and SMF

You can enable secure communication between the HTTP Gateway (CHF) and the NRF, PCF, and SMF in one of these ways:

Using KeyStore certificates stored in the cloud native Helm charts. See "Securing Communication Using KeyStores Mounted in the Helm Chart".
Using external Kubernetes Secrets. See "Securing Communication Using External Kubernetes Secrets".

Securing Communication Using KeyStores Mounted in the Helm Chart

To enable secure communication between the HTTP Gateway (CHF) and the NRF, PCF, and SMF using KeyStores mounted in the Helm chart:

Generate your SSL TrustStore and Identity KeyStore certificates for the NRF, PCF, and SMF.
Move the SSL TrustStore and Identity KeyStore certificate files to the oc-cn-ece-helm-chart/secrets/httpgateway directory.

When you perform a Helm install or upgrade, the ECE Helm chart mounts the TrustStore and Identity KeyStores inside the httpgateway pods as a Kubernetes Secret.
Open your override-values.yaml file for oc-cn-ece-helm-chart.
Enable SSL-based communication between the CHF and the PCF, NRF, and SMF by setting the following keys under httpgateway.httpgatewayList.httpGatewayConfiguration:
- pcfSSLEnabled: Set this to true to enable SSL-based communication between the CHF and PCF.
- nrfSSLEnabled: Set this to true to enable SSL-based communication between the CHF and NRF.
- smfSSLEnabled: Set this to true to enable SSL-based communication between the CHF and SMF.
- httpSSLType: Specify the type of SSL communication: oneway or twoway.
Specify the name and location of the TrustStore and Identity KeyStore files by setting the following keys under httpgateway:
- httpIdentityKeystore: Specify the path to the Identity KeyStore certificate files.
- httpIdentityKeystoreType: Specify the type of SSL Identity KeyStore: PKCS12 or SSO.
- httpTruststore: Specify the path to the SSL TrustStore files.
- httpTruststoreType: Specify the type of SSL TrustStore file: PKCS12 or SSO.
If your ECE cloud native services route communication between the CHF and other network functions through an Oracle Services Communications Proxy (SCP), do the following:
1. In the httpgateway.httgatewayList.httpGatewayConfiguration.scpAuthorities key, enter the URL of the primary and secondary SCP authority, delimited by commas.
  
  For example: scpAuthorities="scp1.example.com,scp2.example.com".
2. Ensure that the oc-cn-ece-helm-chart/secrets/httpgateway/ directory contains the SCP SSL KeyStore certificates rather than PCF and SMF certificates.
See "Configuring Communication through SCP" in ECE Implementing Charging for more information about SCP.
Run the helm install or helm upgrade command to update the ECE Helm chart.

The KeyStores are mounted inside the httpgateway pod as a Kubernetes Secret at /home/charging/mnt/secrets/httpgateway/server_ssl.

Securing Communication Using External Kubernetes Secrets

To enable secure communication between the HTTP Gateway (CHF) and the NRF, PCF, and SMF using external Kubernetes Secrets:

Create your KeyStore certificates for the NRF, PCF, and SMF as Secrets in your Kubernetes cluster.

Note:

If communication is routed through an Oracle Services Communications Proxy (SCP), create SCP-related certificates instead.

For information about creating Kubernetes Secrets, see "Managing Secrets" in the Kubernetes documentation.
Open your override-values.yaml file for oc-cn-ece-helm-chart.
Specify the external Kubernetes Secrets by setting the following keys under httpgateway:
- extHttpIdentityKeystoreSecret: Specify the name of the external Kubernetes Secret containing the HTTP Identity KeyStore.
- httpIdentityKeystore: Specify the name of the Identity KeyStore certificate file contained in the external Kubernetes Secret.
- httpTruststore: Specify the name of the SSL TrustStore file contained in the external Kubernetes Secret.
- extHttpTruststoreSecret: Specify the name of the external Kubernetes Secret containing the HTTP TrustStore.
If your ECE cloud native services route communication between the CHF and other network functions through an Oracle Services Communications Proxy (SCP), set the httpgateway.httgatewayList.httpGatewayConfiguration.scpAuthorities key to the URL of the primary and secondary SCP authority, delimited by commas.

For example: scpAuthorities="scp1.example.com,scp2.example.com".

See "Configuring Communication through SCP" in ECE Implementing Charging for more information about SCP.
Perform a helm install of the ECE Helm chart:
```
helm install EceReleaseName oc-cn-ece-helm-chart --namespace BrmNameSpace --values OverrideValuesFile
```
where:
- EceReleaseName is the release name for oc-cn-ece-helm-chart and is used to track this installation instance. It must be different from the one used for the BRM Helm chart.
- BrmNameSpace is the namespace in which BRM Kubernetes objects reside for the BRM Helm chart.
- OverrideValuesFile is the path to a YAML file that overrides the default configurations in the oc-cn-ece-helm-chart/values.yaml file.

28 Securing ECE Communications

Enabling SSL Communication When BRM and ECE Run in Separate Clusters

Using Customer-Provided TLS Certificates for BRM Communication

Securing Communication Between the CHF and NRF, PCF, and SMF

Securing Communication Using KeyStores Mounted in the Helm Chart

Securing Communication Using External Kubernetes Secrets