Implementing Security Recommendations and Guidelines

3 Implementing Security Recommendations and Guidelines

3.1 Common Security Recommendations and Guidelines

This section provides details of the common security recommendations and guidelines, irrespective of the NFs.

3.1.1 4G and 5G Application Authentication and Authorization

Mutual Transport Layer Security (mTLS) is a type of authentication in which the two parties in a connection authenticate each other using the TLS protocol. mTLS ensures that the traffic is secure and trusted in both directions between a client and server. Cloud Native Core NFs support integration with platform service meshes and Mutual Transport Layer Security (mTLS) may be provided by the platform service mesh, thereby securing communication flows between all applications that participate in the platform service mesh. mTLS also encrypts the data flows so that only the endpoints of the mTLS session can access the contents of the communication data.

4G and 5G NFs use Mutual Transport Layer Security (mTLS) authentication to secure communication. All NFs require to establish a trust relationship with all peers by exchanging and trusting peer root or intermediate certificates. The peer certificates must be available in the truststore (K8s Secrets) to establish secure communication.

4G and 5G NFs also support manual importation and a semiautomatic import using the cert-manager external provider.

3.1.2 cnDBTier Authentication and Authorization

The cnDBTier provides a highly available multisite database that stores NF state and configuration. When installed, the MySQL DB is configured with a root account whose password is randomly generated. Each NF must have additional accounts for that particular NF.

The procedures in this section explain the following:

Changing cnDBTier Passwords

Note:

The roles of DB Administrator and Kubernetes cluster administrator must be kept separate. The DB Administrator must be responsible for securing and maintaining the cnDBTier MySQL NDB cluster. The Kubernetes cluster administrator must be responsible for securing and operating the Bastion Host and Kubernetes Cluster. When 5G NFs are installed, the DB Administrator is required to create new NF database and NF DB accounts (using the DB Root credentials). Once this is completed, the Kubernetes cluster administrator installs the NF.

3.1.2.1 Changing cnDBTier Passwords

This section provides the procedures to change cnDBTier passwords such as root user, occneuser, and occnerepluser passwords in a stand-alone and multisite georeplication setup using the dbtpasswd bash script.

Note:

The password changes are applicable only to the current site and are not replicated in the mate sites.
Ensure that your password meets the following password policy requirements:
- Password must be between 20 and 32 characters in length.
- Password must contain at least one lower case letter.
- Password must contain at least one upper case letter.
- Password must include at least one digit.
- Password must include at least one of the following special characters: ,%~+.:_/-
Any character that does not meet the complexity requirements mentioned in the previous note is not supported as it may break the functionality of the dbtpasswd script.

Changing a cnDBTier password involves the following steps:

Adding a new password in MySQL.

Note:
The old password is active until the pods are restarted and the transitional operations are complete.
Replacing the current or old password with the new password in Kubernetes secret.
Restarting the configured cnDBTier pods to use the new Kubernetes secret (This step is not applicable while changing an NF password).
Discarding the old password in MySQL.

The dbtpasswd bash script automates these steps and provides a single script to change all cnDBTier passwords at once. The script also provides options to run selective steps as changing passwords often requires running selective transitional operations, such as restarting pods, while both passwords are still valid.

You can use dbtpasswd to:

change one or more cnDBTier passwords in a single site or cluster. Changing a cnDBTier password on a site includes changing the password in MySQL and Kubernetes secret, restarting all required cnDBTier pods, and updating passwords on cnDBTier database tables if necessary.
change passwords on a live cluster with no service interruption.
change NF passwords. However, when changing an NF password, dbtpasswd can change the password in the Kubernetes secret and database only. You have to manually restart NF pods as a separate user action.

To provide flexibility and support for changing non-cnDBTier passwords (that is, NF passwords), dbtpasswd provides a range of options for controlling the phases of execution. For example, you can configure dbtpasswd to only add the new password to the database, change it in the Kubernetes secret, and then stop. After running the other operations, you can configure the script and run it again to discard the old password only.

MySQL Dual Password

The dbtpasswd script uses the MySQL Dual Password feature to first add the new password and then discard the old MySQL password after database values and secrets are changed and the pods are restarted. Both the passwords are valid until the old password is discarded.

Note:

MySQL Dual Password is not supported for changing the root password.

Support for Non-cnDBTier Secrets on Different Namespace

To support changing NF passwords, that have their secrets on a namespace different from the cnDBTier namespace, dbtpasswd provides the --nf-namespace to configure the namespace in which the secrets are stored. For more information about this option, see unresolvable-reference.html#GUID-3B2ACD82-BB9E-4DC9-B464-57C1436ADB61.

3.1.2.1.1 Prerequisites

Before changing the cnDBTier passwords ensure that the following prerequisites are met:

The dbtpasswd script must be properly installed. For more information, see"Installing and Using dbtpasswd Script" section in the Cloud Native Core, cnDBTier User Guide.
If you are changing the replication password in a multisite setup, then ensure that the DB Replication is up and running between all of the sites in the system.

3.1.2.1.2 Installing and Using dbtpasswd Script

This section provides details about installing and using the dbtpasswd script to change cnDBTier passwords.

Installing the dbtpasswd Script

Run the following commands to source and add the bin directory containing the dbtpasswd program to the user's path.

cd Artifacts/Scripts/tools
source ./source_me

The system prompts you to enter the namespace and uses the same to set the DBTIER_NAMESPACE. It also sets the DBTIER_LIB environment variable with the path to the directory containing the libraries needed by dbtpasswd.

Using the dbtpasswd Script

You can use the dbtpasswd script in the following ways:

dbtpasswd [-h | --help]
dbtpasswd [OPTIONS] [SECRET...]

3.1.2.1.3 Configuration Options

This section describes the list of options that are available to configure the dbtpasswd script.

Table 3-1 Configuration Options

Option	Usage	Example
-h \| --help	This option is used to print the help message and exit.	`dbtpasswd --help`
-v \| --version	This option is used to print script's version.	`dbtpasswd --version`
--debug	This option is used to output DEBUG log message to standard error, stderr.	`dbtpasswd --debug`
--skip-namespace-test	This option is used to skip testing that the namespace in DBTIER_NAMESPACE exists in the current cluster.	`dbtpasswd --skip-namespace-test`
--rollout-watch-timeout=0s	This option is used to define the time to wait before ending the rollout status watch. Set this value to zero if you donot want to wait before ending the rollout status watch. Use a corresponding time unit to set other values. For example: 1s, 2m, 3h.	`dbtpasswd --rollout-watch-timeout=0s`
--no-checks	This option is used to skip verifying if replication to mate sites is UP, when updating a replication password.	`dbtpasswd --no-checks`
--no-discard	This option is used to change a password without discarding the old password.	To change all cnDBTier passwords, but retain the old passwords: `dbtpasswd --no-discard`
--discard-only	This option is used to only discard the old password.	`dbtpasswd --discard-only`
--secrets-only	This option is used to change the password in the secrets only.	`dbtpasswd --secrets-only`
--mysql-only	This option is used to change the passwords in MySQL only. Note: The current secret password must be the current MySQL password. Therefore, if you are using the `--mysql-only` and `--secrets-only` options to change the passwords, you must first change the MySQL password and then the secret password.	`dbtpasswd --mysql-only`
--secrets-and-mysql-only	This option is used to change the passwords in the secrets and MySQL only.	`dbtpasswd --secrets-and-mysql-only`
--restart-only	This option is used to only restart the pods configured to use cnDBTier secrets and doesn't change the passwords.	`dbtpasswd --restart-only`
--nf-namespace=<namespace_where_secrets_are>	Non-cnDBTier secrets may be stored on a namespace different from the cnDBTier namespace. This option is used to provide the details of the namespace where the non-cnDBTier secrets are stored to support changing NF passwords. Note: All non-cnDBTier secrets must be stored in the NF namespace. All cnDBTier secrets must be stored in DBTIER_NAMESPACE.	To change a non-DBTier password in its secret, which is on a different namespace, and in mysql: `dbtpasswd --secrets-and-mysql-only --nf-namespace=other-namespace-name nf-secret-on-diff-namespace` To discard a non-DBTier old password whose secret is on a different namespace: `dbtpasswd --discard-only --nf-namespace=other-namespace-name nf-secret-on-diff-namespace` To change a non-DBTier password in its secret, which is on same namespace as cnDBTier, and in mysql: `dbtpasswd --secrets-and-mysql-only nf-secret-on-same-namespace` To discard a non-DBTier old password whose secret is on the same namespace as cnDBTier: `dbtpasswd --discard-only nf-secret-on-same-namespace`

Note:

Use the

dbtpasswd
          --help

command to refer to more examples.

3.1.2.1.4 Changing All cnDBTier Passwords in a Site

Run the following command to change all the cnDBTier passwords in a cnDBTier site:

$ dbtpasswd

Sample output:

2022-12-23T21:54:24Z INFO - Changing password for user root
Current password:
Enter new password:
Enter new password again:
2022-12-23T21:54:39Z INFO - Changing password for user occneuser
Current password:
Enter new password:
Enter new password again:
2022-12-23T21:54:58Z INFO - Changing password for user occnerepluser
Current password:
Enter new password:
Enter new password again:
2022-12-23T21:55:05Z INFO - Getting sts and sts pod info...
2022-12-23T21:55:12Z INFO - MGM_STS="ndbmgmd"
2022-12-23T21:55:12Z INFO - MGM_REPLICAS="2"
2022-12-23T21:55:12Z INFO -
    ndbmgmd-0
    ndbmgmd-1
2022-12-23T21:55:18Z INFO - NDB_STS="ndbmtd"
2022-12-23T21:55:18Z INFO - NDB_REPLICAS="2"
2022-12-23T21:55:18Z INFO -
    ndbmtd-0
    ndbmtd-1
2022-12-23T21:55:25Z INFO - API_STS="ndbmysqld"
2022-12-23T21:55:25Z INFO - API_REPLICAS="2"
2022-12-23T21:55:25Z INFO -
    ndbmysqld-0
    ndbmysqld-1
2022-12-23T21:55:29Z INFO - APP_STS="ndbappmysqld"
2022-12-23T21:55:29Z INFO - APP_REPLICAS="2"
2022-12-23T21:55:29Z INFO -
    ndbappmysqld-0
    ndbappmysqld-1
2022-12-23T21:55:29Z INFO - Getting deployment pod info...
2022-12-23T21:55:29Z INFO - grepping for backup-man (BAK_CHART_NAME)...
2022-12-23T21:55:36Z INFO -
    mysql-cluster-db-backup-manager-svc-7bb947f5f9-nc45s
2022-12-23T21:55:36Z INFO -
    mysql-cluster-db-backup-manager-svc
2022-12-23T21:55:36Z INFO - grepping for db-mon (MON_CHART_NAME)...
2022-12-23T21:55:42Z INFO -
    mysql-cluster-db-monitor-svc-5cff4bf789-g86rr
2022-12-23T21:55:42Z INFO -
    mysql-cluster-db-monitor-svc
2022-12-23T21:55:42Z INFO - grepping for replicat (REP_CHART_NAME)...
2022-12-23T21:55:47Z INFO -
    mysql-cluster-lfg-site-1-lfg-site-2-replication-svc-b4f8d9g6hbc
2022-12-23T21:55:47Z INFO -
    mysql-cluster-lfg-site-1-lfg-site-2-replication-svc
2022-12-23T21:55:47Z INFO - Labeling pods with dbtier-app...
pod/ndbmgmd-0 not labeled
pod/ndbmgmd-1 not labeled
pod/ndbmtd-0 not labeled
pod/ndbmtd-1 not labeled
pod/ndbappmysqld-0 not labeled
pod/ndbappmysqld-1 not labeled
pod/ndbmysqld-0 not labeled
pod/ndbmysqld-1 not labeled
pod/mysql-cluster-db-backup-manager-svc-7bb947f5f9-nc45s not labeled
pod/mysql-cluster-db-monitor-svc-5cff4bf789-g86rr not labeled
pod/mysql-cluster-lfg-site-1-lfg-site-2-replication-svc-b4f8d9g6hbc not labeled
2022-12-23T21:56:08Z INFO - Pods labeled with dbtier-app
2022-12-23T21:56:08Z INFO - Verifying Geo Replication to mates...
2022-12-23T21:56:18Z INFO - Geo Replication to mates is UP
2022-12-23T21:56:18Z INFO - Changing mysql password for 'root'@'localhost'...
mysql: [Warning] Using a password on the command line interface can be insecure.
2022-12-23T21:56:29Z INFO - Mysql password changed
2022-12-23T21:56:33Z INFO - Patching secret, occne-mysqlndb-root-secret, with new password
secret/occne-mysqlndb-root-secret patched
2022-12-23T21:56:36Z INFO - Secret, occne-mysqlndb-root-secret, patched with new password
2022-12-23T21:56:36Z INFO - Adding new mysql password for 'occneuser'@'%'...
mysql: [Warning] Using a password on the command line interface can be insecure.
2022-12-23T21:56:48Z INFO - New mysql password added
2022-12-23T21:56:54Z INFO - Patching secret, occne-secret-db-monitor-secret, with new password
secret/occne-secret-db-monitor-secret patched
2022-12-23T21:56:58Z INFO - Secret, occne-secret-db-monitor-secret, patched with new password
2022-12-23T21:56:58Z INFO - Adding new mysql password for 'occnerepluser'@'%'...
mysql: [Warning] Using a password on the command line interface can be insecure.
2022-12-23T21:57:10Z INFO - New mysql password added
2022-12-23T21:57:10Z INFO - Changing password in replication_info.DBTIER_REPL_SITE_INFO table...
2022-12-23T21:57:16Z INFO - Using replication pod: mysql-cluster-lfg-site-1-lfg-site-2-replication-svc-b4f8d9g6hbc
2022-12-23T21:57:16Z INFO - Using replication pod container: lfg-site-1-lfg-site-2-replication-svc
2022-12-23T21:57:16Z INFO - MYSQL_REPLICATION_SITE_NAME = lfg-site-1
mysql: [Warning] Using a password on the command line interface can be insecure.
2022-12-23T21:57:28Z INFO - Password changed in replication_info.DBTIER_REPL_SITE_INFO table
2022-12-23T21:57:35Z INFO - Patching secret, occne-replication-secret-db-replication-secret, with new password
secret/occne-replication-secret-db-replication-secret patched
2022-12-23T21:57:38Z INFO - Secret, occne-replication-secret-db-replication-secret, patched with new password
2022-12-23T21:57:38Z INFO - Starting rollover restarts at 2022-12-23T21:57:38Z
2022-12-23T21:57:38Z INFO - number of db-replication-svc deployments: 1
2022-12-23T21:57:38Z INFO - Patching deployment 0: mysql-cluster-lfg-site-1-lfg-site-2-replication-svc...
deployment.apps/mysql-cluster-lfg-site-1-lfg-site-2-replication-svc patched (no change)
2022-12-23T21:57:41Z INFO - Rollout restarting mysql-cluster-lfg-site-1-lfg-site-2-replication-svc...
deployment.apps/mysql-cluster-lfg-site-1-lfg-site-2-replication-svc restarted
...
2022-12-23T22:01:53Z INFO - ndbmtd pods rollout restarted
...
2022-12-23T22:02:11Z INFO - ndbappmysqld pods rollout restarted
...
2022-12-23T22:02:27Z INFO - ndbmysqld pods rollout restarted
...
2022-12-23T22:02:48Z INFO - db-backup-manager-svc pods rollout restarted
...
2022-12-23T22:03:08Z INFO - db-monitor-svc pods rollout restarted
2022-12-23T22:03:08Z INFO - Discarding old mysql password for 'occneuser'@'%'...
mysql: [Warning] Using a password on the command line interface can be insecure.
2022-12-23T22:03:20Z INFO - Old mysql password discarded
2022-12-23T22:03:20Z INFO - Discarding old mysql password for 'occnerepluser'@'%'...
mysql: [Warning] Using a password on the command line interface can be insecure.
2022-12-23T22:03:30Z INFO - Old mysql password discarded
2022-12-23T22:03:30Z INFO - Password(s) updated successfully

3.1.2.1.5 Changing All Passwords in a Stand-Alone or Georeplication Site

This section provides the command to change all cnDBTier passwords in a stand-alone site or a site where Georeplication has been configured but the mate sites are not configured.

$ dbtpasswd

Sample output:

