4 Post Installation Activities
This chapter describes the verification and security hardening procedures post installation of OCCNE.
Post Install Verification
Introduction
This document verifies installation of CNE Common services on all nodes hosting the cluster. There are different UI end points installed with common services like Kibana, Grafana, Prometheus Server, Alert Manager; below are the steps to launch different UI endpoints and verify the services are installed and working properly.
Prerequisities
- Common services has been installed on all nodes hosting the cluster.
- Gather list of cluster names and version tags for docker images that were used during install.
- All cluster nodes and services pods should be up and running.
- Commands are required to be run on Management server.
- Any Modern browser(HTML5 compliant) with network connectivity to CNE.
Table 4-1 OCCNE Post Install Verification
Step No. | Procedure | Description |
---|---|---|
1.
![]() |
Run the commands to get the load-balancer IP address and port number for Kibana Web Interface. |
Launch the Browser and navigate to http://$KIBANA_LOADBALANCER_IP:$KIBANA_LOADBALANCER_PORT(e.g.: http://10.75.182.51:80 in the example above) received in the output of the above commands. |
2.
![]() |
Using Kibana verify Log and Tracer data is stored in Elasticsearch |
|
3.
![]() |
Verify Elasticsearch cluster health |
|
4.
![]() |
Verify Prometheus Alert manager is accessible |
|
5.
![]() |
Verify metrics are scraped and stored in prometheus server |
|
6.
![]() |
Verify Alerts are configured |
|
7.
![]() |
Verify grafana is accessible and change the default password for admin user |
|
Post-Installation Security Hardening
Introduction
After installation, the OC-CNE system security stance should be audited prior to placing the system into service. This primarily consists of changing credentials and sequestering SSH keys to trusted servers. The following table lists all the credentials that need to be checked / changed / retained:
Note:
Refer to this section if you are performing bare metal installation.Table 4-2 Credentials
Credential Name | Type | Associated Resource | Initial Setting | Credential Rotation |
---|---|---|---|---|
TOR Switch | username / password | Cisco Top or Rack Switch | username/password from PreFlight Checklist | Reset post-install |
Enclosure Switch | username / password | HP Enclosure Switch | username/password from PreFlight Checklist | Reset post-install |
OA Admin | username / password | HP On-board Administrator Console | username/password from PreFlight Checklist | Reset post-install |
ILO Admin | username / password | HP Integrated Lights Out Manger | username/password from PreFlight Checklist | Reset post-install |
Server Super User (root) | username / password | Server Super User | Set to well-known Oracle default during server installation | Reset post-install |
Server Admin User (admusr) | username / password | Server Admin User | Set to well-known Oracle default during server installation | Reset post-install |
Server Admin User SSH | SSH Key Pair | Server Admin User | Key Pair generated at install time | Can rotate keys at any time; key distribution manual procedure |
MySQL Admin | username / password | MySQL Database | Set by customer during initial install | Reset post-install |
If factory or Oracle defaults were used for any of these credentials, they should be changed prior to placing the system into operation. The customer should then store these credentials in a safe a secure way off site. It is recommended that the customer may plan a regular schedule for updating (rotating) these credentials.
Prerequisites
This procedure is performed after the site has been deployed and prior to placing the site into service.
Limitations and Expectations
The focus of this procedure is to secure the various credentials used or created during the install procedure. There are additional security audits that the CNE operator should perform such as scanning repositories for vulnerabilities, monitoring the system for anomalies, regularly checking security logs. These are outside the scope of this post-installation procedure.References
- Nexus commands to configure Top of Rack switch username and password:https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus9000/sw/6-x/security/configuration/guide/b_Cisco_Nexus_9000_Series_NX-OS_Security_Configuration_Guide/b_Cisco_Nexus_9000_Series_NX-OS_Security_Configuration_Guide_chapter_01001.html
- HP commands to configure Enclosure switch username and password:https://support.hpe.com/hpsc/doc/public/display?docId=c04763521
- HP OA commands to configure OA username and password:https://support.hpe.com/hpsc/doc/public/display?docId=emr_na-a00040582en_us&docLocale=en_US#N101C8
- HP iLO commands to configure iLO username and password:https://www.golinuxhub.com/2018/02/hp-ilo4--cli-guide-cheatsheet-example.html
- See ToR switch procedure for initial username/password configuration: Configure Top of Rack 93180YC-EX Switches
- See procedure to configure initial iLO/OA username/password: Configure Addresses for RMS iLOs, OA, EBIPA
- See Enclosure switch procedure for initial username/password: Configure Enclosure Switches
Procedure
Table 4-3 Post-Installation Security Hardening
Step No. | Procedure | Description |
---|---|---|
1.
|
Reset Credentials on the TOR Switch |
|
2.
|
Reset Credentials on the Enclosure Switch |
|
3.
|
Reset Credentials for the OA Admin Console |
|
4.
|
Reset Credentials for the ILO Admin Console |
|
5.
|
Reset Credentials for the root account on Each and Every Server | Login to each and every server in the
cluster (ssh admusr@cluster_host ) and perform the following command:
|
6.
|
Reset (or Delete) Credentials for the admusr account on Each and Every Server | Login to each and every server in the
cluster (ssh admusr@cluster_host ) and perform the following command:
|
7.
|
Reset Credentials for the MySQL Accounts | See Database Tier Installer for details on how to reset the DB Account Passwords. |
8.
|
Regenerate / Redistribute SSH Keys Credentials for the admusr Account | Log into the Bastion Host VM and generate a
new cluster-wide keypair by perform the following:
Now, for each and every server in the cluster, perform these actions:
At this point, the new key should be usable. Switch from using the old key to the new key, and confirm that each and every cluster host is still reachable. On the Bastion Host VM, perform these actions:
The new private key (new_occne_id_rsa) should also be copied to any secondary Bastion Host VM, and possibly copied off site and securely saved. |