2023-10-12T21:34:05Z INFO - DBTIER_NAMESPACE = occne-cndbtier
2023-10-12T21:34:05Z INFO - Testing namespace, occne-cndbtier, exists...
2023-10-12T21:34:05Z INFO - Should be able to see namespace, occne-cndbtier, with "kubectl get ns -o name occne-cndbtier" - PASSED
2023-10-12T21:34:05Z INFO - Namespace, occne-cndbtier, exists
2023-10-12T21:34:05Z INFO - Changing password for user root 2023-01-03T19:06:31Z INFO - Changing password for user root
Current password:
Enter new password:
Enter new password again:
2023-10-12T21:34:06Z INFO - Changing password for user occneuser
Current password:
Enter new password:
Enter new password again:
2023-10-12T21:34:06Z INFO - Changing password for user occnerepluser
Current password:
Enter new password:
Enter new password again: 2023-10-12T21:34:06Z INFO - Getting sts and sts pod info...
2023-10-12T21:34:06Z INFO - Getting MGM sts and sts pod info...
2023-10-12T21:34:07Z INFO - MGM_STS="ndbmgmd"
2023-10-12T21:34:07Z INFO - MGM_REPLICAS="2"
2023-10-12T21:34:07Z INFO - MGM_PODS:
ndbmgmd-0
ndbmgmd-1
2023-10-12T21:34:07Z INFO - Getting NDB sts and sts pod info...
2023-10-12T21:34:07Z INFO - NDB_STS="ndbmtd"
2023-10-12T21:34:07Z INFO - NDB_REPLICAS="2"
2023-10-12T21:34:07Z INFO - NDB_PODS:
ndbmtd-0
ndbmtd-1
2023-10-12T21:34:07Z INFO - Getting API sts and sts pod info...
2023-10-12T21:34:07Z INFO - API_STS="ndbmysqld"
2023-10-12T21:34:07Z INFO - API_REPLICAS="6"
2023-10-12T21:34:07Z INFO - API_PODS:
ndbmysqld-0
ndbmysqld-1
ndbmysqld-2
ndbmysqld-3
ndbmysqld-4
ndbmysqld-5
2023-10-12T21:34:07Z INFO - Getting APP sts and sts pod info...
2023-10-12T21:34:07Z INFO - APP_STS="ndbappmysqld"
2023-10-12T21:34:07Z INFO - APP_REPLICAS="2"
2023-10-12T21:34:07Z INFO - APP_PODS:
ndbappmysqld-0
ndbappmysqld-1
2023-10-12T21:34:07Z INFO - Getting deployment pod info...
2023-10-12T21:34:07Z INFO - grepping for backup-man (BAK_CHART_NAME)...
2023-10-12T21:34:07Z INFO - BAK_PODS:
mysql-cluster-db-backup-manager-svc-78fdcdfd98-gpml2
2023-10-12T21:34:07Z INFO - BAK_DEPLOY:
mysql-cluster-db-backup-manager-svc
2023-10-12T21:34:07Z INFO - grepping for db-mon (MON_CHART_NAME)...
2023-10-12T21:34:07Z INFO - MON_PODS:
mysql-cluster-db-monitor-svc-ccc9bfbfd-5z45b
2023-10-12T21:34:07Z INFO - MON_DEPLOY:
mysql-cluster-db-monitor-svc
2023-10-12T21:34:07Z INFO - grepping for repl (REP_CHART_NAME)...
2023-10-12T21:34:08Z INFO - REP_PODS:
mysql-cluster-lfg-site-1-lfg-site-2-replication-svc-67d96bg9z5m
mysql-cluster-lfg-site-1-lfg-site-3-replication-svc-8f77b9xrrqt
mysql-cluster-lfg-site-1-lfg-site-4-replication-svc-ddc647dt78q
2023-10-12T21:34:08Z INFO - REP_DEPLOY:
mysql-cluster-lfg-site-1-lfg-site-2-replication-svc
mysql-cluster-lfg-site-1-lfg-site-3-replication-svc
mysql-cluster-lfg-site-1-lfg-site-4-replication-svc
2023-10-12T21:34:08Z INFO - Labeling pods with dbtier-app...
pod/ndbmgmd-0 labeled
pod/ndbmgmd-1 labeled
pod/ndbmtd-0 labeled
pod/ndbmtd-1 labeled
pod/ndbappmysqld-0 labeled
pod/ndbappmysqld-1 labeled
pod/ndbmysqld-0 labeled
pod/ndbmysqld-1 labeled
pod/ndbmysqld-2 labeled
pod/ndbmysqld-3 labeled
pod/ndbmysqld-4 labeled
pod/ndbmysqld-5 labeled
pod/mysql-cluster-db-backup-manager-svc-78fdcdfd98-gpml2 labeled
pod/mysql-cluster-db-monitor-svc-ccc9bfbfd-5z45b labeled
pod/mysql-cluster-lfg-site-1-lfg-site-2-replication-svc-67d96bg9z5m labeled
pod/mysql-cluster-lfg-site-1-lfg-site-3-replication-svc-8f77b9xrrqt labeled
pod/mysql-cluster-lfg-site-1-lfg-site-4-replication-svc-ddc647dt78q labeled
2023-10-12T21:34:41Z INFO - Pods labeled with dbtier-app
2023-10-12T21:34:42Z INFO - DBTIER_REPL_SITE_INFO table is empty (num_of_recs=0); indicating SINGLE SITE SETUP...
2023-10-12T21:34:42Z INFO - Changing mysql password for 'root'@'localhost'...
2023-10-12T21:34:43Z INFO - Mysql password changed
2023-10-12T21:34:43Z INFO - Patching secret, occne-mysqlndb-root-secret, with new password
secret/occne-mysqlndb-root-secret patched
2023-10-12T21:34:43Z INFO - Secret, occne-mysqlndb-root-secret, patched with new password
2023-10-12T21:34:43Z INFO - Adding new mysql password for 'occneuser'@'%'...
2023-10-12T21:34:43Z INFO - New mysql password added
2023-10-12T21:34:43Z INFO - Patching secret, occne-secret-db-monitor-secret, with new password
secret/occne-secret-db-monitor-secret patched
2023-10-12T21:34:44Z INFO - Secret, occne-secret-db-monitor-secret, patched with new password
2023-10-12T21:34:44Z INFO - Adding new mysql password for 'occnerepluser'@'%'...
2023-10-12T21:34:44Z INFO - New mysql password added
2023-10-12T21:34:44Z INFO - Patching secret, occne-replication-secret-db-replication-secret, with new password
secret/occne-replication-secret-db-replication-secret patched
2023-10-12T21:34:44Z INFO - Secret, occne-replication-secret-db-replication-secret, patched with new password
2023-10-12T21:34:44Z INFO - Starting rollover restarts at 2023-10-12T21:34:44Z
2023-10-12T21:34:44Z INFO - number of db-replication-svc deployments: 3
2023-10-12T21:34:44Z INFO - Patching deployment 0: mysql-cluster-lfg-site-1-lfg-site-2-replication-svc...
2023-10-12T21:34:47Z INFO - Patching deployment 1: mysql-cluster-lfg-site-1-lfg-site-3-replication-svc...
2023-10-12T21:34:47Z INFO - Patching deployment 2: mysql-cluster-lfg-site-1-lfg-site-4-replication-svc...
2023-10-12T21:34:48Z INFO - Waiting for deployment mysql-cluster-lfg-site-1-lfg-site-2-replication-svc to rollout restart...
Waiting for deployment "mysql-cluster-lfg-site-1-lfg-site-2-replication-svc" rollout to finish: 0 out of 1 new replicas have been updated...
Waiting for deployment "mysql-cluster-lfg-site-1-lfg-site-2-replication-svc" rollout to finish: 0 out of 1 new replicas have been updated...
Waiting for deployment "mysql-cluster-lfg-site-1-lfg-site-2-replication-svc" rollout to finish: 0 out of 1 new replicas have been updated...
Waiting for deployment "mysql-cluster-lfg-site-1-lfg-site-2-replication-svc" rollout to finish: 0 of 1 updated replicas are available...
deployment "mysql-cluster-lfg-site-1-lfg-site-2-replication-svc" successfully rolled out
2023-10-12T21:36:19Z INFO - Waiting for deployment mysql-cluster-lfg-site-1-lfg-site-3-replication-svc to rollout restart...
deployment "mysql-cluster-lfg-site-1-lfg-site-3-replication-svc" successfully rolled out
2023-10-12T21:36:19Z INFO - Waiting for deployment mysql-cluster-lfg-site-1-lfg-site-4-replication-svc to rollout restart...
deployment "mysql-cluster-lfg-site-1-lfg-site-4-replication-svc" successfully rolled out
2023-10-12T21:36:22Z INFO - number of db-backup-manager-svc deployments: 1
2023-10-12T21:36:22Z INFO - Patching deployment 0: mysql-cluster-db-backup-manager-svc...
2023-10-12T21:36:23Z INFO - number of db-monitor-svc deployments: 1
2023-10-12T21:36:23Z INFO - Patching deployment 0: mysql-cluster-db-monitor-svc...
2023-10-12T21:36:23Z INFO - Waiting for statefulset ndbmtd to rollout restart...
Waiting for 1 pods to be ready...
Waiting for 1 pods to be ready...
waiting for statefulset rolling update to complete 1 pods at revision ndbmtd-d7bf774f6...
Waiting for 1 pods to be ready...
Waiting for 1 pods to be ready...
statefulset rolling update complete 2 pods at revision ndbmtd-d7bf774f6...
2023-10-12T21:37:49Z INFO - Waiting for statefulset ndbappmysqld to rollout restart...
statefulset rolling update complete 2 pods at revision ndbappmysqld-5b8948d47d...
2023-10-12T21:37:49Z INFO - Waiting for statefulset ndbmysqld to rollout restart...
Waiting for 1 pods to be ready...
waiting for statefulset rolling update to complete 4 pods at revision ndbmysqld-94dd7fcbb...
Waiting for 1 pods to be ready...
Waiting for 1 pods to be ready...
waiting for statefulset rolling update to complete 5 pods at revision ndbmysqld-94dd7fcbb...
Waiting for 1 pods to be ready...
Waiting for 1 pods to be ready...
statefulset rolling update complete 6 pods at revision ndbmysqld-94dd7fcbb...
2023-10-12T21:38:32Z INFO - Waiting for deployment mysql-cluster-db-backup-manager-svc to rollout restart...
deployment "mysql-cluster-db-backup-manager-svc" successfully rolled out
2023-10-12T21:38:33Z INFO - Waiting for deployment mysql-cluster-db-monitor-svc to rollout restart...
deployment "mysql-cluster-db-monitor-svc" successfully rolled out
2023-10-12T21:38:33Z INFO - Discarding old mysql password for 'occneuser'@'%'...
2023-10-12T21:38:33Z INFO - Old mysql password discarded
2023-10-12T21:38:33Z INFO - Discarding old mysql password for 'occnerepluser'@'%'...
2023-10-12T21:38:34Z INFO - Old mysql password discarded
2023-10-12T21:38:34Z INFO - Password(s) updated successfully

3.1.2.1.6 Changing All cnDBTier Passwords in Phases

This section provides the procedure to change all cnDBTier Passwords in Phases.

Run the following command to add the new passwords to MySQL (retain the old passwords) and change the passwords in the Kubernetes secret:

$ dbtpasswd --secrets-and-mysql-only

Sample output:

2022-12-24T03:41:08Z INFO - Changing password for user root
Current password:
Enter new password:
Enter new password again:
2022-12-24T03:41:08Z INFO - Changing password for user occneuser
Current password:
Enter new password:
Enter new password again:
2022-12-24T03:41:09Z INFO - Changing password for user occnerepluser
Current password:
Enter new password:
Enter new password again:
2022-12-24T03:41:09Z INFO - Getting sts and sts pod info...
2022-12-24T03:41:09Z INFO - MGM_STS="ndbmgmd"
2022-12-24T03:41:09Z INFO - MGM_REPLICAS="2"
2022-12-24T03:41:09Z INFO -
    ndbmgmd-0
    ndbmgmd-1
2022-12-24T03:41:09Z INFO - NDB_STS="ndbmtd"
2022-12-24T03:41:09Z INFO - NDB_REPLICAS="2"
2022-12-24T03:41:09Z INFO -
    ndbmtd-0
    ndbmtd-1
2022-12-24T03:41:09Z INFO - API_STS="ndbmysqld"
2022-12-24T03:41:09Z INFO - API_REPLICAS="2"
2022-12-24T03:41:09Z INFO -
    ndbmysqld-0
    ndbmysqld-1
2022-12-24T03:41:09Z INFO - APP_STS="ndbappmysqld"
2022-12-24T03:41:09Z INFO - APP_REPLICAS="2"
2022-12-24T03:41:10Z INFO -
    ndbappmysqld-0
    ndbappmysqld-1
2022-12-24T03:41:10Z INFO - Getting deployment pod info...
2022-12-24T03:41:10Z INFO - grepping for backup-man (BAK_CHART_NAME)...
2022-12-24T03:41:10Z INFO -
    mysql-cluster-db-backup-manager-svc-c4648f6bc-jpkt9
2022-12-24T03:41:10Z INFO -
    mysql-cluster-db-backup-manager-svc
2022-12-24T03:41:10Z INFO - grepping for db-mon (MON_CHART_NAME)...
2022-12-24T03:41:10Z INFO -
    mysql-cluster-db-monitor-svc-7d684c7c6f-gvv76
2022-12-24T03:41:10Z INFO -
    mysql-cluster-db-monitor-svc
2022-12-24T03:41:10Z INFO - grepping for replicat (REP_CHART_NAME)...
2022-12-24T03:41:10Z INFO -
    mysql-cluster-lfg-site-1-lfg-site-2-replication-svc-7b689frvfr2
2022-12-24T03:41:10Z INFO -
    mysql-cluster-lfg-site-1-lfg-site-2-replication-svc
2022-12-24T03:41:10Z INFO - Labeling pods with dbtier-app...
pod/ndbmgmd-0 not labeled
pod/ndbmgmd-1 not labeled
pod/ndbmtd-0 not labeled
pod/ndbmtd-1 not labeled
pod/ndbappmysqld-0 not labeled
pod/ndbappmysqld-1 not labeled
pod/ndbmysqld-0 not labeled
pod/ndbmysqld-1 not labeled
pod/mysql-cluster-db-backup-manager-svc-c4648f6bc-jpkt9 not labeled
pod/mysql-cluster-db-monitor-svc-7d684c7c6f-gvv76 not labeled
pod/mysql-cluster-lfg-site-1-lfg-site-2-replication-svc-7b689frvfr2 not labeled
2022-12-24T03:41:11Z INFO - Pods labeled with dbtier-app
2022-12-24T03:41:11Z INFO - Verifying Geo Replication to mates...
2022-12-24T03:41:14Z INFO - Geo Replication to mates is UP
2022-12-24T03:41:14Z INFO - Changing mysql password for 'root'@'localhost'...
mysql: [Warning] Using a password on the command line interface can be insecure.
2022-12-24T03:41:15Z INFO - Mysql password changed
2022-12-24T03:41:15Z INFO - Patching secret, occne-mysqlndb-root-secret, with new password
secret/occne-mysqlndb-root-secret patched
2022-12-24T03:41:15Z INFO - Secret, occne-mysqlndb-root-secret, patched with new password
2022-12-24T03:41:15Z INFO - Adding new mysql password for 'occneuser'@'%'...
mysql: [Warning] Using a password on the command line interface can be insecure.
2022-12-24T03:41:15Z INFO - New mysql password added
2022-12-24T03:41:16Z INFO - Patching secret, occne-secret-db-monitor-secret, with new password
secret/occne-secret-db-monitor-secret patched
2022-12-24T03:41:16Z INFO - Secret, occne-secret-db-monitor-secret, patched with new password
2022-12-24T03:41:16Z INFO - Adding new mysql password for 'occnerepluser'@'%'...
mysql: [Warning] Using a password on the command line interface can be insecure.
2022-12-24T03:41:16Z INFO - New mysql password added
2022-12-24T03:41:16Z INFO - Changing password in replication_info.DBTIER_REPL_SITE_INFO table...
2022-12-24T03:41:16Z INFO - Using replication pod: mysql-cluster-lfg-site-1-lfg-site-2-replication-svc-7b689frvfr2
2022-12-24T03:41:16Z INFO - Using replication pod container: lfg-site-1-lfg-site-2-replication-svc
2022-12-24T03:41:16Z INFO - MYSQL_REPLICATION_SITE_NAME = lfg-site-1
mysql: [Warning] Using a password on the command line interface can be insecure.
2022-12-24T03:41:17Z INFO - Password changed in replication_info.DBTIER_REPL_SITE_INFO table
2022-12-24T03:41:17Z INFO - Patching secret, occne-replication-secret-db-replication-secret, with new password
secret/occne-replication-secret-db-replication-secret patched
2022-12-24T03:41:17Z INFO - Secret, occne-replication-secret-db-replication-secret, patched with new password
2022-12-24T03:41:17Z INFO - Password(s) updated successfully

Run the following command to restart the appropriate cnDBTier pods:

$ dbtpasswd --restart-only

Sample output:

2022-12-24T03:58:36Z INFO - Changing password for user root
Current password:
2022-12-24T03:58:41Z INFO - Changing password for user occneuser
Current password:
2022-12-24T03:58:46Z INFO - Changing password for user occnerepluser
Current password:
2022-12-24T03:58:49Z INFO - Getting sts and sts pod info...
...
2022-12-24T04:01:39Z INFO - db-monitor-svc pods rollout restarted
2022-12-24T04:01:39Z INFO - Password(s) updated successfully

Once the necessary transition is done, run the following command to discard the old MySQL cnDBTier passwords:

$ dbtpasswd --discard-only

Sample output:

2022-12-24T03:51:40Z INFO - Changing password for user root
Current password:
2022-12-24T03:52:04Z INFO - Changing password for user occneuser
Current password:
2022-12-24T03:52:07Z INFO - Changing password for user occnerepluser
Current password:
2022-12-24T03:52:09Z INFO - Getting sts and sts pod info...
...
2022-12-24T03:52:12Z INFO - Discarding old mysql password for 'occneuser'@'%'...
mysql: [Warning] Using a password on the command line interface can be insecure.
2022-12-24T03:52:12Z INFO - Old mysql password discarded
2022-12-24T03:52:12Z INFO - Discarding old mysql password for 'occnerepluser'@'%'...
mysql: [Warning] Using a password on the command line interface can be insecure.
2022-12-24T03:52:13Z INFO - Old mysql password discarded
2022-12-24T03:52:13Z INFO - Password(s) updated successfully

3.1.2.1.7 Changing an NF Password

This section provides a sample procedure to change an NF password when the secret is stored in an NF namespace that is different from the cnDBTier namespace.

Run the following commands to change the password on the secret and add a new password to MySQL.

Note:

When the output prompts for the current password, enter the current password in the NF secret.

$ export DBTIER_NAMESPACE=”dbtier_namespace”
$ dbtpasswd --secrets-and-mysql-only --nf-namespace=name-of-nf-namespace nf-secret-in-nf-namespace

Sample output:

2022-12-15T23:27:19Z INFO - Changing password for user luis
Current password:
Enter new password:
Enter new password again:
...
2022-12-15T23:27:37Z INFO - Adding new mysql password for 'luis'@'%'...
mysql: [Warning] Using a password on the command line interface can be insecure.
2022-12-15T23:27:37Z INFO - New mysql password added
2022-12-15T23:27:37Z INFO - Patching secret, nf-secret-in-nf-namespace, with new password
secret/nf-secret-in-nf-namespace patched
2022-12-15T23:27:37Z INFO - Secret, nf-secret-in-nf-namespace, patched with new password
2022-12-15T23:27:37Z INFO - Password(s) updated successfully

Run the following command to discard the old password in MySQL, after restarting NF pods, adding new NF passwords on mate sites, or both.

Note:

When the output prompts for the current password, enter the current password in the NF secret.
The NF secret must be present on nf-namespace and the corresponding MySQL user must be present with the corresponding password.

$ dbtpasswd --discard-only --nf-namespace=name-of-nf-namespace nf-secret-in-nf-namespace

Sample output:

2022-12-15T23:28:48Z INFO - Changing password for user luis
Current password:
...
2022-12-15T23:28:53Z INFO - Discarding old mysql password for 'luis'@'%'...
mysql: [Warning] Using a password on the command line interface can be insecure.
2022-12-15T23:28:54Z INFO - Old mysql password discarded
2022-12-15T23:28:54Z INFO - Password(s) updated successfully

3.1.3 Cloud Native Core Ingress and Egress Gateways Specific Security Recommendations and Guidelines

This section provides Ingress and Egress Gateways specific security recommendations and guidelines. Security recommendations common to all 5G and 4G are available in the Common Security Recommendations and Guidelines section.

Note:

The following procedures can be performed by any authenticated user who has privileged access to the system. This user can create different roles for specific operations. For creation of role and role binding, see the NF or component-specific Installation and Upgrade Guide.

The procedures are:

Enabling TLS and Ciphers in Ingress and Egress Gateway

Use the following procedure to enable TLS and Ciphers:

Helm Configuration to enable TLS:
To open HTTPS port in Ingress Gateway, set the enableIncomingHttps parameter to true.

To configure the HTTPS client in Ingress Gateway, set the enableOutgoingHttps parameter to true.
Create the following files:
1. RSA or ECDSA Private key (Example: rsa_private_key_pkcs1.pem)
2. Truststore password (Example:trust.txt)
3. Key store password (Example: key.txt)
4. Certificate chain for truststore (Example: caroot.cer)
5. Signed server certificate (Example: ocingress.cer) or Signed client certificate (Example: ocegress.cer)
Note: Creation of private keys, certificates, and passwords is at the discretion of user.

Run the following command to create secret:

$ 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

Enable the cipher suites:

Cipher Suites to be enabled on Server side (Ingress Gateway).
Cipher Suites to be enabled on Client side (Egress Gateway).

cipher Suites:


-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

Certificate Management and Dynamic Reload of Certificates in Gateways

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

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

$ 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 implemented in update container checks for a change in file state and replaces 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 endpoint to reload key and truststore dynamically. 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.

3.2 Cloud Native Core Network Function Specific Security Recommendations and Guidelines

Note:

kubectl commands might vary based on the platform deployment. Replace kubectl with Kubernetes environment-specific command line tool to configure Kubernetes resources through kube-api server. The instructions provided in this document are as per the Oracle Communications Cloud Native Core, Cloud Native Environment (CNE) version of kube-api server.

Caution:

User, computer and applications, and character encoding settings may cause an issue when copy-pasting commands or any content from PDF. PDF reader version also affects the copy-pasting functionality. It is recommended to verify the pasted content especially when the hyphens or any special characters are part of the copied content.

3.2.1 Automated Test Suite (ATS) Specific Security Recommendations and Guidelines

This section provides Automated Test Suite (ATS) specific security recommendations and guidelines. Security recommendations common to all 4G and 5G NFs are available in the Common Security Recommendations and Guidelines Section.

Note:

The procedures are:

Enabling TLS in ingress and egress gateways and selection of CIPHERS

For Enabling TLS in ingress and egress gateways and selection of CIPHERS, see Cloud Native Core Ingress/Egress Gateways Specific Security Recommendations and Guidelines.

Enabling TLS in ATS Pod

Note:

This procedure takes PCF as an example of procedure to be followed for TLS enabled server side. It applies to all TLS enabled server side NFs.
This procedure is run after successful deployment of TLS enabled server side (for example, PCF) and ATS.

Use the following procedure to enable TLS in ATS Pod:

Run the following command to copy the caroot.cer generated while PCF deployment to ATS pod in "cert" directory:

kubectl cp  <path_to_file>/caroot.cer <namespace>/<ATS-Pod-name>: /var/lib/jenkins/cert/ -n <namespace>

Example:

 kubectl cp cert/caroot.cer ocpcf/ocpcf-ocats-pcf-56754b9568-rkj8z:/var/lib/jenkins/cert/

Run the following command to log in to your ATS Pod:
```
kubectl exec -it <ATS-Pod-name> bash -n <namespace>
```
Run the following commands from cert directory to create private key and certificates:
1. ```
openssl req -x509 -nodes -sha256 -days 365 -newkey rsa:2048 -keyout rsa_private_key_client -out rsa_certificate_client.crt 
```
  Note:
  User has to specify fqdn of PCF Ingress Gateway service, that is, <ingress-servicename>.<pcf_namespace>.svc in Common Name
2. ```
 openssl rsa -in rsa_private_key_client -outform PEM -out rsa_private_key_pkcs1_client.pem 
```
3. ```
openssl rsa -in rsa_private_key_client -outform PEM -out rsa_private_key_pkcs1_client.pem
```
  Note:
  ssl.conf which was used while deploying PCF can be used or copied to ATS pod for this step.

Copy the ocegress_client.csr to the bastion and run the following command from the Bastion:

openssl x509 -CA caroot.cer -CAkey cakey.pem -CAserial serial.txt -req -in ocegress_client.csr -out ocegress_client.cer -days 365 -extfile ssl.conf -extensions req_ext

Copy the ocegress_client.cer from the Bastion to the ATS Pod.
Restart the ingress and egress gateway pods from the Bastion.
Run the following command to unset the http and https proxy in the ATS pod:
```
 
unset http_proxy
unset https_proxy
```

Run the following CURL command from the ATS pod cert directory:

Note:

Update the Ingress-gateway-service-name and HTTPS port before running the command.

curl -X POST -v "https://<Ingress-gateway-service-name.namespace.svc>:<HTTPS-port>/npcf-smpolicycontrol/v1/sm-policies"
 --cacert caroot.cer --cert ./ocegress_client.cer --key rsa_private_key_client -H "Content-Type: application/json" -d 
'{ "3gppPsDataOffStatus": true, "accNetChId": { "accNetChaIdValue": "01020304", "sessionChScope": true }, "accessType": 
"3GPP_ACCESS", "dnn": "dnn1", "gpsi": "9192503899", "ipv4Address": "192.168.10.10", "ipv6AddressPrefix": "2001:1:22:3286::/64",
 "notificationUri": "http://smf-simulator:8080/smf/notify", "offline": true, "online": false, "pduSessionId": 1, "pduSessionType": 
"IPV4", "pei": "imei-100120210000001", "ratType": "EUTRA", "servingNetwork": { "mcc": "450", "mnc": "08" }, "sliceInfo": 
{ "sd": "abc123", "sst": 11 }, "smPoliciesUpdateNotificationUrl": "npcf-smpolicycontrol/v1/sm-policies/{ueId}/notify", 
"subSessAmbr": { "downlink": "1000000 Kbps", "uplink": "10000 Kbps" }, "subscribedDefaultQosInformation": "FFS", "supi": 
"imsi-030003000000053", "supportedFeatures": "", "ueTimeZone": "+08:00", "userLocationInformation": { "nrLocation": { "ncgi": 
{ "nrCellId": "512", "plmnId": { "mcc": "450", "mnc": "08" } }, "tai": { "plmnId": { "mcc": "450", "mnc": "08" }, "tac": "1801" } } } }'

The output of the command will be:

Note: Unnecessary use of -X or --request, POST is already inferred.
*   Trying 10.75.233.76:31940...
* TCP_NODELAY set
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0* Connected to 10.75.233.76 (10.75.233.76) port 31940 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: caroot.cer
  CApath: C:/Users/prup
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [94 bytes data]
* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [924 bytes data]
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
{ [300 bytes data]
* TLSv1.2 (IN), TLS handshake, Request CERT (13):
{ [205 bytes data]
* TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
* TLSv1.2 (OUT), TLS handshake, Certificate (11):
} [1866 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [37 bytes data]
* TLSv1.2 (OUT), TLS handshake, CERT verify (15):
} [264 bytes data]
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]
* TLSv1.2 (IN), TLS handshake, Finished (20):
{ [16 bytes data]
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: C=IN; ST=Karnataka; L=Bangalore; O=Oracle; CN=10.75.233.76
*  start date: Mar 22 18:24:24 2020 GMT
*  expire date: Mar 22 18:24:24 2021 GMT
*  subjectAltName: host "10.75.233.76" matched cert's IP address!
*  issuer: C=IN; ST=Karnataka; L=Bangalore; O=Oracle; OU=CGBU; CN=pcfperf-bastion-1; emailAddress=pruthvi.p@oracle.com
*  SSL certificate verify ok.
  0     0    0     0    0     0      0      0 --:--:--  0:00:01 --:--:--     0* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
} [5 bytes data]
* Using Stream ID: 1 (easy handle 0x671fe0)
} [5 bytes data]
> POST /npcf-smpolicycontrol/v1/sm-policies HTTP/2
> Host: 10.75.233.76:31940
> user-agent: curl/7.68.0
> accept: */*
> content-type: application/json
> content-length: 999
>
{ [5 bytes data]
* Connection state changed (MAX_CONCURRENT_STREAMS == 4294967295)!
} [5 bytes data]
* We are completely uploaded and fine
{ [5 bytes data]
< HTTP/2 201
< location: https://vzw-pcf-ingress-gateway.svc:443/npcf-smpolicycontrol/v1/sm-policies/46c38683-d138-4691-a9b9-21557a50703a
< content-type: application/json
< date: Sun, 22 Mar 2020 18:28:02 GMT
< cache-control: no-cache, no-store, max-age=0, must-revalidate
< pragma: no-cache
< expires: 0
< x-content-type-options: nosniff
< x-frame-options: DENY
< x-xss-protection: 1 ; mode=block
< referrer-policy: no-referrer
<
100   999    0     0  100   999      0    434  0:00:02  0:00:02 --:--:--   434{ [5 bytes data]
100  1612    0   613  100   999    229    373  0:00:02  0:00:02 --:--:--   603{"sessRules":{"0_1":{"authDefQos":{"5qi":9,"arp":{"priorityLevel":1,"preemptCap":"MAY_PREEMPT","preemptVuln":"NOT_PREEMPTABLE"}},"sessRuleId":"0_1"}},"pccRules":{"0_0":{"flowInfos":[{"flowDescription":"permit in ip from any to any","flowDirection":"UPLINK"},{"flowDescription":"permit out ip from any to any","flowDirection":"DOWNLINK"}],"pccRuleId":"0_0","precedence":3000,"refQosData":["qosdata_0"]}},"qosDecs":{"qosdata_0":{"5qi":9,"qosId":"qosdata_0","arp":{"priorityLevel":1,"preemptCap":"MAY_PREEMPT","preemptVuln":"NOT_PREEMPTABLE"}}},"policyCtrlReqTriggers":["PLMN_CH","UE_IP_CH","DEF_QOS_CH","AC_TY_CH"]}
* Connection #0 to host 10.75.233.76 left intact

3.2.2 Network Repository Function (NRF) Specific Security Recommendations and Guidelines

This section provides Network Repository Function (NRF) specific security recommendations and guidelines. Security recommendations common to all 4G and 5G NFs are available in the Common Security Recommendations and Guidelines section.

Note:

The procedures are:

NRF Access Token Secret Configuration

Use the following procedure to create access token secret:

Create the following files:
- ECDSA private keys for algorithm ES256 and corresponding valid public certificates for NRF
- RSA private keys for algorithm RS256 and corresponding valid public certificates for NRF
Note: Creation of private keys, certificates, and passwords are at the discretion of user.
Log in to Bastion Host or server from where kubectl can be executed.
Create namespace for the secret by performing the following steps:
1. Verify required namespace already exists in system:
```
$ kubectl get namespaces
```
2. In the output of the above command, check if required namespace is available. If not available, create the namespace using following the command:
  Note: This is an optional step. In case required namespace already exists, proceed with next procedures.
```
$ kubectl create namespace <required namespace>
```
  Example:
```
$ kubectl create namespace ocnrf
```
Create Kubernetes secret for Access token by performing the following steps:
1. To create Kubernetes secret for HTTPS, following files are required:
  - ECDSA private keys for algorithm ES256 and corresponding valid public certificates for NRF
  - RSA private keys for algorithm RS256 and corresponding valid public certificates for NRF
  Note:
  Creation process for private keys, certificates and passwords is based on the discretion of the user or operator. Only unencrypted keys and certificates are supported. PKCS1 and PKCS8 are the only supported versions for RSA, and PKCS8 is the only supported version for ECDSA.
2. Run the following command to create secret. The names used below are same as provided in custom values.yaml in NRF deployment:
```
$ kubectl create secret generic <ocnrfaccesstoken-secret-name>  --from-file=<ecdsa_private_key.pem>
 --from-file=<rsa_private_key.pem>  --from-file=<ssl_truststore.txt> --from-file=<keystore_password.txt> 
  --from-file=rsa_certificate.crt --from-file=<ecdsa_certificate.crt> -n <Namespace of NRF AccessToken secret>
```
  Note: Note down the command used during the creation of Kubernetes secret, this command will be used for updates in future.
```
$ kubectl create secret generic ocnrfaccesstoken-secret  --from-file=ecdsa_private_key.pem 
--from-file=rsa_private_key.pem  --from-file=ssl_truststore.txt --from-file=keystore_password.txt  --from-file=
rsa_certificate.crt --from-file=ecdsa_certificate.crt -n ocnrf
```
3. Run the following command to verify secret created:
```
$ kubectl describe secret <ocnrfaccesstoken-secret-name> -n <Namespace of NRF AccessToken secret>
```
  Example:
```
 $ kubectl describe secret ocnrfaccesstoken-secret -n ocnrf
```

NRF Access Token Secret Update

Use the following procedure to update access token secret:

Update the following files:
- ECDSA private keys for algorithm ES256 and corresponding valid public certificates for NRF
- RSA private keys for algorithm RS256 and corresponding valid public certificates for NRF
Note: Updating private keys, certificates, and passwords are at the user's discretion.
Log in to Bastion Host or server from where kubectl can be executed.

Update the secret with new or updated details by performing the following steps:

Copy the exact command used in above section during creation of secret.
Update the same command with string "--dry-run -o yaml" and "kubectl replace -f - -n <Namespace of Access Token secret>".

Sample format of the create secret command is given below:


$ kubectl create secret generic <ocnrfaccesstoken-secret> --from-file=<ecdsa_private_key.pem>
 --from-file=<rsa_private_key.pem> --from-file=<rsa_certificate.crt> --from-file=<ecdsa_certificate.crt>
 --dry-run -o yaml -n <Namespace of NRF deployment> | kubectl replace -f - -n <Namespace of NRF deployment>

Example: The names used below are same as provided in custom_values.yaml in NRF deployment:

$ kubectl create secret generic ocnrfaccesstoken-secret --from-file=ecdsa_private_key.pem
 --from-file=rsa_private_key.pem --from-file=rsa_certificate.crt --from-file=ecdsa_certificate.crt 
--dry-run -o yaml -n ocnrf | kubectl replace -f - -n ocnrf

Run the updated command.
After successful secret update, the following message is displayed:
```
secret/<ocnrfaccesstoken-secret> replaced
```

NRF MySQL Secret Configuration

This section describes the secret creation for two types of NRF users. Different users have different sets of permissions.

NRF privileged user: This user category has the complete set of permissions. The user can perform DDL and DML operations to install, upgrade, roll back or delete operations.
NRF application user: This user category has fewer permissions and is used by NRF applications during service operations handling. The user can insert, update, get, and remove the records but cannot create, alter, and drop the database and tables.

Kubernetes secret creation for NRF privileged database user

This section explains the steps to create Kubernetes secrets for accessing NRF database for the privileged user.

Log in to Bastion Host or server from where kubectl can be executed.
Create namespace for the secret by performing the following steps:
1. Verify if required namespace already exists in the system:
```
$ kubectl get namespaces
```
2. In the output of the above command, check if required namespace is available. If not available, create the namespace using the following command:
  Note: This is an optional step. In case required namespace already exists, proceed with next procedures.
```
$ kubectl create namespace <required namespace>
```
  For example:
```
$ kubectl create namespace ocnrf
```

Create Kubernetes secret for privileged user as follows:

Create Kubernetes secret for MySQL:

$ kubectl create secret generic <privileged user secret name> --from-literal=dbUsername=<NRF Privileged Mysql database username> --from-literal=dbPassword=<NRF Privileged Mysql User database passsword> --from-literal=appDbName=<NRF Mysql database name> --from-literal=networkScopedDbName=<NRF Mysql Network database name> --from-literal=commonConfigDbName=<NRF Mysql Common Configuration DB> --from-literal=leaderElectionDbName=<Perf-Info DB> -n <Namespace of NRF deployment>

Note:

Note down the command used during the creation of Kubernetes secret, this command is used for updates in future.

Example:

$ kubectl create secret generic privilegeduser-secret --fromliteral=dbUsername=nrfPrivilegedUsr --fromliteral=dbPassword=nrfPrivilegedPasswd --fromliteral=appDbName=nrfApplicationDB --fromliteral=networkScopedDbName=nrfNetworkDB --fromliteral=commonConfigDbName=commonConfigurationDB --fromliteral=leaderElectionDbName=leaderElectionDB -n ocnrf

Verify the secret created using above command:

$ kubectl describe secret <database secret name> -n <Namespace of NRF deployment>

Example:

$ kubectl describe secret privilegeduser-secret -n ocnrf

Kubernetes secret update for NRF privileged database user

This section explains the steps to update Kubernetes secrets for accessing NRF database for the privileged user.

This section describes the steps to update the secrets. Update Kubernetes secret for privileged user as follows:

Copy the exact command used in section during creation of secret:


$ kubectl create secret generic <privileged user secret name> 
--from-literal=dbUsername=<NRF Privileged MySQL database username> 
--from-literal=dbPassword=<NRF Privileged MySQL database password> 
--from-literal=appDbName=<NRF MySQL database name> 
--from-literal=networkScopedDbName=<NRF MySQL Network database name> 
--from-literal=commonConfigDbName=<NRF MySQL Common Configuration DB> -n 
<Namespace of NRF deployment>

Update the same command with string "--dry-run -o yaml" and "kubectl replace -f - -n <Namespace of MySQL secret>". After update, the command will be as follows:

$ kubectl create secret generic <privileged user secret name> 
--from-literal=dbUsername=<NRF Privileged MySQL database username> 
--from-literal=dbPassword=<NRF Privileged MySQL database password> 
--from-literal=appDbName=<NRF MySQL database name> 
--from-literal=networkScopedDbName=<NRF MySQL Network database name> 
--from-literal=commonConfigDbName=<NRF MySQL Common Configuration DB> --dry-run -o yaml 
-n <Namespace of NRF deployment> | kubectl replace -f - -n <Namespace of NRF deployment>

Run the updated command. The following message is displayed:
```
secret/<database secret name> replaced
```

Kubernetes secret creation for NRF application database user

This section explains the steps to create Kubernetes secrets for accessing NRF database for the application database user.

Log in to Bastion Host or server from where kubectl can be executed.
Create namespace for the secret by performing the following steps:
1. Verify if required namespace already exists in the system:
```
$ kubectl get namespaces
```
2. In the output of the above command, check if required namespace is available. If not available, create the namespace using the following command:
  Note: This is an optional step. In case required namespace already exists, proceed with next procedures.
```
$ kubectl create namespace <required namespace>
```
  Example:
```
$ kubectl create namespace ocnrf
```

Create Kubernetes secret for NRF application database user for configuring records is as follows:

Create Kubernetes secret for NRF application database user:

$ kubectl create secret generic <appuser-secret name> --from-literal=dbUsername=<NRF APPLICATION User Name> --from-literal=dbPassword=<Password for NRF APPLICATION User> --from-literal=appDbName=<NRF Application Database> -n <Namespace of NRF deployment>

Note:

Note down the command used during the creation of Kubernetes secret, this command will be used for updates in future.

Example:

$ kubectl create secret generic appuser-secret --from-literal=dbUsername=nrfApplicationUsr --from-literal=dbPassword=nrfApplicationPasswd --from-literal=appDbName=nrfApplicationDB -n ocnrf

Verify the secret creation:

$ kubectl describe secret <appuser-secret name> -n <Namespace of NRF deployment>

Example:

$ kubectl describe secret appuser-secret -n ocnrf

Kubernetes secret update for NRF application database user

This section explains the steps to update Kubernetes secrets for accessing NRF database for the application database user.

This section explains how to update the Kubernetes secret.

Copy the exact command used in above section during creation of secret:

$ kubectl create secret generic <appuser-secret name> --from-literal=dbUsername=<NRF APPLICATION
 User Name> --from-literal=dbPassword=<Password for NRF APPLICATION User> --from-literal=appDbName=<NRF 
Application Database> -n <Namespace of NRF deployment>

Update the same command with string "--dry-run -o yaml" and "kubectl replace -f - -n <Namespace of MySQL secret>". After update, the command will be as follows:

$ kubectl create secret generic <database secret name> --from-literal=dbUsername=<NRF APPLICATION 
User Name> --from-literal=dbPassword=<Password for NRF APPLICATION User> --from-literal=appDbName=<NRF 
Application Database> --dry-run -o yaml -n <Namespace of NRF deployment> | kubectl replace -f - -n <Namespace 
of NRF deployment>

Run the updated command. The following message is displayed:
```
secret/<database secret name> replaced
```

Creating Secrets for DNS NAPTR - Alternate route service

This section provides information about how to create secret for DNS NAPTR in Alternate Route service.

Run the following command to create secret:

$ kubectl create secret generic <DNS NAPTR Secret> --from-literal=tsigKey=<tsig key generated of DNS Server> --from-literal=algorithm=<Algorithm used to generate key> --from-literal=keyName=<key-name used while generating key> -n <Namespace of NRF deployment>

Note:

Note down the command used during the creation of the secret. Use the command for updating the secrets in the future.

Example:

$ kubectl create secret generic tsig-secret  --from-literal=tsigKey=kUVdLp2SYshV/mkE985LEePLt3/K4vhM63suWJXA9T6DAl3hJFQQpKAcK5imcIKjI5IVyYk2AJBkq3qtQvRTGw== --from-literal=algorithm=hmac-sha256 --from-literal=keyName=ocnrf-tsig -n ocnrf

Run the following command to verify the secret created:

$ kubectl describe secret <DNS NAPTR Secret> -n <Namespace of NRF deployment>

Example:

$ kubectl describe secret tsig-secret -n ocnrf

Note:

Creating DNS Server Key is on discretion of the operator.

Network Policies

The network policies allow ingress or egress rules to be defined based on Kubernetes resources such as Pod, Namespace, IP, and Ports. These rules are selected based on Kubernetes labels in the application. These network policies enforces access restrictions for all the applicable data flows except communication from Kubernetes node to pod for invoking container probe.

Note:

Configuring network policy is optional. Based on the security requirements, network policy can be configured.

For more information on the network policy, see https://kubernetes.io/docs/concepts/services-networking/network-policies/.

For more information on configuring the network policy, see Oracle Communications Cloud Native Core, Network Repository Function Installation, Upgrade, and Fault Recovery Guide.

3.2.3 Service Communication Proxy (SCP) Specific Security Recommendations and Guidelines

This section provides Service Communication Proxy Function (SCP) specific security recommendations and guidelines. Security recommendations common to all 4G and 5G NFs are available in the Common Security Recommendations and Guidelines section.

Note:

The procedures are:

SCP Kubernetes Secret Configuration

The following SCP users have different sets of permissions:

SCP privileged user: This user category has a complete set of permissions. The user can perform DDL and DML operations to install, upgrade, roll back or delete operations.
SCP application user: This user category has fewer permissions and is used by SCP applications during service operations handling. The user can insert, update, get, and remove the records. This user cannot create, alter, and drop the database and tables.

Note:

Do not use the same credentials in different Kubernetes secrets, and the passwords stored in the secrets must follow the password policy requirements as recommended in Changing cnDBTier Passwords.

Kubernetes Secret Creation for SCP Privileged Database User

This section explains the steps to create Kubernetes secrets for accessing SCP database for the privileged user.

Log in to Bastion Host or server from where kubectl can be run.
Create namespace for the secret by performing the following steps:
1. Verify if required namespace already exists in the system:
```
$ kubectl get namespaces
```
2. In the output of the above command, check if required namespace is available. If not available, create the namespace using the following command:
  Note:This is an optional step. In case required namespace already exists, proceed with next procedures.
```
$ kubectl create namespace <required namespace>
```
  For example:
```
$ kubectl create namespace ocscp
```

Create Kubernetes secret for privileged user as follows:

Create Kubernetes secret for MySQL:


  $ kubectl create secret generic <privileged user secret name>
 --from-literal=dbUsername=<SCP Privileged Mysql database username> 
--from-literal=dbPassword=<SCP Privileged Mysql User database password> 
--from-literal=appDbName=<SCP Mysql database name> 
--from-literal=networkScopedDbName=<SCP Mysql Network database name> 
--from-literal=commonConfigDbName=<SCP Mysql Common Configuration DB> -n 
<Namespace of SCP deployment>

Note:

Note down the command used during the creation of Kubernetes secret, this command is used for updates in future.

Example:


 $ kubectl create secret generic privilegeduser-secret --from-literal=dbUsername=nrfPrivilegedUsr 
--from-literal=dbPassword=nrfPrivilegedPasswd --from-literal=appDbName=nrfApplicationDB --from-literal
=networkScopedDbName=nrfNetworkDB --from-literal=commonConfigDbName=commonConfigurationDB -n ocscp

Verify the secret created using above command:

$ kubectl describe secret <database secret name> -n <Namespace of SCP deployment>

Example:

$ kubectl describe secret privilegeduser-secret -n ocscp

Kubernetes secret update for SCP privileged database user

This section explains the steps to update Kubernetes secrets for accessing SCP database for the privileged user.

This section describes the steps to update the secrets. Update Kubernetes secret for privileged user as follows:

Copy the exact command used in section during creation of secret:


   $ kubectl create secret generic <privileged user secret name> 
--from-literal=dbUsername=<SCP Privileged Mysql database username> 
--from-literal=dbPassword=<SCP Privileged Mysql database password> 
--from-literal=appDbName=<SCP Mysql database name> 
--from-literal=networkScopedDbName=<SCP Mysql Network database name> 
--from-literal=commonConfigDbName=<SCP Mysql Common Configuration DB> -n 
<Namespace of SCP deployment>

Update the same command with string "--dry-run -o yaml" and "kubectl replace -f - -n <Namespace of MySQL secret>". After update, the command will be as follows:

$ kubectl create secret generic <privileged user secret name> 
--from-literal=dbUsername=<SCP Privileged Mysql database username> 
--from-literal=dbPassword=<SCP Privileged Mysql database password> 
--from-literal=appDbName=<SCP Mysql database name> 
--from-literal=networkScopedDbName=<SCP Mysql Network database name> 
--from-literal=commonConfigDbName=<SCP Mysql Common Configuration DB> --dry-run -o yaml 
-n <Namespace of SCP deployment> | kubectl replace -f - -n <Namespace of SCP deployment>

Run the updated command. The following message is displayed:
```
secret/<database secret name> replaced
```

Kubernetes Secret Creation for SCP Application Database User

This section explains the steps to create Kubernetes secrets for accessing SCP database for the application database user.

Log in to Bastion Host or server from where kubectl can be run.
Create namespace for the secret by performing the following steps:
1. Verify required namespace already exists in system:
```
 $ kubectl get namespaces
```
2. In the output of the above command, check if required namespace is available. If not available, create the namespace using the following command:
  Note: This is an optional step. In case required namespace already exists, proceed with next procedures.
```
 $ kubectl create namespace <required namespace>
```
  Example:
```
 $ kubectl create namespace ocscp
```

Create Kubernetes secret for SCP application database user for configuring records is as follows:

Create Kubernetes secret for SCP application database user:

 $ kubectl create secret generic <appuser-secret name> --from-literal=
dbUsername=<SCP APPLICATION User Name> --from-literal=
dbPassword=<Password for SCP APPLICATION User> --from-literal=
appDbName=<SCP Application Database> -n <Namespace of SCP deployment>

Note:

Note down the command used during the creation of Kubernetes secret, this command will be used for updates in future.

Example:

 $ kubectl create secret generic appuser-secret --from-literal
=dbUsername=nrfApplicationUsr --from-literal=dbPassword
=nrfApplicationPasswd --from-literal=appDbName=nrfApplicationDB -n ocscp

Verify the secret creation:

 $ kubectl describe secret <appuser-secret name> -n <Namespace of SCP deployment>

Example:

 $ kubectl describe secret appuser-secret -n ocscp

Kubernetes Secret Update for SCP Application Database User

This section explains the steps to update Kubernetes secrets for accessing SCP database for the application database user.

This section explains how to update the Kubernetes secret.

Copy the exact command used in above section during creation of secret:

 $ kubectl create secret generic <appuser-secret name> --from-literal
=dbUsername=<SCP APPLICATION
 User Name> --from-literal=dbPassword=<Password for SCP APPLICATION User> --from-literal=appDbName=<SCP 
Application Database> -n <Namespace of SCP deployment>

Update the same command with string "--dry-run -o yaml" and "kubectl replace -f - -n <Namespace of MySQL secret>". After update, the command will be as follows:

 $ kubectl create secret generic <database secret name> --from-literal=dbUsername=<SCP APPLICATION 
User Name> --from-literal=dbPassword=<Password for SCP APPLICATION User> --from-literal=appDbName=<SCP 
Application Database> --dry-run -o yaml -n <Namespace of SCP deployment> | kubectl replace -f - -n <Namespace 
of SCP deployment>

Run the updated command. The following message is displayed:
```
secret/<database secret name> replaced
```

Network Policies

Note:

Configuring network policy is optional. Based on the security requirements, network policy can be configured.

For more information on the network policy, see https://kubernetes.io/docs/concepts/services-networking/network-policies/.

For more information on configuring the network policy, see Oracle Communications Cloud Native Core,Service Communication Proxy Installation, Upgrade, and Fault Recovery Guide.

3.2.4 Network Exposure Function (NEF) Specific Security Recommendations and Guidelines

This section provides specific recommendations and guidelines for Network Exposure Function (NEF) security. Security recommendations common to all 4G and 5G NFs are available in the Common Security Recommendations and Guidelines section.

Note:

The procedures are:

Network Policies

NEF Access Token Secret Configuration

Use the following procedure to create an Access token secret :

Create the following files:
- ECDSA private keys for algorithm ES256 and corresponding valid public certificates for NEF
- RSA private keys for algorithm RS256 and corresponding valid public certificates for NEF
Note: Creation of private keys, certificates and passwords are at the discretion of user.
Log in to Bastion Host or server from where you can run kubectl commands.
Create a namespace for the secret by performing the following steps:
1. Verify if the required namespace already exists in the system:
```
$ kubectl get namespaces
```
2. In the output of the above command, check if required namespace is available. If not available, create the namespace using the following command:
  Note: This is an optional step. In case required namespace already exists, proceed with next procedures.
```
$ kubectl create namespace <required namespace>
```
  Example:
```
$ kubectl create namespace ocnef
```
Create Kubernetes secret for the Access token by performing the following steps:
1. To create Kubernetes secret for HTTPS, following files are required:
  - ECDSA private keys for algorithm ES256 and corresponding valid public certificates for NEF
  - RSA private keys for algorithm RS256 and corresponding valid public certificates for NEF
  Note:
  Creation process for private keys, certificates and passwords is at the user's or operators discretion. Unencrypted key and certificates is only supported. PKCS1 and PKCS8 are the only supported versions for RSA. PKCS8 is the only supported version for ECDSA.
2. Run the following command to create secret. The names used below are same as provided in custom values.yaml in NEF deployment:
```
$ kubectl create secret generic <ocnefaccesstoken-secret-name>  --from-file=<ecdsa_private_key.pem>
 --from-file=<rsa_private_key.pem>  --from-file=<ssl_truststore.txt> --from-file=<keystore_password.txt> 
  --from-file=rsa_certificate.crt --from-file=<ecdsa_certificate.crt> -n <Namespace of ocnef AccessToken secret>
```
  Note: Note down the command used during the creation of Kubernetes secret, this command will be used for updates in future.
```
$ kubectl create secret generic ocnefaccesstoken-secret  --from-file=ecdsa_private_key.pem 
--from-file=rsa_private_key.pem  --from-file=ssl_truststore.txt --from-file=keystore_password.txt  --from-file=
rsa_certificate.crt --from-file=ecdsa_certificate.crt -n ocnef
```
3. Run the following command to verify if the secret is created:
```
$ kubectl describe secret <ocnefaccesstoken-secret-name> -n <Namespace of NEF AccessToken secret>
```
  Example:
```
 $ kubectl describe secret ocnefaccesstoken-secret -n ocnef
```

NEF Access Token Secret Update

Use the following procedure to update the Access token secret:

Update the following files:
- ECDSA private keys for algorithm ES256 and corresponding valid public certificates for NEF
- RSA private keys for algorithm RS256 and corresponding valid public certificates for NEF
Note: Update of private keys, certificates and passwords are at the discretion of user.
Log in to Bastion Host or server from where you can run kubectl commands.

Update the secret with new or updated details by performing the following steps:

Copy the exact command used in above section during creation of secret.
Update the same command with string "--dry-run -o yaml" and "kubectl replace -f - -n <Namespace of Access Token secret>".

Create secret command must look like:


$ kubectl create secret generic <ocnefaccesstoken-secret> --from-file=<ecdsa_private_key.pem>
--from-file=<rsa_private_key.pem> --from-file=<rsa_certificate.crt> --from-file=<ecdsa_certificate.crt>
 --dry-run -o yaml -n <Namespace of ocnef deployment> | kubectl replace -f - -n <Namespace of ocnef deployment>

Example: The names used below are same as provided in custom_values.yaml in NEF deployment:

$ kubectl create secret generic ocnefaccesstoken-secret --from-file=ecdsa_private_key.pem
--from-file=rsa_private_key.pem --from-file=rsa_certificate.crt --from-file=ecdsa_certificate.crt 
--dry-run -o yaml -n ocnef | kubectl replace -f - -n ocnef

Run the updated command.
After successful secret update, the following message is displayed:
```
secret/<ocnefaccesstoken-secret> replaced
```

NEF MySQL Secret Configuration

This section describes the secret creation for two types of NEF users. Different users have different sets of permissions.

NEF privileged user: This user category has a complete set of permissions. The user can perform DDL and DML operations to install, upgrade, roll back or delete operations.
NEF application user: This user category has fewer sets of permissions and is used by NEF applications during service operations handling. This user cannot create, alter, and drop the database and tables.

Kubernetes secret creation for NEF privileged database user

This section explains the steps to create Kubernetes secrets for accessing NEF database for the privileged user.

Log in to Bastion Host or server from where you can run kubectl commands.
Create a namespace for the secret by performing the following steps:
1. Verify if the required namespace already exists in the system:
```
$ kubectl get namespaces
```
2. In the output of the above command, check if the required namespace is available. If not available, create the namespace using the following command:
  Note: This is an optional step. In case the required namespace already exists, proceed with the next set of procedures.
```
$ kubectl create namespace <required namespace>
```
  For example:
```
$ kubectl create namespace ocnef
```

Create a Kubernetes secret for privileged user as follows:

Create a Kubernetes secret for MySQL:


 $ kubectl create secret generic <privileged user secret name>
 --from-literal=dbUsername=<NEF Privileged MySQL database username> 
--from-literal=dbPassword=<NEF Privileged MySQL User database password> 
--from-literal=appDbName=<NEF MySQL database name> 
--from-literal=networkScopedDbName=<NEF MySQL Network database name> 
--from-literal=commonConfigDbName=<NEF MySQL Common Configuration DB> -n 
<Namespace of NEF deployment>

Note:

Note down the command used during the creation of the Kubernetes secret; this command is used for updates in the future.

Example:


$ kubectl create secret generic privilegeduser-secret --from-literal=dbUsername=ocnefPrivilegedUsr 
--from-literal=dbPassword=ocnefPrivilegedPasswd --from-literal=appDbName=ocnefApplicationDB --from-literal
=networkScopedDbName=ocnefNetworkDB --from-literal=commonConfigDbName=commonConfigurationDB -n ocnef

Verify the secret created using above command:

$ kubectl describe secret <database secret name> -n <Namespace of NEF deployment>

Example:

$ kubectl describe secret privilegeduser-secret -n ocnef

Kubernetes secret update for NEF privileged database user

This section explains the steps to update Kubernetes secrets for accessing NEF database for the privileged user.

This section describes the steps to update the secrets. Update Kubernetes secret for privileged user as follows:

Copy the exact command used in section during creation of secret:


$ kubectl create secret generic <privileged user secret name> 
--from-literal=dbUsername=<NEF Privileged MySQL database username> 
--from-literal=dbPassword=<NEF Privileged MySQL database password> 
--from-literal=appDbName=<NEF MySQL database name> 
--from-literal=networkScopedDbName=<NEF MySQL Network database name> 
--from-literal=commonConfigDbName=<NEF MySQL Common Configuration DB> -n 
<Namespace of NEF deployment>

Update the same command with string "--dry-run -o yaml" and "kubectl replace -f - -n <Namespace of MySQL secret>". After update, the command will be as follows:

$ kubectl create secret generic <privileged user secret name> 
--from-literal=dbUsername=<NEF Privileged MySQL database username> 
--from-literal=dbPassword=<NEF Privileged MySQL database password> 
--from-literal=appDbName=<NEF MySQL database name> 
--from-literal=networkScopedDbName=<NEF MySQL Network database name> 
--from-literal=commonConfigDbName=<NEF MySQL Common Configuration DB> --dry-run -o yaml 
-n <Namespace of NEF deployment> | kubectl replace -f - -n <Namespace of NEF deployment>

Run the updated command. The following message is displayed:
```
secret/<database secret name> replaced
```

Kubernetes secret creation for NEF application database user

This section explains the steps to create Kubernetes secrets for accessing NEF database for the application database user.

Log in to Bastion Host or server from where you can run kubectl commands.
Create a namespace for the secret by performing the following steps:
1. Verify if the required namespace already exists in the system:
```
$ kubectl get namespaces
```
2. In the output of the above command, check if required the namespace is available. If not available, create the namespace using the following command:
  Note: This is an optional step. In case the required namespace already exists, proceed with the next set of procedures.
```
$ kubectl create namespace <required namespace>
```
  Example:
```
$ kubectl create namespace ocnef
```

Create a Kubernetes secret for NEF application database user for configuring records as follows:

Create a Kubernetes secret for NEF application database user:

$ kubectl create secret generic <appuser-secret name> --from-literal=dbUsername=<NEF APPLICATION User Name> --from-literal=dbPassword=<Password for NEF APPLICATION User> --from-literal=appDbName=<NEF Application Database> -n <Namespace of NEF deployment>

Note:

Note down the command used during the creation of Kubernetes secret, this command will be used for updates in future.

Example:

$ kubectl create secret generic appuser-secret --from-literal=dbUsername=NEFApplicationUsr --from-literal=dbPassword=NEFApplicationPasswd --from-literal=appDbName=NEFApplicationDB -n ocnef

Verify the secret creation:

$ kubectl describe secret <appuser-secret name> -n <Namespace of NEF deployment>

Example:

$ kubectl describe secret appuser-secret -n ocnef

Kubernetes secret update for NEF application database user

This section explains the steps to update Kubernetes secrets for accessing NEF database for the application database user.

This section explains how you can update the Kubernetes secret.

Copy the exact command used in above section during creation of secret:

$ kubectl create secret generic <appuser-secret name> --from-literal=dbUsername=<NEF APPLICATION
 User Name> --from-literal=dbPassword=<Password for NEF APPLICATION User> --from-literal=appDbName=<NEF 
Application Database> -n <Namespace of NEF deployment>

Update the same command with string "--dry-run -o yaml" and "kubectl replace -f - -n <Namespace of MySQL secret>". After update, the command will be as follows:

$ kubectl create secret generic <database secret name> --from-literal=dbUsername=<NEF APPLICATION 
User Name> --from-literal=dbPassword=<Password for NEF APPLICATION User> --from-literal=appDbName=<NEF 
Application Database> --dry-run -o yaml -n <Namespace of NEF deployment> | kubectl replace -f - -n <Namespace 
of NEF deployment>

Run the updated command. The following message is displayed:
```
secret/<database secret name> replaced
```

Network Policies

Note:

Configuring network policy is optional. Based on the security requirements, network policy can be configured.

For more information on the network policy, see https://kubernetes.io/docs/concepts/services-networking/network-policies/.

For more information on configuring the network policy, see Oracle Communications Cloud Native Core, Network Exposure Function Installation, Upgrade, and Fault Recovery Guide.

3.2.5 Network Slice Selection Function (NSSF) Specific Security Recommendations and Guidelines

This section provides Network Slice Selection Function (NSSF) specific security recommendations and guidelines. Recommendations common to all 4G and 5G NFs are available in the Common Security Recommendations and Guidelines section.

Note:

The procedures are:

NSSF Access Token Secret Configuration

Use the following procedure to create access token secret:

Create the following files:
- ECDSA private key (Example: ecdsa_private_key_pkcs8.pem)
- RSA private key (Example: rsa_private_key_pkcs1.pem)
- TrustStore password file (Example: trustStorePassword.txt)
- KeyStore password file (Example:keyStorePassword.txt)
- CA signed ECDSA NSSF certificate (Example: ecdsa_ocnssf_certificate.crt)
- CA signed RSA NSSF certificate (Example: rsa_ocnssf_certificate.crt)
Note: Creation of private keys, certificates and passwords are at the discretion of user.
Log in to Bastion Host or server from where kubectl can be run.
Create namespace for the secret by executing the following command:
$ kubectl create namespace ocnssf

Create Kubernetes secret for NF Access token by executing the following command:

$ kubectl create secret generic
         ocnssfaccesstoken-secret --from-file=ecdsa_private_key_pkcs8.pem
         --from-file=rsa_private_key_pkcs1.pem --from-file=trustStorePassword.txt
         --from-file=keyStorePassword.txt --from-file=ecdsa_ocnssf_certificate.crt--from-file=rsa_ocnssf_certificate.crt -n
      ocnssf

Verify that secret is created successfully by executing the following command:
$ kubectl describe secret ocnssfaccesstoken-secret -n ocnssf

NSSF Access Token Secret Update

Use the following procedure to update access token secret:

Update the following files:
- ECDSA private key (Example: ecdsa_private_key_pkcs8.pem)
- RSA private key (Example: rsa_private_key_pkcs1.pem)
- TrustStore password file (Example: trustStorePassword.txt)
- KeyStore password file (Example:keyStorePassword.txt)
- CA signed ECDSA NSSF certificate (Example: ecdsa_ocnssf_certificate.crt)
- CA signed RSA NSSF certificate (Example: rsa_ocnssf_certificate.crt)
Note:Update private keys, certificates, and passwords are at the user's discretion.
Log in to Bastion Host or server from where kubectl can be run.

Update the secret with new or updated details by executing the following commands:

Delete the secret:

$ kubectl delete secret ocnssfaccesstoken-secret -n ocnssf

Create the secret again with updated details:

$ kubectl create secret generic ocnssfaccesstoken-secret --from-file=ecdsa_private_key_pkcs8.pem
 --from-file=rsa_private_key_pkcs1.pem --from-file=trustStorePassword.txt --from-file=keyStorePassword.txt 
--from-file=ecdsa_ocnssf_certificate.crt--from-file=rsa_ocnssf_certificate.crt -n ocnssf

NSSF MySQL Secret Configuration

Kubernetes Secret Creation for NSSF Privileged Database User

This section explains the steps to create Kubernetes secrets for accessing NSSF database for the privileged user.

Log in to Bastion Host or server from where kubectl can be run.
Create namespace for the secret by following:
1. Verify required namespace already exists in system:
```
$ kubectl get namespaces
```
2. In the output of the above command, check if required namespace is available. If not available, create the namespace using following command:
  Note:This is an optional step. In case required namespace already exists, proceed with next procedures.
```
$ kubectl create namespace <required namespace>
```
  For example:
```
$ kubectl create namespace ocnssf
```
Create a yaml file with the username and password with the syntax as follows:
```
apiVersion: v1
kind: Secret
metadata:
name: <secret-name>
type: Opaque
data:
mysql-username: cm9vdA==
mysql-password: cm9vdHBhc3N3ZA==
```
Note:
The values for "mysql-username" and "mysql-password" must be Base64 encoded.
Run kubectl create -f <yaml_file_name> -n <namespace> to create the secret.
Verify whether the secret is created by running the following command:
$ kubectl describe secret <secret-name> -n <namespace>

Kubernetes Secret Update For NSSF Privileged Database User

This section explains the steps to update Kubernetes secrets for accessing NSSF database for the privileged user.

Delete the Kubernetes secret for MySQL:

# Delete the secret
$ kubectl delete secret <secret name> -n <namespace>

Update yaml file from step 3 in secret creation with new values for MySQL-username and MySQL-password
Run kubectl create -f <yaml_file_name> -n <namespace> to create the secret.
Verify whether the secret is created by running the following command:
$ kubectl describe secret <secret-name> -n <namespace>

Kubernetes Secret Creation for NSSF Application Database User

This section explains the steps to create Kubernetes secrets for accessing NSSF database for the application database user.

Log in to Bastion Host or server from where kubectl can be run.
Create namespace for the secret by following:
1. Verify required namespace already exists in system:
```
$ kubectl get namespaces
```
2. In the output of the above command, check if required namespace is available. If not available, create the namespace using following command:
  
  Note:
  This is an optional step. In case required namespace already exists, proceed with next procedures.
```
$ kubectl create namespace <required namespace>
```
  For example:
```
$ kubectl create namespace ocnssf
```
Create a yaml file with the username and password with the syntax as follows:
```
apiVersion: v1
kind: Secret
metadata:
name: <secret-name>
type: Opaque
data:
mysql-username: bnNzZnVzZXI=
mysql-password: bnNzZnBhc3N3ZA==
```
Note:
The values for "mysql-username" and "mysql-password" must be Base64 encoded.
Run kubectl create -f <yaml_file_name> -n <namespace> to create the secret.
Verify whether the secret is created by running the following command:
$ kubectl describe secret <secret-name> -n <namespace>

Kubernetes Secret Update for NSSF Application Database User

This section explains the steps to update Kubernetes secrets for accessing NSSF database for the application database user.

Delete the Kubernetes secret for MySQL:

# Delete the secret
$ kubectl delete secret <secret name> -n <namespace>

Update yaml file from step 3 in secret creation with new values for MySQL-username and MySQL-password
Run kubectl create -f <yaml_file_name> -n <namespace> to create the secret.
Verify whether the secret is created by running the following command:
$ kubectl describe secret <secret-name> -n <namespace>

Network Policies

Note:

Configuring network policy is optional. Based on the security requirements, network policy can be configured.

For more information on the network policy, see https://kubernetes.io/docs/concepts/services-networking/network-policies/.

For more information on configuring the network policy, see Oracle Communications Cloud Native Core, Network Slice Selection Function Installation, Upgrade, and Fault Recovery Guide.

3.2.6 Security Edge Protection Proxy (SEPP) Security Recommendations and Procedures

This section provides Security Edge Protection Proxy (SEPP) specific security recommendations and procedures. Security recommendations common to all 4G and 5G NFs are available in the Common Security Recommendations and Guidelines section.

Note:

The procedures are:

SEPP Secret Configuration for HTTPS and HTTP over TLS

Use the following procedures to configure secret for HTTPS and HTTP over TLS and to update Access Token Secret:

Creating Secret for HTTPS and HTTP over TLS

Use the following procedure to create secret for HTTPS and HTTP over TLS:

Log in to Bastion Host or server from where you can run kubectl commands.
Create the following files:
- RSA or ECDSA Private key ( For example: rsa_private_key_pkcs1.pem)
- Truststore password (For example: trust.txt)
- Key store password (For example: key.txt)
- Certificate chain for truststore (For example: caroot.cer)
- Signed server certificate (For example: ocsepp.cer) or Signed client certificate (For example: ocsepp.cer)
Note: Creation of private keys, certificates, and passwords is at the discretion of the user.
To verify and create the Kubernetes namespace, do the following:
1. Run the following command to verify if the required namespace exists in the system:
  $ kubectl get namespaces
2. Run the following command to create a Kubernetes namespace if the output of the above command does not display the required namespace:
  $ kubectl create namespace <required namespace>
  
  Note:
  This is an optional step. In case the required namespace already exists, skip this procedure.
  Example:
  $ kubectl create namespace seppsvc

Run the following commands to create Kubernetes secrets:

For Creating secrets

$ kubectl create secret generic <secret-name>
                  --from-file=<ssl_ecdsa_private_key.pem> --from-file=<rsa_private_key_pkcs1.pem>
                  --from-file=<ssl_truststore.txt> --from-file=<ssl_keystore.txt> --from-file=<signed.cer>
                  --from-file=<caroot.cer> --from-file=<ssl_rsa_certificate.crt> --from-file
                  <ssl_ecdsa_certificate.crt> -n <Namespace of SEPP deployment>

For HTTP over TLS => For n32 interface

$ kubectl create secret generic ocsepp-n32-secret
                  --from-file=rsa_private_key_pkcs1.pem --from-file=trust.txt --from-file=key.txt
                  --from-file=caroot.cer --from-file=rsa_certificate.crt --from-file=ocsepp.cer -n
                  seppsvc

For HTTPS => For Plmn interface

$ kubectl create secret generic
                    ocsepp-plmn-secret --from-file=rsa_private_key_pkcs1.pem --from-file=trust.txt
                    --from-file=key.txt --from-file=caroot.cer --from-file=rsa_certificate.crt
                    --from-file=ocsepp.cer -n seppsvc

Updating Access Token Secret

Use the following procedure to update access token secret:

Update the secret with new or updated details.

Run the following commands to create the secrets again with updated details:

for HTTP over TLS For n32 interface

$ kubectl create secret generic ocsepp-n32-secret --from-file=rsa_private_key_pkcs1.pem
      --from-file=trust.txt --from-file=key.txt --from-file=caroot.cer
      --from-file=rsa_certificate.crt --from-file=ocsepp.cer --dry-run -o yaml  -n seppsvc | kubectl replace -f - -n seppsvc

for HTTPS For PLMN interface

$ kubectl create secret generic ocsepp-plmn-secret --from-file=rsa_private_key_pkcs1.pem
      --from-file=trust.txt --from-file=key.txt --from-file=caroot.cer
      --from-file=rsa_certificate.crt --from-file=ocsepp.cer --dry-run -o yaml  -n seppsvc |
      kubectl replace -f - -n seppsvc

Note: Update of private keys, certificates and passwords are at the discretion of the user.

SEPP MySQL Secret Configuration

Creating Secret for MySQL

Use the following procedure to create MySQL Secret:

Log in to Bastion Host or server from where you can run kubectl commands.
Create namespace for the secret. Skip this step, if already created.
```
$ kubectl create namespace seppsvc
```
Note: Creation of private keys, certificates and passwords are at the discretion of the user.
Create a yaml file with the username, password, and DB name with the syntax shown below:
```
apiVersion: v1
kind: Secret
metadata:
name: ocsepp-mysql-cred
type: Opaque
data:
mysql-username: c2VwcF91c3I=
mysql-password: RHVrdzFAbT8=
dbName: c2VwcGRi
```
Note:
Note: The values for "mysql-username", "mysql-password" and dbName should be Base64 encoded.

Run the following commands to create Kubernetes secrets:

$ kubectl apply -f <yaml_file_name> -n <namespace>


kubectl create secret generic ocsepp-mysql-cred --from-literal=mysql-username='<USR_NAME>' 
--from-literal=mysql-password='<PWD>' --from-literal=dbName='<Db Name>' -n seppsvc

Verify the secret creation:

$ kubectl describe secret <secret-name> -n <namespace>

Updating Secret for MySQL

Use the following procedure to update MySQL Secret :

Update the Kubernetes secret for MySQL:


# Delete the secret:

$ kubectl delete secret database-secret -n <namespace>


# Create the secret with updated details:

$ kubectl create secret generic <secretName> -from-literal=mysql-username='<USR_NAME>' 
--from-literal=mysql-password='<PWD>' --from-literal=dbName='<Db Name>' -n <namespace>

Network Policies

Note:

Configuring network policy is optional. Based on the security requirements, network policy can be configured.

For more information on the network policy, see https://kubernetes.io/docs/concepts/services-networking/network-policies/.

For more information on configuring the network policy, see Oracle Communications Cloud Native Core, Security Edge Protection Proxy Installation, Upgrade, and Fault Recovery Guide.

3.2.7 Unified Data Repository (UDR) and Unstructured Data Storage Function (UDSF) Specific Security Recommendations and Guidelines

This section provides Unified Data Repository (UDR), Unstructured Data Storage Function (UDSF), and Equipment Identity Register (EIR) specific security recommendations and guidelines. Security recommendations common to all 4G and 5G NFs are available in the Common Security Recommendations and Guidelines Section.

Note:

The procedures are:

Oauth Token Validation Configuration

Use the following procedure for Oauth Token validation configuration:

NRF creates access tokens using following private keys:
- ECDSA private key
  Example:
```
ecdsa_private_key_pkcs8.pem
```
- RSA private key
  Example:
```
rsa_private_key_pkcs1.pem
```
  In order to validate access token secret needs to be created and configured in ocudr ingress gateway with certificates fetched from nrf.
  Example:
```
 6faf1bbc-6e4a-4454-a507-a14ef8e1bc5c_ES256.crt
```
Log in to Bastion Host or server from where kubectl can be executed.
Create namespace for the secret.
```
$ kubectl create namespace ocudr
```
Create Kubernetes secret for NF Access token validation

Note:
The file names in below command are same as in Step 1.
```
$ kubectl create secret generic oauthsecret --from-file=6faf1bbc-6e4a-4454-a507-a14ef8e1bc5c_ES256.crt-n ocudr
```
Run the following command to verify if the secret is created successfully:
```
$ kubectl describe secret oauthsecret -n ocudr
```

Rest Configuration

We need REST based configurations to distinguish certificates configured from different NRF and use them properly to validate token received from specific NRF. These configurations can be added from CNCC GUI which internally uses config API and payload as below:

“/udr/nf-common-component/v1/igw/oauthvalidatorconfiguration”

Payload:

{
              "keyIdList": [{

                             "keyId": "664b344e74294c8fa5d2e7dfaaaba407",
                             "kSecretName": "samplesecret1",
                             "certName": "samplecert1.crt",
                             "certAlgorithm": "ES256"
                           }],
              "instanceIdList": [{

                             "instanceId": "664b344e74294c8fa5d2e7dfaaaba407",
                             "kSecretName": "samplesecret2",
                             "certName": "samplecert2.crt",
                             "certAlgorithm": "ES256"

                              }],
              "oAuthValidationMode": "INSTANCEID_ONLY"

}

The multiple keyId and instanceId object of different NRFs can be configured.

Using oAuthValidationMode mode of validation can be selected.

Example: INSTANCEID_ONLY, KID_ONLY or KID_PREFERRED

KID_PREFERRED is a fall back mode where it checks for keyId in token, if token contains keyId then validation mode is KID_ONLY or else it falls back to INSTANCEID_ONLY.

Public key Update for Changed Access Token

Use the following procedure for public key update for changed access token:

Update the secret with new or updated details:

# Delete the secret and recreate it
$ kubectl delete secret oauthsecret -n ocudr

# Fetch updated certificates from nrf 

# Recreate the secret with updated details
$ kubectl create secret generic oauthsecret --from-file=0263663c-f5c2-4d1b-9170-f7b1a9116337_ES256.crt

-n ocudr

Certificate configuration update request needs to be sent using CNCC GUI with the updated keyIdList and instanceIdList with new certificates.

Disabling the Signature Validation for Oauth

If serviceMeshCheck flag is enabled under ingress gateway in custom-values file, signature validation is disabled by default.

In this case, only header and payload are validated, and request is successful even if token has wrong signature.

UDR MySQL Kubernetes Secret for storing Database Username and Password

Use the following procedure to create MySQL Kubernetes secret for storing database username and password:

Log in to Bastion Host or server from where kubectl can be executed.
Create namespace for the MySQL secret. Skip this step, if already created.
```
 $ kubectl create namespace <namespace>
```

Run the following command for creating the secret:

kubectl create secret generic ocudr-secrets --from-literal=
dbname=<dbname> --from-literal=configdbname=<configdbname> --from-literal=
privilegedUsername=<privilegedUsername> --from-literal=
privilegedPassword=<privilegedPassword> --from-literal=dsusername=<udruserName> --from-literal=
dspassword=<udruserPassword> --from-literal=encryptionKey='My secret passphrase' -n <ocudr-namespace>

Example:

kubectl create secret generic ocudr-secrets --from-literal=dbname=udrdb --from-literal=
configdbname=udrconfigdb --from-literal=privilegedUsername=root --from-literal=
privilegedPassword=rootPasswd --from-literal=dsusername=udruser --from-literal=dspassword=udrpasswd --from-literal=
encryptionKey='My secret passphrase' -n <ocudr-namespace>

Verify the whether the secret is created by executing the following command:
```
$ kubectl describe secret <secret-name> -n <namespace>  
```

TLS certificate for HTTPs support

UDR and EIR has two Ingress Gateway services to handle the signaling and provisioning traffic. Hence, you must configure two separate TLS certificates to support HTTPS on both the gateways.

For information on the procedure to enable TLS certificates, see Cloud Native Core - Ingress/Egress Gateways - Security Recommendations / Guidelines for TLS configuration.

Updating Keys and Certificates in the Existing Secrets

Prerequsite: The certificates and files that need to be updated must be present in the secret.

Perform the following steps to update the existing certificates in secrets:

Run the following command to add a certificate:
```
TLS_CRT=$(base64 < "<certificate-name>" | tr -d '\n')
kubectl patch secret <secret-name> -p "{\"data\":{\"<certificatename>\":\"${TLS_CRT}\"}}"
```
Here,

<certificate-name> is the certificate file name.

<secret-name> is the name of the secret, for example, ocudr-gateway-secret.

Example:

Run the following command to add a Certificate Authority (CA) Root from the caroot.cer file to the ocudr-gateway-secret.
```
TLS_CRT=$(base64 < "caroot.cer" | tr -d '\n')
kubectl patch secret ocudr-gateway-secret -p "{\"data\":{\"caroot.cer\":\"${TLS_CRT}\"}}" -n udr
```
Similarly, you can also add other certificates and keys to the ocudr-gateway-secret.
Run the following command to update an existing certificate:
```
TLS_CRT=$(base64 < "<updated-certificate-name>" | tr -d '\n')
kubectl patch secret <secret-name> -p "{\"data\":{\"<certificatename>\":\"${TLS_CRT}\"}}"
```
Here,

<updated-certificate-name> is the certificate file that contains the updated content.

Example:
Run the following command to update the private key present in the rsa_private_key_pkcs1.pem file to the ocudr-gateway-secret:
```
TLS_CRT=$(base64 < "rsa_private_key_pkcs1.pem" | tr -d '\n')
kubectl patch secret ocudr-gateway-secret -p "{\"data\":{\"rsa_private_key_pkcs1.pem\":\"${TLS_CRT}\"}}" -n udr
```
Similarly, you can also update other certificates and keys to the ocudr-gateway-secret.
Run the following command to remove an existing certificate:
```
kubectl patch secret <secret-name> -p "{\"data\":{\"<certificatename>\":null}}"
```

Here,

<certificate-name> is the name of the certificate to be removed.

The certificate must be removed when it expires or needs to be revoked.

Example:

Run the following command to remove the CA Root from the ocudr-gateway-secret:

kubectl patch secret ocudr-gateway-secret -p "{\"data\":{\"caroot.cer\":null}}" -n udr

Similarly, you can also remove other certificates and keys from the ocudr-gateway-secret.

Note:

The following are the certificate update and renewal impacts:

Updating, adding, deleting the certificate, ot terminates all the existing connections gracefully and re-establishes new connections for new requests.
When the certificates expires, no new connections are established for new requests, however, the existing connections remain active. After the renewal of the certificates all the existing connections are gracefully terminated. And, new connections are established with the renewed certificates.

Remote File Transfer Support

UDR supports the transfer of files to the remote sever using Secure File Transfer Protocol (SFTP) in the subscriber bulk import tool and the subscriber export tool as below:

In subscriber bulk import tool the files will be transferred from the remote server to Persistent Volume Claim (PVC) and vice versa using SFTP
In subscriber export tool the files will be transferred from PVC to the remote server using SFTP

To support the file transfer, you must run the below command to configure the private and public keys in to the kuberenetes secrets. The operator will get the private and public keys from the remote server.

Keys

kubectl create secret generic ocudr-ssh-private-key --from-file=id_rsa=/home/cloud-user/ocudr/secrets/id_rsa -n <namespace>
kubectl create secret generic ocudr-ssh-public-key --from-file=id_rsa.pub=/home/cloud-user/ocudr/secrets/id_rsa.pub -n <namespace>

Network Policies

Note:

Configuring network policy is optional. Based on the security requirements, network policy can be configured.

For more information on the network policy, see https://kubernetes.io/docs/concepts/services-networking/network-policies/.

For more information on configuring the network policy, see Oracle Communications Cloud Native Core, Unified Data Repository Installation, Upgrade, and Fault Recovery Guide and Oracle Communications Cloud Native Core, Unified Data Repository User Guide.

3.2.8 Binding Support Function (BSF) Specific Security Recommendations and Guidelines

This section provides Binding Support Function (BSF) specific security recommendations and guidelines. Security recommendations common to all 4G and 5G NFs are available in the Common Security Recommendations and Guidelines Section.

Note:

The procedure is:

Creating BSF MySQL Kubernetes Secret for Storing Database Username and Password

Use the following procedure to create BSF MySQL Kubernetes secret for storing database username and password:

Log in to Bastion Host or server from where kubectl can be Run.
Create namespace, if already does not exists, by entering the command:
```
kubectl create namespace <namespace>
```
where:
<namespace> is the deployment BSF namespace.
Create a Kubernetes secret for an admin user and an application user. To create a Kubernetes secret for storing database username and password for these users follow the procedure below:

Create a YAML file with the application user's username and password with the syntax shown below:
Note:
The values mentioned in the syntax are sample values.
```
apiVersion: v1
             kind: Secret
             metadata:
             name: <secret-name>
             type: Opaque
             data:
             mysql-username: YnNmdXNy
             mysql-password: YnNmcGFzc3dk
```
Create a YAML file with the admin user's username and password with the syntax shown below:
Note:
The values mentioned in the syntax are sample values.
```
apiVersion: v1
           kind: Secret
           metadata:
           name: <secret-name>
           type: Opaque
           data:
            mysql-username: YnNmcHJpdmlsZWdlZHVzcg==
            mysql-password: YnNmcHJpdmlsZWdlZHBhc3N3ZA==
```
Note:
The values for mysql-username and mysql-password should be Base64 encoded
Run the following command to create the secret:
```
kubectl create -f <yaml_file_name> -n <namespace>
```
Verify whether the secret is created by executing the following command:
```
$ kubectl describe secret <secret-name> -n <namespace>
```

For more information, see cnDBTier Authentication and Authorization.

Network Policies

Note:

Configuring network policy is optional. Based on the security requirements, network policy can be configured.

For more information on the network policy, see https://kubernetes.io/docs/concepts/services-networking/network-policies/.

For more information on configuring the network policy, see Oracle Communications Cloud Native Core, Binding Support Function Installation, Upgrade, and Fault Recovery Guide.

3.2.9 Cloud Native Core Policy Specific Security Recommendations and Guidelines

This section provides Cloud Native Core Policy specific security recommendations and guidelines. Security recommendations common to all 4G and 5G NFs are available in the Common Security Recommendations and Guidelines Section.

Note:

The procedures are:

Access Token configuration

Use the following procedure to create access token :

Create following files:
- ECDSA private key (Example:ecdsa_private_key_pkcs8.pem)
- RSA private key (Example: rsa_private_key_pkcs1.pem)
- TrustStore password file (Example: trustStorePassword.txt)
- KeyStore password file (Example: keyStorePassword.txt)
- CA signed ECDSA OCPolicy certificate (Example: ecdsa_occnp_certificate.crt)
- CA signed RSA OCPolicy certificate (Example: rsa_occnp_certificate.crt)
Log in to Bastion Host or server from where kubectl can be run.
Create namespace for the secret:
```
$ kubectl create namespace occnp
```

Create Kubernetes secret for NF Access token :

Note: The filenames in below command are same as in Step 1

$ kubectl create secret generic ocpcfaccesstoken-secret --from-file=
ecdsa_private_key_pkcs8.pem --from-file=rsa_private_key_pkcs1.pem --from-file=
trustStorePassword.txt --from-file=keyStorePassword.txt --from-file=
ecdsa_ocpcf_certificate.crt--from-file=rsa_ocpcf_certificate.crt -n ocpcf

Verify that secret is created successfully:
```
$ kubectl describe secret ocpcfaccesstoken-secret -n ocpcf
```

Update Keys to Sign JSON Web Token (JWTs) for Access Token

Use the following procedure to update keys to sign JSON web token (JWTs) for access token:

Update the following files:
- ECDSA private key (Example: ecdsa_private_key_pkcs8.pem)
- RSA private key (Example: rsa_private_key_pkcs1.pem)
- CA signed ECDSA OCPolicy certificate (Example: ecdsa_occnp_certificate.crt)
- CA signed RSA OCPolicy certificate (Example: rsa_occnp_certificate.crt)
Note:
Update of private keys, certificates and passwords are at the discretion of user
Log in to Bastion host or server from where kubectl can be run.

Update the secret with new or updated details by performing the following steps:

Delete the secret by executing the following command:
```
$ kubectl delete secret ocpcfaccesstoken-secret -n ocpcf
```

Create the secret with updated details:

$ kubectl create secret generic ocpcfaccesstoken-secret
            --from-file=ecdsa_private_key_pkcs8.pem --from-file=rsa_private_key_pkcs1.pem
            --from-file=trustStorePassword.txt --from-file=keyStorePassword.txt
            --from-file=ecdsa_occnp_certificate.crt--from-file=rsa_ocpcf_certificate.crt -n
            occnp

Create CNC Policy MySQL Kubernetes Secret for Storing Database Username and Password for Admin and Application Users

Use the following procedure to create OCPolicy MySQL Kubernetes secret for storing database username and password:

Log in to Bastion Host or server from where kubectl can be run.
Create namespace for the MySQL secret. Skip this step, if already created.
```
$ kubectl create namespace <namespace>
```
To create a Kubernetes secret for storing database username and password for an admin user and an application user:
1. Create a YAML file with the application user's username and password with the syntax shown below:
  
  Note:
  The values mentioned in the syntax are sample values.
```
apiVersion: v1
kind: Secret
metadata:
  name: occnp-db-pass
type: Opaque
data:
  mysql-username: b2NjbnB1c3I=
  mysql-password: b2NjbnBwYXNzd2Q=
```
2. Create a YAML file with the admin user's username and password with the syntax shown below:
  
  Note:
  The values mentioned in the syntax are sample values.
```
apiVersion: v1
kind: Secret
metadata:
  name: occnp-admin-db-pass
type: Opaque
data:
  mysql-username: b2NjbnBhZG1pbnVzcg==
  mysql-password: b2NjbnBhZG1pbnBhc3N3ZA==
```
  '
  
  Note:
  name will be used to contain dbCredSecretName and privilegedDbCredSecretName parameters in the CNC Policy custom-values.yaml file.
  
  Note:
  The values for mysql-username and mysql-password should be Base64 encoded.
3. Run the following commands to add the Kubernetes secrets in a namespace:
```
kubectl create -f yaml_file_name1 -n release_namespace
kubectl create -f yaml_file_name2 -n release_namespace
```
  where:
  - release_namespace is the deployment namespace used by the helm command.
  - yaml_file_name1 is a name of the YAML file that is created in step a.
  - yaml_file_name2 is a name of the YAML file that is created in step b.
Verify whether the secret is created by executing the following command:
```
$ kubectl describe secret <secret-name> -n <namespace>
```

For more information, see cnDBTier Authentication and Authorization.

Create a Kubernetes Secret for Storing LDAP credentials

Use the following procedure to create a Kubernetes secret for storing LDAP credentials:

Create a YAML file with the following syntax:

Note:
The values mentioned in the syntax are sample values.
```
apiVersion: v1 
kind: Secret 
metadata:  
  name: secretarial  
  labels:    
    type: ocpm.secret.ldap 
type: Opaque 
stringData:  
  name: "ldap1"  
  password: "camiant"  
  authDn: "uid=PolicyServer,ou=samplename,c=hu,o=samplename"
```
where:
- name is the configured LDAP server name.
- password is the LDAP credential for that data source.
- authDN is the authentication DN for that LDAP data source.
- samplename is the sample operator name.
Create the secret by executing the following command:
```
kubectl apply -f yaml_file_name -n <namespace>
```
Here:
- yaml_file_name is a name of the YAML file that is created in step 1.
- <namespace> is the deployment namespace used by the helm command.

Network Policies

Note:

Configuring network policy is optional. Based on the security requirements, network policy can be configured.

For more information on the network policy, see https://kubernetes.io/docs/concepts/services-networking/network-policies/.

For more information on configuring the network policy, see Oracle Communications Cloud Native Core, Converged Policy Installation, Upgrade, and Fault Recovery Guide.

3.2.10 Oracle Communications Certificate Management (OCCM) Specific Security Recommendations and Guidelines

This section provides Oracle Communications Certificate Management (OCCM) specific security recommendations and guidelines. Security recommendations common to all 4G and 5G NFs are available in the Common Security Recommendations and Guidelines section.

Note:

The procedures are:

Global Service Account Configuration

This section is optional and it describes how to manually create a service account, role, and rolebinding.

A custom service account can be provided for OCCM deployment in global.serviceAccountName of occm_custom_values_<version>.yaml.

A custom service account can be provided for helm in global.serviceAccountName:

global:  
  dockerRegistry: cgbu-occncc-dev-docker.dockerhub-phx.oci.oraclecorp.com
  serviceAccountName: ""

Configuring Global Service Account to Manage NF Certificates with OCCM and NF in the Same Namespace

A sample OCCM Service account yaml file to create custom service account is as follows:

## Service account yaml file for occm-sa
apiVersion: v1
kind: ServiceAccount
metadata:
  name: occm-sa
  namespace: occm
  annotations: {}
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: occm-role
  namespace: occm
rules:
- apiGroups:
  - "" # "" indicates the core API group
  resources:
  - services
  - configmaps
  - pods
  - secrets
  - endpoints
  verbs:
  - get
  - watch
  - list
  - create
  - delete
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: occm-rolebinding
  namespace: occm
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: occm-role
subjects:
- kind: ServiceAccount
  name: occm-sa
  namespace: occm

Configuring Global Service Account to Manage NF Certificates with OCCM and NF in Separate Namespaces

OCCM provides support for key and certificate management in multiple namespaces.

In this deployment model, OCCM is deployed in namespace different from the components’ namespaces managed by it. It needs privileges to read, write, and delete Kubernetes secrets in the managed namespaces.

This is achieved by creating multiple namespace specific roles and binding them to the service account for OCCM.

AUTOMATIC Service Account Configuration: Roles and role bindings are created for each namespace specified using the occmAccessedNamespaces field in occm_custom_values.yaml. A service account for OCCM is created automatically and the roles created are assigned using the corresponding role binding.
Namespaces managed by OCCM service account:
```
occmAccessedNamespaces:
  - ns1
  - ns2
```
Note:
Automatic Service Account Configuration is applicable for Single Namespace Management as well

Custom Service Account Configuration: A custom service account can also be configured against the serviceAccountName field in occm_custom_values.yaml. If this is provided, automatic service account creation doesn't get triggered. The occmManagedNamespaces field doesn't need to be configured.

A sample OCCM service account yaml file for creating a custom service account is as follows:

apiVersion: v1
kind: Namespace
metadata:
  name: ns1
---
apiVersion: v1
kind: Namespace
metadata:
  name: ns2
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: occm-sa
  namespace: occm
  annotations: {}
---
 
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: ns1
  name: occm-secret-writer-role
rules:
- apiGroups:
  - "" # "" indicates the core API group
  resources:
  - secrets
  verbs:
  - get
  - watch
  - list
  - create
  - update
  - delete
---
 
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: ns2
  name: occm-secret-writer-role
rules:
- apiGroups:
  - "" # "" indicates the core API group
  resources:
  - secrets
  verbs:
  - get
  - watch
  - list
  - create
  - update
  - delete
 
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: occm-secret-writer-rolebinding
  namespace: ns1
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: occm-secret-writer-role
subjects:
- kind: ServiceAccount
  name: occm-sa
  namespace: occm
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: occm-secret-writer-rolebinding
  namespace: ns2
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: occm-secret-writer-role
subjects:
- kind: ServiceAccount
  name: occm-sa
  namespace: occm

Helm Test Service Account Configuration

helmTestServiceAccountName is an optional field in the


                    occm_custom_values_<version>.yaml

file It should be added only if helm kubernetes resource is enabled. Custom service account can be provided for helm in global.helmTestServiceAccountName::

global:
  helmTestServiceAccountName: occm-helmtest-serviceaccount

A sample helm test service account yaml file is as follows:

helm test service account apiVersion: v1
kind: ServiceAccount
metadata:
  name: occm-helmtest-serviceaccount
  namespace: occm
  annotations: {}
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: occm-helmtest-role
  namespace: occm
rules:
- apiGroups:
  - "" # "" indicates the core API group
  resources:
  - services
  - configmaps
  - pods
  - secrets
  - endpoints
  - serviceaccounts
  verbs:
  - get
  - watch
  - list
- apiGroups:
  - policy
  resources:
  - poddisruptionbudgets
  verbs:
  - get
  - watch
  - list
  - update
- apiGroups:
  - apps
  resources:
  - deployments
  - statefulsets
  verbs:
  - get
  - watch
  - list
  - update
- apiGroups:
  - autoscaling
  resources:
  - horizontalpodautoscalers
  verbs:
  - get
  - watch
  - list
  - update
- apiGroups:
  - rbac.authorization.k8s.io
  resources:
  - roles
  - rolebindings
  verbs:
  - get
  - watch
  - list
  - update
- apiGroups:
  - monitoring.coreos.com
  resources:
  - prometheusrules
  verbs:
  - get
  - watch
  - list
  - update
  
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: occm-helmtest-rolebinding
  namespace: occm
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: occm-helmtest-role
subjects:
- kind: ServiceAccount
  name: occm-helmtest-serviceaccount
  namespace: occm

Network Policies

Note:

Configuring network policy is optional. Based on the security requirements, network policy can be configured.

For more information on the network policy, see https://kubernetes.io/docs/concepts/services-networking/network-policies/.

For more information on configuring the network policy, see Oracle Communications Cloud Native Core, Certificate Management Installation, Upgrade, and Fault Recovery Guide.

TLS configuration

OCCM does not directly interact with other NF microservices. The access is only through the CNC Console.

Note:

OCCM supports authentication of the CA generating the certificates using the CMPv2 MAC based and signing mechanism.
As an additional layer of security encryption of the traffic between OCCM and Certificate Authority using HTTPs is supported.
Configuration options are provided at REST API and helm deployment level. Refer to installation and user guide for details on configuration options.

For more information on TLS configuration, see CNC Console IAM LDAP Configuration in the Cloud Native Configuration Console (CNCC) Specific Security Recommendations and Guidelines section.

3.2.11 OCI Adaptor Specific Security Recommendations and Guidelines

This section provides OCI Adaptor specific security recommendations and guidelines. Security recommendations common to all 4G and 5G NFs are available in the Common Security Recommendations and Guidelines section.

Note:

OCI Adaptor is deployed on OCI tenancy owned and managed by the customer. Therefore, customer is expected to develop an OCI security concept on their own.

OCI Adapter Registry Pull Secret (Automated)

While deploying OCI Adaptor, a registry pull secret must get created automatically (using Helm) and is used to pull OCI Adapter images from private Oracle Cloud Infrastructure Registry (OCIR).

Table 3-2 OCI Adaptor Secret

Secret Name	Secret Type	Secret Content
ocir-container-registry-secret	kubernetes.io/dockerconfigjson	registry_name: Must be provided by the user on OCI RM Stack UI. registry_username: Must be provided by the user on OCI RM Stack UI. registry_password: Must be provided by the user on OCI RM Stack UI.

Secret Name

Secret Type

Secret Content

ocir-container-registry-secret

kubernetes.io/dockerconfigjson

registry_name: Must be provided by the user on OCI RM Stack UI.

registry_username: Must be provided by the user on OCI RM Stack UI.

registry_password: Must be provided by the user on OCI RM Stack UI.

3.3 Cloud Native Configuration Console (CNC Console) Specific Security Recommendations and Guidelines

This section provides Cloud Native Configuration Console (CNC Console) specific security recommendations and procedures. Security recommendations common to all 4G and 5G NFs are available in the Common Security Recommendations and Guidelines Section.

Note:

Caution:

Note:

The procedures are:

CNC Console IAM MySQL Secret Configuration
CNC Console IAM Default User (Admin) Secret Configuration
OCI IAM Secret Configuration
CNC Console IAM LDAPS Secret Configuration
CNC Console IAM LDAP Configuration
CNC Console TLS Secret configuration
CNC Console Core Secret Configuration to Enable HTTPS
CNC Console IAM SAML Configuration
OCI IAM SAML Configuration
- Adding a SAML Identity Provider in OCI IAM
- JIT Configuration in OCI IAM
Configuring Role Mapping in OCI IAM
Network Policies

CNC Console IAM MySQL Secret Configuration

Use the following procedure to create MySQL Kubernetes secret:

Log in to Bastion Host or server from where kubectl can be executed
Create namespace for the secret by running the following commands:
1. Verify whether the required namespace already exists in system by running the following command:
```
$ kubectl get namespaces
```
2. If the output of the above command does not display the required namespace, create the namespace by running following command:
```
$ kubectl create namespace <required namespace>
```
  Example:
```
$ kubectl create namespace cncc
```

Run the following command to create the Kubernetes secret for MySQL:

kubectl create secret generic <database secret name> --from-literal=dbUserNameKey=<CNCC 
Mysql database username> --from-literal=dbPasswordKey=<CNCC Mysql database password> -n <Namespace of MySQL secret

Example:

$ kubectl create secret generic cncc-db-secret --from-literal=dbUserNameKey=root --from-
literal=dbPasswordKey=mypass -n cncc

Run the following command to verify the secret creation:

$ kubectl describe secret <database secret name> -n <Namespace of MySQL secret>

Example:

$ kubectl describe secret cncc-db-secret -n cncc

CNC Console IAM Default User (Admin) Secret Configuration

Note:

Not applicable for OCI deployment.

Use the following procedure to create default user (Admin) secret :

Log in to Bastion Host or server from where kubectl can be executed
Create namespace for the secret by running the following commands:
Verify whether the required namespace already exists in system by running the following command:
```
$ kubectl get namespaces  
```
If the output of the above command does not display the required namespace then create the namespace by running following command:
```
$ kubectl create namespace <required namespace>
```
Example:
```
$ kubectl create namespace cncc
```

Run the following command to create the Kubernetes secret for MySQL for Admin User:

$ kubectl create secret generic <secret-name> --from-literal=iamAdminPasswordKey=<password> --namespace <namespace>

Example:

$ kubectl create secret generic cncc-iam-secret --from-literal=iamAdminPasswordKey=cncciampasswordvalue --namespace cncc

Run the following command to verify the secret creation:

$ kubectl describe secret <secret name> -n <namespace>

Example:

$ kubectl describe secret cncc-iam-secret -n cncc

OCI IAM Secret Configuration

Note:

This section is applicable only for OCI deployment.

Run the following commands to create the oci iam secret:

Run the following command to create the Kubernetes secret for OCI IAM clientId and clientSecret:
```
$ kubectl create secret generic <secret-name> --from-literal=clientId='<clientId>' --from-literal=clientSecret='<clientSecret>' --namespace <namespace>
```

Run the following command to verify whether the secret is created:

$ kubectl describe secret <secret name> -n <namespace>

Example:


$ kubectl create secret generic oci-iam-secret --from-literal=clientId='269d98xxxxbb5064' --from-literal=clientSecret='6779exxxxx9602' --namespace cncc
$ kubectl describe secret oci-iam-secret -n cncc

CNC Console IAM LDAPS Secret Configuration

Use the following procedure to create the secrets to enable LDAPS:

Note:

The value of ssl_truststore.txt and ssl_truststore-password-key value must be same.

Log in to Bastion Host or server from where kubectl can be run.
Create namespace for the secret by running the following commands:
Verify whether the required namespace already exists in system by running the following command:
```
$ kubectl get namespaces  
```
If the output of the above command does not display the required namespace then create the namespace by running following command:
```
$ kubectl create namespace <required namespace> 
```
Example:
```
$ kubectl create namespace cncc 
```

Create a secret by running the following command:

kubectl create secret generic <secret-name> --from-file=<caroot.cer> 
--from-file=ssl_truststore.txt --from-literal=ssl_truststore-password-key=<password> --namespace cncc

Note:

The command is used for Kubernetes secret updates in future.

Example:

$ kubectl create secret generic cncc-iam-kc-root-ca --from-file=caroot.cer
      --from-file=ssl_truststore.txt --from-literal=ssl_truststore-password-key=<password> --namespace
      cncc

Run the following to display the sample ssl_truststore.txt:

echo <password> > ssl_truststore.txt

On successfully running the above command, the following message is displayed:
secret/cncc-iam-kc-root-ca created
Run the following command to verify the secret creation:
```
$ kubectl describe secret cncc-iam-kc-root-ca -n cncc
```

CNC Console IAM LDAP Configuration

Use the following procedure to configure CNC Console IAM LDAP :

Set up User Federation with CNC Console IAM by running following steps:
1. Log in to CNC Console IAM application.
2. Select Cncc Realms and then select User Federation; User federation Screen appears.
3. Fill the necessary parameters and save.
4. New buttons (Synchronize changed users, Synchronize all users, Remove imported, Unlink users) appear next to the Save and Cancel.
5. If a user has to be imported to CNCC-IAM, Click Synchronize all users.
6. The user can view the imported users by clicking Users under Manage in the left pane and click View all users in the right pane.
Steps to add Group-Mapper and Assign Roles:
1. Log in to CNC Console IAM application.
2. Select Cncc Realms and then select User Federation; User federation Screen appears.
3. Click Configure and select User Federation. Click ldap (Console Display Name) and select the Mappers tab, and click Create.
4. The Add User federation mapper page appears. Select 'group-ldap-mapper' as Mapper Type from dropdown menu. Click Save.
5. Enter the details in the new screen and Save.
6. New buttons Synchronize LDAP Groups to Keyclaok and Synchronize Keyclaok Groups to LDAP appear.
7. Click Synchronize LDAP Groups to Keyclaok.
8. Select the Groups in the left pane and click the View all groups in the right pane.
9. Click any group and then click Edit. The following tabs appear: Settings, Attributes, Role Mappings, and Members.
10. Select Role Mapping tab to see a list of roles that are pre-defined in cncc-iam.
11. Select one or more roles from Available Roles and assign it to the group.

CNC Console TLS Secret configuration

Use the following procedure to configure CNC C TLS Secret:

To create Kubernetes secret for HTTPS, the following files are required:
- ECDSA private key and CA signed certificate of CNC Console (if initial Algorithm is ES256)
- RSA private key and CA signed certificate of CNC Console (if initial Algorithm is RSA256)
- TrustStore password file
- KeyStore password file
- CA certificate

Create a secret by running the following command:

$ kubectl create secret generic <secret-name> --fromfile=<ssl_ecdsa_private_key.pem>
      --from-file=<rsa_private_key_pkcs1.pem> --fromfile=<ssl_truststore.txt>
      --from-file=<ssl_keystore.txt> --from-file=<caroot.cer> --fromfile=<ssl_rsa_certificate.crt>
      --from-file=<ssl_ecdsa_certificate.crt> -n <Namespace of CNCC IAM Ingress Gateway
    secret>

Example:

$ kubectl create secret generic cncc-iam-ingress-secret
      --fromfile=ssl_ecdsa_private_key.pem  --from-file=rsa_private_key_pkcs1.pem
      --fromfile=ssl_truststore.txt --from-file=ssl_keystore.txt --from-file=caroot.cer
      --fromfile=ssl_rsa_certificate.crt --from-file=ssl_ecdsa_certificate.crt -n
    cncc

On successfully running the above command, the following message will be displayed:

secret/cncc-iam-ingress-secret created

Run the following command to verify the secret creation:

$ kubectl describe secret cncc-iam-ingress-secret -n cncc

This section explains how to update the secrets for enabling HTTPS, if they already exist:

Create a secret by running the following command:

$ kubectl create secret generic <secret-name> --fromfile=<ssl_ecdsa_private_key.pem>
      --from-file=<rsa_private_key_pkcs1.pem> --fromfile=<ssl_truststore.txt>
      --from-file=<ssl_keystore.txt> --from-file=<caroot.cer> --fromfile=<ssl_rsa_certificate.crt>
      --from-file=<ssl_ecdsa_certificate.crt> --dry-run -o yaml -n <Namespace of CNCC IAM Ingress
      Gateway secret> | kubectl replace -f - -n <Namespace of CNCC IAM Ingress Gateway
    secret>

Example:

$ kubectl create secret generic cncc-iam-ingress-secret
      --fromfile=ssl_ecdsa_private_key.pem  --from-file=rsa_private_key_pkcs1.pem
      --fromfile=ssl_truststore.txt --from-file=ssl_keystore.txt --from-file=caroot.cer
      --fromfile=ssl_rsa_certificate.crt --from-file=ssl_ecdsa_certificate.crt --dry-run -o yaml -n
      cncc | kubectl replace -f - -n cncc

On successfully running the above command, the following message will be displayed:

secret/cncc-iam-ingress-secret replaced

CNC Console Core Secret Configuration to Enable HTTPS

Note:

Not applicable for OCI deployment.

Use the following procedure to configure CNC Console Core Secret to Enable HTTPS:

To create Kubernetes secret for HTTPS, the following files are required:
- ECDSA private key and CA signed certificate of CNC Console (if initial Algorithm is ES256)
- RSA private key and CA signed certificate of CNC Console (if initial Algorithm is RSA256)
- TrustStore password file
- KeyStore password file
- CA certificate

Create a secret by running the following command:

$ kubectl create secret generic <secret-name> --fromfile=<ssl_ecdsa_private_key.pem>
      --from-file=<rsa_private_key_pkcs1.pem> --fromfile=<ssl_truststore.txt>
      --from-file=<ssl_keystore.txt> --from-file=<caroot.cer> --fromfile=<ssl_rsa_certificate.crt>
      --from-file=<ssl_ecdsa_certificate.crt> -n <Namespace of CNCC Core Ingress Gateway
    secret>

Example:

kubectl create secret generic cncc-core-ingress-secret --fromfile=ssl_ecdsa_private_key.pem 
      --from-file=rsa_private_key_pkcs1.pem --fromfile=ssl_truststore.txt
      --from-file=ssl_keystore.txt --from-file=caroot.cer --fromfile=ssl_rsa_certificate.crt
      --from-file=ssl_ecdsa_certificate.crt -n cncc

On successfully running the above command, the following message will be displayed:

secret/cncc-core-ingress-secret created

Run the following command to verify the secret creation:

$ kubectl describe secret cncc-core-ingress-secret -n cncc

This section explains how to update the secrets for enabling HTTPS if they already exist:

Create a secret by running the following command:

$ kubectl create secret generic <secret-name> --fromfile=<ssl_ecdsa_private_key.pem>
      --from-file=<rsa_private_key_pkcs1.pem> --fromfile=<ssl_truststore.txt>
      --from-file=<ssl_keystore.txt> --from-file=<caroot.cer> --fromfile=<ssl_rsa_certificate.crt>
      --from-file=<ssl_ecdsa_certificate.crt> --dry-run -o yaml -n <Namespace of CNCC Core Ingress
      Gateway secret> | kubectl replace -f - -n <Namespace of CNCC Core Ingress Gateway
    secret>

Example:

$ kubectl create secret generic cncc-core-ingress-secret
      --fromfile=ssl_ecdsa_private_key.pem  --from-file=rsa_private_key_pkcs1.pem
      --fromfile=ssl_truststore.txt --from-file=ssl_keystore.txt --from-file=caroot.cer
      --fromfile=ssl_rsa_certificate.crt --from-file=ssl_ecdsa_certificate.crt --dry-run -o yaml -n
      cncc | kubectl replace -f - -n cncc

On successfully running the above command, the following message will be displayed:

secret/cncc-core-ingress-secret replaced

CNC Console IAM SAML Configuration

Use the following procedure to configure CNC Console IAM SAML:

To configure SAML identity provider (IdP) in CNC Console IAM, log in to CNC Console IAM Console using admin credentials provided during installation of CNC Console IAM .
Select Cncc realm and the Identity Provider tab in the left pane. Identity Providers screen appears in the right pane.
From the Add provider drop down list select the saml entry and the Add Identity Provider screen appears.
To create custom 'First Login Flow', click Authentication tab In the left pane. The Authentication screen appears.
Click New at the right pane. Create Top Level Form screen appears.
Enter the appropriate alias and click Save.
The Authentication screen with the newly created custom flow selected in the drop down list appears. Click Add Execution in the right pane .
Create Authenticator Execution screen appears.
Select Create User If Unique from the Provider drop down list. Click Save.
The Authentication screen appears with the newly created custom flow selected in the drop down. Under Requirement section, select Alternative.
Select Identity Provider in the left pane. Select the custom flow from First Login Flow drop down list.

OCI IAM SAML Configuration

SAML (Security Assertion Markup Language) enables applications to authenticate a user using an identity provider. The identity provider authenticates the user and returns the assertion information about the authenticated user and the authentication event to the application. If the user tries to access any other application that uses the same identity provider for user authentication, the user shall not be required to log in a second time and will be granted access. This is the principle of SSO (Single Sign On).

Note:

OCI IAM provides option to implement SAML SSO. This is an optional step.
Applicable only for OCI deployment.

The following section describes the steps to implement SAML SSO in OCI IAM.

Adding a SAML Identity Provider in OCI IAM

Navigate to the identity domain: Open the navigation menu and click Identity & Security. Under Identity, click Domains.
Click the name of the identity domain that you want to work in. You might need to change the compartment to find the domain that you want.
Then, click Security and then Identity providers.
Click Add IdP, and then click Add SAML IdP.
Enter the following information:
- Name: Enter the name of the IdP.
- (Optional) Description: Enter a description of the IdP.
- (Optional) Identity provider icon: Drag and drop a supported image, or click select one to browse for the image.
Click Next.
On the Exchange metadata screen, do one of the following:
- Import IdP metadata: Select this option if you have an XML file exported from your IdP. Drag and drop the XML file to upload the metadata, or click select one to browse for the metadata file.
- Enter IdP metadata: Select this option if you want to manually enter the IdP metadata. Provide the following details:
  - Identity provider issuer URI
  - SSO service URI
  - SSO service binding
  - Upload identity provider signing certificate
  - Enable global logout
  - Identity provider logout request URL
  - Identity provider logout response URL
On the Map User Identity Screen, keep the Requested Name ID Format as None
Map user's identity attributes received from the IdP to an Oracle Cloud Infrastructure identity domain. Mapping options vary based on identity provider. You might be able to directly assign an IdP value to an Oracle Cloud Infrastructure identity domain value. For example, NameID might map to UserName. If you select SAML assertion attribute as the source, select the Assertion attribute name and then enter the Oracle Cloud Infrastructure identity domain.
Click Submit.
On the Review and create screen, review your SAML identity provider settings. If the settings are correct, click Create. Click Edit next to the set of settings, if you need to change them.
The console displays a message when the SAML identity provider is created. You can do the following from the overview page:
- Click Test to verify that the SAML SSO connection is working correctly.
- Click Activate to activate the IdP so the identity domain can use it.
- Click Assign to IdP policy rule to assign this SAML identity provider to an existing policy rule you have created.
Click Close.

At this point, the SAML IDP is configured, but any user created in SAML IDP needs to be created in OCI IAM in-order to allow a successful Login
In order to directly login to CNCC Core via SAML IdP, JIT Provisioning needs to configured (Just-In-Time)

OCI IAMs SAML Metadata can be exported, by clicking on "Export SAML Metadata" on the "Identity Providers" Tab as shown above.
The exported file, can be used to configure SAML Client in an IdP

3. JIT Configuration in OCI IAM

JIT stands for Jut-In-Time Provisioning. It allows the federated user to be created in OCI IAM users List whenever a federated user logs in for the first time. Follow below steps to configure this in OCI-IAM

On the IDP Configuration Page, click Configure JIT
Enable Just-In_Time(JIT) provisioning
Select one/both of the following options as required:
- Create a new identity domain user: Create an identity user in the identity domain, if the user doesn't exist when sign in with the identity provider.
- Update the existing identity domain user: Merge and overwrite identity domain user account data from the mapped IdP. The existing data is overwritten by the user data from the IdP.
In the Map user attributes area , map a user account from the IdP to a user account from the identity domain.
1. Select a value in the IdP user attribute type row.
  - If you select Attribute, then enter the IdP user attribute name.
  - If you select NameID, you don't need to enter the IdP user attribute name.
2. (Optional) Select the identity domain user attribute.
3. (Optional) Add more identity domain attributes.

For example, as per above screenshot NameID value to userName is the default mapping, and the name to familyName mapping is configured by the user.

OCI IAM will look for an attribute named namein the Assertions coming from SAML IdP, as mentioned below:

<saml:AttributeStatement>
      <saml:Attribute FriendlyName="name"
                      Name="name"
                      NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
        <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema"
                             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                             xsi:type="xs:string">SamlUser</saml:AttributeValue>
      </saml:Attribute>

The user needs to make sure the SAML IDP is populating these attributes in the assertions , else JIT Configuring will not work, thus failing the SAML SSO Authentication

4. Configuring Role Mapping in OCI-IAM

Role Mapping for SAML in OCI IAM is configured as a part of JIT Provisioning configuration. Below mentioned steps can be followed

On the IDP Configuration Page, click Configure JIT
To enable group mapping, click Assign group mapping
For Group membership attribute name enter the IdP attribute name that contains group memberships.
To import the group settings, select one of the following options:
- Define explicit group mapping: This option requires you to provide the group name to map between the IdP and identity domain. If you select this option, enter the IdP group name and select an available identity domain group name.
- Assign implicit group mapping: This option maps an IdP group to an identity domain group that has the same name. No other action is required.
  - OCI-IAM reads Roles as Groups, "Group membership attribute name" has assigned as groups
  - After this CNC Console (OCI-IAM) Groups can be mapped to the IdP Groups as mentioned in the below screenshot
Under Assignment rules, specify actions to take when assigning group memeberships:
1. If users are assigned to existing groups, select whether to merge with existing group memberships or replace existing group memberships.
When a group isn't found, select to take one of the following actions:
1. Ignore the missing group: The user successfully signs in.
2. Fail the entire request: The sign-in attempt fails.
Click Save Changes.

OCI-IAM will be reading Groups from the SAML Assertions.
As the Role Mapping is created through 'groups' attribute name, OCI-IAM will look for 'groups' attribute in SAML Assertions.
Ensure the IDP is sending the required attributes in assertions

5. Assigning Idp to Identity provider (IdP) policies

Under your domain , click Security and then Idp policies.
Create Idp policy if required else use Default Identity Provider Policy.
Under your Identity Provider Policy , click on Add Idp Rule to create a new Rule if required else to use Default IDP Rule click on the Edit IdP rule.
Assign the name of IdP under Assign identity providers.
Click Save to save the changes and exit.

Network Policies

Note:

Configuring network policy is optional. Based on the security requirements, network policy can be configured.

For more information on the network policy, see https://kubernetes.io/docs/concepts/services-networking/network-policies/.

For more information on configuring the network policy, see Oracle Communications Cloud Native Configuration Console, Installation, Upgrade, and Fault Recovery Guide.

3.4 Cloud Native Environment (CNE) Specific Security Recommendations and Guidelines

After installation, audit the CNE security system stance before deploying the system into service. This primarily consists of changing credentials and unique SSH keys to trusted servers. The following table lists all the credentials that need to be checked, changed, and retained:

Note:

Caution:

Credential Name	Deployment	Credential Type	Associated Resource	Initial Setting for Credential Type	Credential Rotation
TOR Switch	Bare Metal Only	username and password	Cisco Top or Rack Switch	username and password from PreFlight Checklist	Reset postinstallation
Enclosure Switch	Bare Metal Only	username and password	HP Enclosure Switch	username and password from PreFlight Checklist	Reset postinstallation
OA Admin	Bare Metal Only	username and password	On-board Administrator Console	username and password from PreFlight Checklist	Reset postinstallation
ILO Admin	Bare Metal Only	username and password	HP Integrated Lights Out Manger	username and password from PreFlight Checklist	Reset postinstallation
Server Super User (root)	VM, Bare Meta, and OpenStack	username and password	Server Super User	Set to well-known Oracle default during server installation	Reset postinstallation
Server Admin User SSH	VM, Bare Meta, and OpenStack	SSH Key Pair	Server Admin User	Key Pair generated at install time	Can rotate keys at any time; key distribution manual procedure

If factory or Oracle defaults were used for any of these credentials, they must be changed before placing the system into operation. The customer must store these credentials safely and securely offsite. It is recommended that the customer must plan a regular schedule for updating (rotating) these credentials. Specific procedures and recommendations for CNE credential management are provided below:

Note:

Network Security Recommendations and Procedures

Recommendation: Review and Follow Configuring the TOR switches procedures.

The CNE on-premise installation guide provides detailed procedures on how to configure the TOR switches and configure them for remote monitoring. Deviations from the standard installation time configurations are not recommended.

For more information, see Oracle Communications Cloud Native Core, Cloud Native Environment Installation, Upgrade, and Fault Recovery Guide

Credential Management Procedures

Procedure 1: Setting Top Of Rack Switch Credentials

This procedure is used to set the credentials on the Cisco TOR switch as deployed with the bare metal deployment option. Steps for creating and deleting accounts and for setting account passwords are given below:

Log in to the TOR switch (from the bastion host):

$ ssh <username>@<switchIP address>
User Access Verification

Password: <password>
Cisco Nexus Operating System (NX-OS) Software

TAC support: www.cisco.com/tac

<switchname>#
Change the password for <username>:
# configure

Enter configuration commands, one per line. End with CNTL/Z.
(config)# username <username> password<newpassword>
(config)#exit
Create a new user (if desired):

# configure
Enter configuration commands, one per line. End with CNTL/Z.
(config)# username <newusername> password <newpassword> role [network-operator|network-admin|vdc-admin|vdc-operator] (config)#exit
Verify the account changes by exiting the ssh session (type exit) and repeat step 1.

# exit
Connection to <switchIP address> closed.
```
$ ssh <newusername>@<switchIP address>  
```
User Access Verification Password: <newpassword>

Cisco Nexus Operating System (NX-OS) SoftwareTAC support: www.cisco.com/tac

<switchname>#
Delete an unrequired user account:

# configureEnter configuration commands, one per line. End with CNTL/Z.
```
(config)# no username <username>
```
(config)#exit
Change the enable secret:
(config)# enable secret <newenablepassword>
(config)# exit
Save the configuration changes:
# copy running-config startup-config

100%

Copy complete, now saving to disk (please wait)...

Copy complete.

Note:

Change TOR passwords before placing site into service: The TOR switch credentials show the changes prior to placing the site into service.
Use Strong Passwords: The Network Administrator must choose complex TOR Switch passwords as per their organization's security guidelines.

Procedure 2: Setting Enclosure Switch Credentials

This procedure is used to set the credentials on the HP enclosure switch as deployed with the bare metal deployment option. Steps for creating and deleting accounts and for setting account passwords is given below. For additional information, refer to HP commands to configure enclosure switch username and password.

Setting Enclosure Switch Credentials

$ ssh <username>@< switchIP address>

Copyright (c)2010-2017Hewlett Packard Enterprise Development LP ** Without the owner's prior written consent, 
** no decompiling or reverse-engineering shall be allowed. 
<switchname> 
<switchname> 
sysSystem View:returnto User View with Ctrl+Z.

Change the password for the current username:

[switchname]local-user <username>class <currentclass> 
[switchname-luser-manage-<username>]password simple <newpassword> 
[switchname-luser-manage-<username>]quit

Create a new user account:

[switchname]local-user <newusername>class[manage|network]

New local user added

[switchname-luser-manage-<newusername>]password simple <newpassword>
[switchname-luser-manage-<newusername>]quit

Delete the user account that is not required:

[switchname]undo local-user <username>class <currentclass>

Delete the user account that is not required:

[switchname]undo local-user <username>class <currentclass>

Save the configuration changes:

[switchname]save 
The current configuration will be written to the device. Are you sure? [Y/N]: y 
Please input the file name(*.cfg)[flash:/<filename>] 
(To leave the existing filename unchanged, press the enter key): 
flash:/<filename> exists, overwrite? [Y/N]: yValidating file. Please wait... 
Saved the current configuration to mainboard device successfully. 
Slot1: 
Save next configuration file successfully. 
[switchname] 
[switchname]save 
The current configuration will be written to the device. Are you sure? [Y/N]: y 
Please input the file name(*.cfg)[flash:/<filename>] 
(To leave the existing filename unchanged, press the enter key): 
flash:/<filename> exists, overwrite? [Y/N]: yValidating file. Please wait... 
Saved the current configuration to mainboard device successfully. 
Slot1: 
Save next configuration file successfully. 
[switchname]

Note:

Set Enclosure Switch Credentials before Placing Into Service: The HP Enclosure switch credentials show are to be changed prior to placing the site into service.
Use Strong Passwords: The Network Administrator must choose complex Enclosure Switch passwords as per their organization's security guidelines.

Hosting Environment Security Recommendations and Procedures

The best way to keep your CNE environment secure is to keep it updated. New CNE releases are typically carried out every two months. The CNE upgrade does not affect the service and typically installs the newer versions of:

Host OSs
Kubernetes and associated containers
cnDBTier binaries
Common service containers

The upgrade process ensures that the uplifts do not affect active service. See Oracle Communications Cloud Native Core, Cloud Native Environment Upgrade Guide for more details.

Note:

Given below are some Repository Management Recommendations to be followed:

Keep central yum repositories updated: Keep central repositories updated with latest yum packages; yum updates are performed on-site whenever a fresh install or upgrade is performed. An up-to-date yum repository will help ensure that fixes for all publish vulnerabilities are applied.
Scan docker image repositories regularly: Scan your docker image repositories regularly using a tool such as clair or anchore-engine. All images are scanned and vulnerabilities are assessed at product development time, but new exploits or vulnerabilities may be reported or fixed later. Scan tools typically use a database of known vulnerabilities. Refer to tool vendor for instructions on creating off-line (internet isolated) vulnerability databases.

Credential Management Procedures

The given below procedures to manage your credentials:

Procedure 1: Setting HP Onboard Administrator (OA) Credentials.

This procedure is applicable only to Bare Metal deployments. This procedure is used to set the credentials on the HP Onboard Administrator as deployed with the bare metal deployment option. Steps for creating and deleting accounts and for setting account passwords are shown. For additional information, please refer to HP commands to configure OA username and password.

$ ssh <username>@<OA address>

WARNING: This is a private system. Do not attempt to log in unless you are unauthorized user. Any authorized or unauthorized access and use may be monitored and can result in criminal or civil prosecution under applicable law .


Firmware Version: 4.85 
Built:04/06/2018@06:14OA 
 Bay Number:1 
OA Role: Active 
<username>@<OA address>'s password: <password>  
HPE BladeSystem Onboard Administrator 
(C) Copyright 2006-2018 Hewlett Packard Enterprise Development LP 
Type 'HELP' to display a list of valid commands. 
Type 'HELP <command>' to display detailed information about a specific command. 
Type 'HELP HELP' to display more detailed information about the help system. 
OA-A45D36FD5FB1>

Change the current password:


OA-A45D36FD5FB1> set password <newpassword> 
Changed password for the"<username>"user account. 
OA-A45D36FD5FB1>

Add new user:

OA-A45D36FD5FB1> add user <newusername> 
New Password: <newpassword> 
Confirm : <newpassword> 
User"<newusername>"created. 
You may set user privileges with the 'SET USER ACCESS' and 'ASSIGN' commands. 
OA-A45D36FD5FB1> set user access <newusername> [ADMINISTRATOR|OPERATOR|USER] "<newusername>" 
has been given [administrator|operator|user] level privileges.

Assign full access to the enclosure for the user:


OA-A45D36FD5FB1> assign server all <newusername> 
<newusername> has been granted access to the valid requested bay (sOA-A45D36FD5FB1> assign interconnect all <newusername> 
<newusername> has been granted access to the valid requested bay(s)OA-A45D36FD5FB1> assign oa <newusername> 
<newusername> has been granted access to the OA.

Verify the new account:

OA-A45D36FD5FB1> exit 
Connection to <OA address> closed.
[bastion host]# ssh <newusername>@<OA address> 
WARNING: This is a private system. Do not attempt to log in unless you are unauthorized user. 
Any authorized or unauthorized access and use may be monitored and can result in criminal or 
civil prosecution under applicable law. 
Firmware Version : 4.85 
Built : 04/06/2018 @ 06:14 
OA Bay Number : 1 
OA Role : Active 
<newusername>@<OA address>'s password: <newpassword>  
HPE BladeSystem Onboard Administrator 
(C) Copyright 2006-2018 Hewlett Packard Enterprise Development LP 
Type 'HELP' to display a list of valid commands. 
Type 'HELP <command>' to display detailed information about a specific command. 
Type 'HELP HELP' to display more detailed information about the help system. OA-A45D36FD5FB1>

Delete the user account:

OA-A45D36FD5FB1> remove user <username> 
Entering anything other than 'YES' will result in the command not executing. 
Are you sure you want to remove testuser1? yes 
User"<username>"removed.

Procedure 2: Setting HP Integrated Lights Out Manger (ILO) Credentials

This procedure is applicable only to Bare Metal deployments. This procedure is used to set the credentials on the HP Integrated Lights Out Managers as deployed with the bare metal deployment option. Steps for creating and deleting accounts and for setting account passwords is shown.

$ ssh <username>@<iLO address>

<username>@<iLO address>'s password: <password>User:<username> 
logged-in to ...(<iLO address> / <ipv6 address>)
iLO Advanced2.61at Jul272018 
Server Name: <server name> 
Server Power: On 
</>hpiLO->

Change the current password:

</>hpiLO-> set /map1/accounts1/ <username> password= <newpassword>  
status=0 
status_tag=COMMAND COMPLETED 
Tue Aug2013:27:082019 
</>hpiLO->

Create a new user account:

</>hpiLO-> create /map1/accounts1 username= <newusername> password= <newpassword> 
group=admin,config,oemHP_rc,oemHP_power,oemHP_vm 
status=0 
status_tag=COMMAND COMPLETED 
Tue Aug2013:47:562019 
User added successfully.

Verify the new user account:


</>hpiLO-> exit 
status=0 
status_tag=COMMAND COMPLETED 
Tue Aug2013:30:522019CLI session stoppedReceived disconnect from <iLO address> port22:11: Client Disconnect 
Disconnected from <iLO address> port22 
[bastion host]# ssh <newusername>@<iLO address> 
<newusername>@<iLO address>'s password: <newpassword> 
User:<newusername> logged-in to ...(<iLO address> / <ipv6 address>) 
iLO Advanced2.61at Jul272018 
Server Name: <server name>Server 
 Power: On</>hpiLO->

Delete an unneeded account:


</>hpiLO-> delete /map1/accounts1/ <username> 
status=0 
status_tag=COMMAND COMPLETED 
Tue Aug2013:59:042019 
User deleted successfully.

Procedure 3: Setting Root Passwords for All Cluster Nodes

The procedure to reset the root account requires that the administrator log in to each and every server. This procedure is applicable to all CNE deployments.

To reset the root account, perform the following steps for each and every server in the cluster:

Perform the root password change:

$ sudo passwd root

New password: <new password>
Retype new password: <new password>
Retype new password:<new password>

Repeat step 1 and step 2 for each and every server in the cluster.

Note:

The administrator (admusr) account is provided without a usable password hash. Thus requiring the use of SSH keys to access the account. The SUDO user access is configured without the requirement of a password. If you would like to enable the SUDO passwords for the administrator, you also need to assign a password to the administrator account using a procedure very similar to the one outlined above.

Procedure 4: Updating admusr SSH Keys for All Cluster Nodes

There are two sets of SSH keys used in a deployed cluster: The key used to access the bastion host and the key used to access the cluster servers. This procedure is applicable to all CNE deployments.

These key-pairs are generated at install time and are only usable on the cluster they were generated for. The public key portion of the bastion host key pair is typically provided to administrators who will manage the cluster. The key pair used to access the cluster servers should be kept local to the cluster:

Table 3-3 Updating admusr SSH Keys

Key Pair Name	Public Key Distribution	Private Key Distribution
Bastion Host	Place copy in the authorized_keys file on the bastion host.	Cluster Admin: Place in the cluster admin key agent (e.g., ssh-agent or pageant) external to the cluster. Do not copy to any host on the cluster.
Cluster Hosts	Place a copy in the authorized_keys files on each and every cluster host; do not configure on the bastion host.	Bastion Host: ~admusr/.ssh directory. This will be used when performing orchestration activities (install / upgrade).

To replace either of these key pairs starts with an openssh request to generate a new keypair:

ssh-keygen -b 4096 -t rsa -C "New SSH Key" -f
      .ssh/new_occne_id_rsa -q -N ""

This command generates the following key pair:

Key Name	Purpose
new_occne_id_rsa	The private key
new_occne_id_rsa.pub	The public key

Update the bastion host keys

Log in to the bastion host and generate a new key pair using the ssh-keygen command show above.
```
$ ssh-keygen -b 4096 -t rsa -C "New
            Bastion Key" -f ~/.ssh/new_occne_id_rsa -q -N
    ""
```
Copy the private key portion of the key off cluster and make it available to your ssh agent of choice or store it in the .ssh directory of your client machine. See instructions for your specific SSH client (for example, putty or openssh)
Add the new public key to the authorized key file on the bastion host:
```
$ cat ~/.ssh/new_occne_id_rsa.pub >>
    ~/.ssh/authorized_keys
```

Confirm the permissions of the .ssh directory and files:

$ ls -la ~/.ssh
total 32
drwx------. 2 admusr admusr 4096 Feb 25 15:48 .
drwx------. 42 admusr admusr4096 Feb 24 15:14 ..
-rw-------. 1 admusr admusr 796 Jan 28 14:43 authorized_keys
-rw-------. 2 admusr admusr 545 Feb 12 13:58 config
-rw-------. 1 admusr admusr 3239 Feb 25 15:48 new_occne_id_rsa
-rw-r--r–. 1 admusr admusr 737 Feb 25 15:48 new_occne_id_rsa.pub

In general, the .ssh directory should be mode 700 and the files under that directory should be mode 600.

Confirm that the new key works. Remove the old key from your ssh client's agent (see instructions for your client) and confirm that you can still log in.
Assuming that you were able to Log in using the new key pair, remove the old key pair from the authorized_keys file using your favorite editor.

In general, the authorized_keys file should at this point have two keys in it - the old one and the new one. The new one should be at the bottom.

Note:

Access to Bastion Host container registry is TLS enabled and only CNE has access to it.

General Security Administration Recommendations and Procedures

Note:

Record configuration changes: In a disaster recovery scenario, Oracle provided procedures will only restore base system behavior (they will not include restoration of an special configurations or tweaks). We recommend that all post-delivery customization be logged or automated using tools such as Ansible.

Password Policy Administration Procedures

In general, the host environments use a user account named admusr which is not configured with a password; the only way to access this account is using SSH keys. We recommend using SSH keys rather than passwords for all non-root accounts. The root account cannot be accessed via ssh; the only access is via the console. For this account, we recommend setting a password and storing it off-site to be used only for break-glass console access to the host.

User Administration Recommendations

Customers may want to create additional accounts to manage separate concerns (Example: a dbadmin account, a k8sadmin account, and so on). This can be done using normal Linux user administration procedures.

SSHD Policy Administration Procedures

Customers may want to create augment the standard sshd configuration to perform additional hardening; this can be done using normal Linux ssh administration procedures. Note that in a disaster recovery scenario, Oracle provided procedures will only restore base system behavior (they will not include restoration of an special configurations or tweaks).

Note:

Review changes with Oracle Support: We recommend reviewing any planned changes to sshd configuration with your Oracle Support contact. Improper sshd configuration can either open the system up to attacks or prevent proper system operation.

Auditd Policy Administration Procedures

Customers may want to augment the standard auditd configuration to perform additional monitoring; this can be done using normal Linux auditd administration procedures. Place all customizations in a separate file in the /etc/audit/rules.d directory, do not modify any of the other existing audit configuration files.