Contents

1   Introduction

This document describes security management for the supported security services in the Cloud Execution Environment (CEE).

The supported security services are as follows:

• Security protocols, algorithms and interfaces used in CEE, as described in Section 2
• Identity and access management, as described in Section 3
• Password policies, as described in Section 3.4
• Privileged access, as described in Section 3.5
• Audit and security logging and monitoring, as described in Section 4
• Network security, as described in Section 5
• Transport Layer Security (TLS) for Atlas dashboard, as described in Section 6
• Vulnerability management, as described in Section 7

Note:  

The security management of EMC² ScaleIO as Cinder back end is out of the scope of this document. Refer to the section about security management of the documents Dell EMC ScaleIO Version 2.x User Guide and Dell EMC ScaleIO Version 2.x Security Configuration Guide for more information.

2   Security Protocols, Algorithms, and Interfaces

CEE uses encryption on public facing interfaces to ensure that no eavesdropping or data alteration happens during transit. OpenStack REST APIs are reachable using HTTPS, data is encrypted on the virtual Cloud Infrastructure Controller (vCIC) nodes before it is sent out to the external network. Data is decrypted on the virtual CICs (vCICs), then the unencrypted data is sent to the internal management network. Low level cloud infrastructure management access uses Secure Shell (SSH) and SFTP protocols.

Atlas is an optional component of CEE. When installed, the Atlas virtual machine (VM) exposes OpenStack endpoints using HTTPS and provides management access through SSH to ensure that management sessions are encrypted.

Control and management interfaces with the relevant protocols are shown in fig-SecurityInterfacesEps Figure 1.

2.1   Interfaces

External interfaces, including the OpenStack standard APIs and OpenStack REST APIs extended by Ericsson, are listed in Table 1.

Internal interfaces are exposed to internal components, and do not have any external network connection.

2.2   Algorithms

Encryption algorithms are listed below.

2.3   Protocols and Encryption

The following protocols are used in CEE:

• SSH2 (OpenSSH 6.4p): used for Atlas and vCIC CLIs (CEE-AT-CLI, CEE-CIC-CLI)
• SNMPv2: used for fault management (CEE-FM-1)
• RELP: used for log collection (CEE-SL)
• TCP: used for external logging
• HTTPS (HTTP over TLSv1.2; where TLS is implemented by OpenSSL 1.0.1): used for all other communication
• Network File System (NFS): used for the cinder-backup service
• TLS: used for license management

Note:  

Communication using LDAP, SNMP, NFS and RELP protocols is not encrypted in CEE.

For more information about RELP encryption, refer to section SBI and SIEM Configuration in Audit and Security Logging.

The NFS protocol is recommended to be used only together with Kerberos v5 network authentication, which provides secure authentication and can be used for data integrity and encryption of the NFS traffic. However, this CEE release does not support Kerberos, thus CEE nodes cannot communicate with external Kerberos servers. For this reason, secure communication between the CEE region and external storage back ends (for example, NFS) requires system integration (SI) activity and is outside the scope of this document. Using NFSv3 (or NFSv4 without data encryption) is not recommended unless the communication channel is secured. In CEE, volumes are not encrypted. Encryption of the transferred data is the responsibility of the user.

3   Identity and Access Management

The purpose of the CEE Identity and Access Management (IdAM) tool is to manage identities and credentials for cloud users, and to provide authentication and access control services for user accesses.

The IdAM architecture in CEE is shown in fig-IdAM-Architecture_new_eps Figure 2.

Note:  

ScaleIO administrator users are not managed by IdAM. For more information, refer to the Dell EMC ScaleIO Version 2.x Security Configuration Guide.

Managed Areas

CEE IdAM can be used to manage the following:

• Users, see Section 3.1
• LDAP groups, see Section 3.2
• Passwords, see Section 3.3
• Password policies, see Section 3.4
• Privileged access, see Section 3.5

Configuration

CEE IdAM uses internal default configuration options, or configuration parameters stored in the cee-idam.conf file under /etc/cee-idam/, or both. The initial configuration files are created during installation with parameter values collected from the config.yaml file.

The IdAM section of the config.yaml file has the following main sections:

• ldap
• userlist
• user

For an example of the default configuration options of the idam section of config.yaml, see Section 10.

For more information about IdAM configuration, refer to the Configuration File Guide.

For more information about the CEE IdAM tool, refer to the Infrastructure Administrator Management Guide.

For a functional description of IdAM components, refer to CEE Technical Description.

3.1   Main User Types

The CEE IdAM tool differentiates between the following user types:

• Cloud Infrastructure administrators, see Section 3.1.1
• Local administrators, see Section 3.1.2

  Note:  

  Extreme switches do not support the Lightweight Directory Access Protocol (LDAP), so local users are used for administrative purposes.

  CSC users are not integrated with IdAM. For more information about these users, refer to the below Software Defined Networking (SDN) documents:

  • Security User Guide, Reference [3]
  • Cloud SDN Hardening Guideline, Reference [2]

  
  

OpenStack users are managed by default Keystone and Dashboard operations, not by the CEE IdAM tool, see Section 3.1.3.

3.1.1   Cloud Infrastructure Administrators

Cloud infrastructure administrators (for example ceeadm) manage certain CEE infrastructure components, such as hypervisor blades, network switches, virtual Cloud Infrastructure Controllers (vCICs), and the storage system.

Note:  

Linux users and network device users (Extreme switches) are considered to be infrastructure users.

The cloud infrastructure administrator accounts are stored on a LDAP server that acts as a centralized IdAM repository for CEE. It supports the provisioning and authentication for ceeadm, ensuring that only authorized entities are allowed to access the resources, in line with the defined security policies. When trying to access an infrastructure component, the credentials of the user are verified against the credentials stored in the LDAP server.

3.1.2   Local Administrators

In case the system needs to be accessed by either a user or a service when LDAP is not available, initial local accounts are predefined. For security and personal accountability reasons, the use of root must be limited.

On CEE nodes atlasadm and cmha users are created and SSH-keys are distributed for them. These users belong to user groups that have sudo permissions without passwords, and access defined from each vCIC to all other nodes. For more information about sudo user groups, see Section 3.5.

On vCICs ceebackup user is created for backup and restore, and ceecore for crash and core management.

Predefined Local Administrators

3.1.3   Manage OpenStack Cloud Users

OpenStack users are managed by the default Keystone and dashboard operations.

Note:  

OpenStack services (apart from Cinder) are only configured with internal management VIP addresses. Therefore, Keystone returns the internal OS_AUTH_URL address in case of external authentication requests.

OpenStack administrators (openstack-admin) are consumers of CEE resources exposed through OpenStack services. OpenStack administrators manage OpenStack domains, tenants (projects), users, roles, services, and images. After installation, the identity admin is automatically created and is a member of this group. Keystone acts as an authentication server for openstack-admin, using a local SQL database in CEE as a back end for the identities.

OpenStack users are able to provision their own resources within the limits set by the openstack-admin.

Note:  

There is no automatically created OpenStack user after installation.

For more information about OpenStack cloud users, refer to the OpenStack Identity API and the OpenStack Administrator Guide.

3.1.4   ScaleIO User Management

ScaleIO user management is described in section ScaleIO Access Control in the System Hardening Guideline.

3.1.5   BSP User Management

BSP user management is described in BSP User Management, Reference [1].

3.1.6   NeLS User Management

Network License Server (NeLS) user management is described in the System Hardening Guideline.

3.2   LDAP Groups

Table 3 shows the predefined LDAP groups. These groups are automatically created during the installation.

Note:  

For more information about CSC users, refer to the below SDN documents:

• Security User Guide, Reference [3]
• Cloud SDN Hardening Guideline, Reference [2]

3.3   Passwords

3.3.1   Change Password for root

Root user must not be used directly after the initial installation of the system. The nodes cannot be directly accessed with the root user, but passwordless access to the node can be done with SSH from the vFuel node. The vFuel node is used for system deployment and upgrades, and it is strongly recommended to change the root password after installation, or whenever the current password has been used to access the system.

Note:  

The password of local users can remain unchanged on nodes which are offline during the password change.

The root password in all deployed CEE nodes can be changed using the following methods:

Using passwd

For setting the root password locally on vFuel, the passwd CLI command can also be used.

If the passwd command is used, the root password in vFuel does not propagate to other nodes and so must be changed manually for each node.

Using idamsetup

If idamsetup is used, the root password is set for each newly deployed node.

Passwordless sudo privileges are required, see Section 11.2.

Do the following on vFuel:

1. Create a new password that fulfills the strong password conditions described in the System Hardening Guideline
2. Write the new password to a file set with restricted permissions so that it is not readable to other users (for example, 0600)
3. Change the password:

   idamsetup -u root -c <credentials_file>

   where <credentials_file> is the name of the new password file.

Note:  

The direct inclusion of the password in the command (idamsetup -u root -p <password>) is not recommended. For more information, see Section 11.2

3.3.2   Change Credentials for Predefined Users

Credentials for predefined users can be changed using the following commands:

• passwd
• idamsetup

The command passwd has to be used to change the password of ceeadm and additional accounts created with the cee-idam tool.For more information on passwd, see Section 11.1.

Other passwords and SSH keys of local predefined users in all deployed CEE nodes including the Fuel system can be changed using the idamsetup script in the vFuel node. For more information on idamsetup, see Section 11.2.

Use idamsetup to manage the SSH key and passwords of the following predefined users:

• ceeadm, see Section 3.3.2.4
• ceebackup, see Section 3.3.2.1
• ceecoreSection 3.3.2.2
• cmhaSection 3.3.2.3

3.3.2.1   Changing SSH Keypair and Password for ceebackup

This procedure changes the password of the ceebackup user on vFuel and on the vCICs. Also, a new SSH keypair is created. The private key is distributed to the vCICs, and the public key is installed on all nodes of the region.

Do the following on vFuel:

1. Create a new password that fulfills the strong password conditions described in the System Hardening Guideline
2. Write the new password to a file set with restricted permissions so that it is not readable to other users (for example, 0600)
3. Execute the following command:

   idamsetup -u ceebackup -r root -c <credentials_file>

   where <credentials_file> is the name of the new password file.

3.3.2.2   Changing SSH Keypair for ceecore

This procedure creates a new SSH keypair for the ceebackup user. The private key is distributed to the vCICs, and the public key is installed on all nodes of the region.

Passwordless sudo privileges are required, see Section 11.2.

Execute the following command on vFuel:

idamsetup -u ceecore -r root

3.3.2.3   Changing SSH Keypair for cmha

This procedure creates a new SSH keypair for the cmha user. The private key is distributed to the vCICs, and the public key is installed on all nodes of the region.

Passwordless sudo privileges are required, see Section 11.2.

Execute the following command on vFuel:

idamsetup -u cmha -r root

3.3.2.4   Changing SSH Keypair for ceeadm

This procedure creates a new SSH keypair for the ceebackup user. The private key is distributed to the vCICs, and the public key is installed on all nodes of the region.

Passwordless sudo privileges are required, see Section 11.2.

Execute the following command on vFuel:

idamsetup -u ceeadm -r root

3.3.3   Change Password for OpenStack Administrator

OpenStack identity (Keystone) is deployed in CEE as two separate instances, and both have their own admin users:

For detailed information on passwords refer to sections Initial System and User Accounts and Strong Password Conditions in the System Hardening Guideline.

3.3.3.1   Change vFuel Admin Password

To change the password of the vFuel admin:

1. Log on to the vFuel node and change the admin password:

   fuel user change-password

2. Update the /etc/fuel/astute.yaml by changing FUEL_ACCESS.password:

        "FUEL_ACCESS":
          "password": "admin"
          "user": "admin"

3. Update the tag OS_PASSWORD in /root/.config/fuel/fuel_client.yaml using a suitable editor, for example, vi:

   OS_PASSWORD: "<new_password>"

   Example:

   # cat /root/.config/fuel/fuel_client.yaml 
   
   SERVER_ADDRESS: "192.168.0.11"
   SERVER_PORT: "8000"
   OS_USERNAME: "admin"
   OS_PASSWORD: "admin"
   OS_TENANT_NAME: "admin"
   KEYSTONE_PORT: "5000"
   

3.3.3.2   Change Cloud Admin Password

To change the password of the cloud (vCIC) admin:

1. Log on to the vFuel node and check the number of environments that are defined, using the command fuel env.

   If there are multiple environments, note down the relevant environment ID (<environment_number>).

   Note:  

   As vFuel manages one CEE deployment, the <environment_number> value is set to 1 in most deployments.

   
   
2. Print a list of the current environment variables for the relevant environment:

   fuel env --env <environment_number> --attributes --download

   fuel env --env <environment_number>⇒ --attributes --download

   Example:

   fuel env --env 1 --attributes --download

3. Update ./cluster_<environment_number>/attributes.yaml: change the cloud admin password in the editable.access.password field.

   editable.access.password.value is used to describe the actual key in the YAML hierarchy, as shown below.

   Note:  

   Use single quotation marks, in the format '<password>', to allow special characters in the password.

   
   

   ./cluster_1/attributes.yaml
   
   editable:
     access:
       email:
         description: Email address for Administrator
         label: Email
         regex:
           error: Invalid email
           source: ^\S+@\S+$
         type: text
         value: admin@localhost
         weight: 40
       metadata:
         group: general
         label: OpenStack Access
         weight: 10
       password:
         description: Password for Administrator
         label: Password
         regex:
           error: Empty password
           source: \S
         type: password
         value: 'admin'
         weight: 20
   

4. Execute the below command to upload the attributes:

   fuel env --env <environment_number> --attributes --upload

   fuel env --env <environment_number>⇒ --attributes --upload

5. Propagate the change to vCICs manually:
   1. Log on to one of the vCICs as root user:

      ssh root@cic-<x>

   2. Source the environment file:

      source openrc

   3. Update the password in the vCIC identity database by using one of the following options:
      • In Keystone, use the following command:

        keystone user-password-update --pass '<new_password>' admin

        keystone user-password-update ⇒
        --pass '<new_password>' admin

        Similar warnings in printout can be ignored:

        /usr/lib/python2.7/site-packages/keystoneclient/shell.py:64: DeprecationWarning: The keystone CLI ⇒ is deprecated in favor of python-openstackclient. For a Python library, continue using ⇒ python-keystoneclient. 'python-keystoneclient.', DeprecationWarning) /usr/lib/python2.7/site-packages/keystoneclient/v2_0/client.py:145: DeprecationWarning: Constructing ⇒ an instance of the keystoneclient.v2_0.client.Client class without a session is deprecated as of the ⇒ 1.7.0 release and may be removed in the 2.0.0 release. 'the 2.0.0 release.', DeprecationWarning) /usr/lib/python2.7/site-packages/keystoneclient/v2_0/client.py:147: DeprecationWarning: Using the ⇒ 'tenant_name' argument is deprecated in version '1.7.0' and will be removed in version '2.0.0', ⇒ please use the 'project_name' argument instead super(Client, self).__init__(**kwargs) /usr/lib/python2.7/site-packages/debtcollector/renames.py:45: DeprecationWarning: Using the ⇒ 'tenant_id' argument is deprecated in version '1.7.0' and will be removed in version '2.0.0', ⇒ please use the 'project_id' argument instead return f(*args, **kwargs) /usr/lib/python2.7/site-packages/keystoneclient/httpclient.py:371: DeprecationWarning: ⇒ Constructing an HTTPClient instance without using a session is deprecated as of the 1.7.0 ⇒ release and may be removed in the 2.0.0 release. 'the 2.0.0 release.', DeprecationWarning) /usr/lib/python2.7/site-packages/keystoneclient/session.py:145: DeprecationWarning: ⇒ keystoneclient.session.Session is deprecated as of the 2.1.0 release in favor of ⇒ keystoneauth1.session.Session. It will be removed in future releases. DeprecationWarning) /usr/lib/python2.7/site-packages/keystoneclient/auth/identity/base.py:56: DeprecationWarning: ⇒ keystoneclient auth plugins are deprecated as of the 2.1.0 release in favor of keystoneauth1 ⇒ plugins. They will be removed in future releases. 'in future releases.', DeprecationWarning)

      • In the OpenStack CLI use the following command:

        openstack user set --password '<new_password>' admin

        openstack user set --password ⇒
        '<new_password>' admin

        The change is done even if a similar output is printed: The request you have made requires authentication. (HTTP 401) (Request-ID: req-d4bd8529-bea3-48ec-94cc-06aaad5b00e7).

      • Use the Atlas web UI, as described in the OpenStack Horizon documentation, Reference [5], or use the Atlas CLI as described in section Change password for user in the OpenStack Identity API in CEE.

      Note:  

      Perform the below steps after every update or redeployment, because manual changes are overwritten during the deployment procedure.

      
      
   4. In all vCICs, edit /root/openrc.

      Note:  

      To allow special characters in the password, use single quotation marks, in the format '<password>'.

      
      
   5. In all vCICs, change the admin_password in the file /etc/pmapi/pmapi.conf.
   6. In one of the vCICs, restart PMAPI with the below command:

      crm resource restart clone_p_pmapi

   7. Update the password in /etc/atlasrc.
6. On Atlas, update /home/atlasadm/openrc.

   If the file is owned by root, change the owner to atlasadm and 0600.

3.3.4   Change Password for CSC Administrator

To change the cscadm password, perform the following steps:

1. Change the cscadm by following the procedure described in section Changing CSC Interfaces Users Passwords of the Cloud SDN Hardening Guideline, Reference [2].
2. Continue with Section 3.3.4.1 to propagate the CSC password in the CEE region.

3.3.4.1   Propagate CSC Password in CEE

To propagate the changed cscadm password in CEE, perform the following steps:

1. Update the cscadm user password in the ericsson_sdnc Fuel plugin setting in /mnt/cee_config/config.yaml:

       -
          name: ericsson_sdnc
          config_attributes:
             as_num: '100'
             odl_username: 'cscadm'
             odl_password: <NEW_PASSWORD>
   

2. Update the cscadm user password under sdnc_admin_password in /mnt/cee_config/config.yaml:

     sdn:
       sdnc_admin_username: cscadm
       sdnc_admin_password: <NEW_PASSWORD>
   

3. Update the cscadm user password in Atlas on each vCIC:
   1. Log on to the vCIC.
   2. Update the cscadm user password in Atlas /etc/atlasrc:

      readonly SDNC_USERNAME=cscadm
      readonly SDNC_PASSWORD=<new_password>

4. Update the cscadm user password in /opt/sdnc/opendaylight/karaf_featureInstall.sh on each vCIC:
   1. Log on to the vCIC.
   2. Update the cscadm user password in the /opt/sdnc/opendaylight/karaf_featureInstall.sh file:

      result=$(sshpass -p '<new_password>' ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -p 8101 $USER_ODL@localhost $1)

      result=$(sshpass -p '<new_password>' ssh -o ⇒
      UserKnownHostsFile=/dev/null -o ⇒
      StrictHostKeyChecking=no -p 8101 ⇒
      $USER_ODL@localhost $1)

5. Validate the new configuration in vFuel:
   1. Log on to vFuel.
   2. Retrieve the environment ID from the printout of the following command:

      fuel env

   3. Apply the new configuration:

      apply_settings /var/lib/ericsson/pre_deploy/ /mnt/cee_config/config.yaml <env_id> update /etc/cee/eri_deployment_tasks.yaml /etc/cee/repos.yaml

      apply_settings /var/lib/ericsson/pre_deploy/ ⇒
      /mnt/cee_config/config.yaml <env_id> ⇒
      update /etc/cee/eri_deployment_tasks.yaml ⇒
      /etc/cee/repos.yaml

   4. Update the deployment files with the new Fuel plugin information:

      pre_deploy /var/lib/ericsson/pre_deploy/ /mnt/cee_config/config.yaml <env_id> /etc/cee/openstack_config/

      pre_deploy /var/lib/ericsson/pre_deploy/ ⇒
      /mnt/cee_config/config.yaml <env_id> ⇒
      /etc/cee/openstack_config/

   5. Run the fuel node task for every node in the CEE region:

      fuel node --node <node_ids> --tasks upload_configuration

      fuel node --node <node_ids> ⇒
      --tasks upload_configuration

      The node IDs are acquired from the printout of the fuel node command.

6. Change the password in the Neutron configuration on each vCIC:
   1. Log on to the vCIC.
   2. Change the password in the /etc/neutron/plugins/ml2/ml2_conf.ini file:

      [ml2_odl]
      password = <new_password>
      

7. Restart the Neutron server:

   crm resource restart clone_neutron-server

8. If the SDN counters (sdn_counters) are disabled in the ericsson_openstack_config section in config.yaml, skip to Step 11.

   If the SDN counters are enabled, continue with the next step to update Ceilometer.

9. Update the CSC password in Ceilometer on all vCICs:
   1. Log on to a vCIC.
   2. Update the /etc/ceilometer/pipeline.yaml file:

      ericsson.opendaylight://192.168.2.28:8383/controller/statistics?auth=basic&user=cscadm&password=<new_password>&scheme=http

   3. Restart the ceilometer-agent-central service:

      crm resource restart p_ceilometer-agent-central

   4. Restart the Ceilometer services:

      service ceilometer-agent-notification restart
      service ceilometer-api restart
      service ceilometer-collector restart
      service ceilometer-polling restart

10. Update Ceilometer on all compute hosts:
    1. Log on to a compute host.
    2. Update the /etc/ceilometer/pipeline.yaml file:

       ericsson.opendaylight://192.168.2.28:8383/controller/statistics?auth=basic&user=cscadm&password=<new_password>&scheme=http

    3. Restart the ceilometer-polling service:

       service ceilometer-polling restart

11. The procedure is complete.

3.3.5   Distribute SSH-keys for Personal Accounts

Individual users do not have any individual SSH-keys generated. Each user must create their own SSH-key pairs. SSH public keys are fetched from LDAP. The cee-idam tool can be used to store the keys in LDAP.

3.4   Password Policies

CEE supports the use of password policies for users provisioned in the LDAP user repository.

It is also possible to map policies to a user by using the CEE IdAM tool. The policy name to be used is provided either when the user is created or when the user is modified. By default, the Standard policy is applied, when no other policy is set.

For more information, refer to the Infrastructure Administrator Management Guide.

3.5   Privileged Access

Users are granted privileged access through sudo. sudo privileges are available for users who are members of one of the sudo groups. Users can be added to various sudo user groups.

Local and LDAP user groups are listed in Table 4.

(1)  In maintenance mode (MM) only local user groups can be used.

For information about how to manage sudo groups, refer to Infrastructure Administrator Management Guide.

4   Security and Audit Trail Logging

CEE offers a logging service by which security- and audit trail-related events are logged into a central log collector residing inside the Atlas VM, using Reliable Event Logging Protocol (RELP).

4.1   Logging Service Architecture

The logging service architecture is shown in fig_logging_service_eps Figure 3.

The logging service consists of the following components:

4.2   Log Types

The following logs are created by the logging service:

fuel node --node <node_ids> --tasks eri_rsyslog_common eri_rsyslog_configuration eri_audit_logging_configuration --force

fuel node --node <node_ids> --tasks ⇒
eri_rsyslog_common eri⇒
_rsyslog_configuration eri⇒
_audit_logging_configuration --force

4.3   Configure SIEM

The audit events received by the Log Collector can be forwarded to an arbitrary number of SIEM systems for further analysis and correlation. The supported protocols for forwarding events are RELP and syslog over TCP.

For information about configuring SIEM refer to Security Information and Event Management.

5   Network Security

In CEE, the Data Center Firewall (DC-FW) provides protection for the system. The DC-FW also acts as an O&M firewall.

The DC-FW is located outside CEE. For the connectivity and network description of the DC-FW refer to the DC Firewall Hardening Guide and System Hardening Guideline.

For algorithms used in CEE, see Section 2.

Note:  

These algorithms cannot be found in the config.yaml as they are not configurable.

6   Transport Layer Security

Transport Layer Security (TLS) provides the mechanisms to ensure authentication, non-repudiation, confidentiality, and integrity of user communications for the CEE services.

Secure TLS communication is supported for the OpenStack service and CSC endpoints through the northbound interface.

For settings, refer to SW Installation in Multi-Server Deployment or SW Installation in Single Server Deployment, and the Configuration File Guide.

7   Vulnerability Management

The Ericsson Product Security Incident Response Team (PSIRT) provides a vulnerability monitoring service in order to reduce the risk of system security incidents. PSIRT constantly monitors various vulnerability information sources to sustain an up-to-date understanding of current vulnerabilities. If a new vulnerability potentially affects Ericsson products or solutions, PSIRT notifies the impacted product responsible, who then can act on the reported vulnerabilities. Within CEE, security fixes are merged into the CEE software by normal software upgrade procedures. For information about the upgrade of Atlas software, refer to Atlas SW Upgrade.

For more information about CEE software upgrade refer to CEE Update and Rollback Guide.

8   Privacy

A variety of applications could be running on CEE processing the personal data of subscribers, however such data is not known, and cannot be managed by CEE directly. These applications that utilize CEE may affect subscriber privacy. Their impact on privacy is generally to be considered not under the control of CEE.

CEE provides security controls for applications in VMs that process personal data. It is the responsibility of each application to deploy those controls appropriately to protect subscribers personal data and mitigate any possible privacy impact.

9   Services, Ports, and Protocols

All open ports and services running on the CEE nodes, that is, vCICs, compute nodes with host OS, and Atlas dashboard are listed in this section.

Note:  

• The Process ID (PID) values listed are provided as an example only. The actual PID value is assigned when the process is created and varies over time and between systems.
• Some of these ports can be blocked by the DC-FW, so although they are open, they might not be reachable from outside of the system.

Namespaces

The namespaces global, haproxy, and vrouter are used by applications. There are additional namespaces defined on the vCICs. For the full list enter the command:

ip netns

IP Allocation

Two distinct networks are used for OpenStack services:

• br-ex interface is used by the external network
• br-mgmt interface is used by the internal network

The IP allocation for these services is as follows:

# ip a s br-ex
14: br-ex: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc ⇒
noqueue state UNKNOWN group default
    link/ether ee:f6:ba:31:f4:46 brd ff:ff:ff:ff:ff:ff
    inet 10.20.100.4/24 brd 10.20.100.255 scope global br-ex
       valid_lft forever preferred_lft forever

# ip a s br-mgmt
20: br-mgmt: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc ⇒
noqueue state UNKNOWN group default 
    link/ether c6:ad:eb:08:9a:42 brd ff:ff:ff:ff:ff:ff
    inet 192.168.2.23/25 brd 192.168.2.127 scope global br-mgmt
       valid_lft forever preferred_lft forever

Additionally, pacemaker also manages virtual IP (VIP) addresses. The list of VIPs and where they are defined can be listed as follows:

# crm status
vip__management        (ocf::fuel:ns_IPaddr2): Started ⇒
cic-1.domain.tld
vip__vrouter_pub       (ocf::fuel:ns_IPaddr2): Started ⇒
cic-1.domain.tld
vip__vrouter   (ocf::fuel:ns_IPaddr2): Started cic-1.⇒
domain.tld
vip__public    (ocf::fuel:ns_IPaddr2): Started cic-1.⇒
domain.tld
vip__zbx_vip_mgmt      (ocf::fuel:ns_IPaddr2): Started ⇒
cic-1.domain.tld

These VIP addresses are defined either in the haproxy or in the vrouter namespace as follows:

# ip netns exec haproxy ip a s
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state ⇒
UNKNOWN group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
31: hapr-ns: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc ⇒
pfifo_fast state UP group default qlen 1000
    link/ether 4e:77:eb:d7:df:ba brd ff:ff:ff:ff:ff:ff
    inet 240.0.0.2/30 scope global hapr-ns
       valid_lft forever preferred_lft forever
    inet6 fe80::4c77:ebff:fed7:dfba/64 scope link 
       valid_lft forever preferred_lft forever
35: b_public: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc ⇒
pfifo_fast state UP group default qlen 1000
    link/ether da:33:42:22:7e:73 brd ff:ff:ff:ff:ff:ff
    inet 10.20.100.3/24 scope global b_public
       valid_lft forever preferred_lft forever
    inet6 fe80::d833:42ff:fe22:7e73/64 scope link 
       valid_lft forever preferred_lft forever
37: b_management: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 ⇒
qdisc pfifo_fast state UP group default qlen 1000
    link/ether 2a:60:b2:d7:73:a1 brd ff:ff:ff:ff:ff:ff
    inet 192.168.2.21/25 scope global b_management
       valid_lft forever preferred_lft forever
    inet6 fe80::2860:b2ff:fed7:73a1/64 scope link 
       valid_lft forever preferred_lft forever
39: b_zbx_vip_mgmt: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 ⇒
qdisc pfifo_fast state UP group default qlen 1000
    link/ether 22:6e:f3:37:df:3a brd ff:ff:ff:ff:ff:ff
    inet 192.168.2.22/25 scope global b_zbx_vip_mgmt
       valid_lft forever preferred_lft forever
    inet6 fe80::206e:f3ff:fe37:df3a/64 scope link 
       valid_lft forever preferred_lft forever

# ip netns exec vrouter ip a s
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state ⇒
UNKNOWN group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
23: vr-host-ns: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 ⇒
qdisc pfifo_fast state UP group default qlen 1000
    link/ether e2:46:cf:f5:d6:d9 brd ff:ff:ff:ff:ff:ff
    inet 240.0.0.6/30 scope global vr-host-ns
       valid_lft forever preferred_lft forever
    inet6 fe80::e046:cfff:fef5:d6d9/64 scope link 
       valid_lft forever preferred_lft forever
33: conntrd: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc ⇒
pfifo_fast state UP group default qlen 1000
    link/ether 12:37:ce:a5:c1:c9 brd ff:ff:ff:ff:ff:ff
    inet 240.1.0.23/24 scope global conntrd
       valid_lft forever preferred_lft forever
    inet6 fe80::1037:ceff:fea5:c1c9/64 scope link 
       valid_lft forever preferred_lft forever
45: b_vrouter: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 ⇒
qdisc pfifo_fast state UP group default qlen 1000
    link/ether 96:fb:c8:42:4f:0f brd ff:ff:ff:ff:ff:ff
    inet 192.168.2.20/25 scope global b_vrouter
       valid_lft forever preferred_lft forever
    inet6 fe80::94fb:c8ff:fe42:4f0f/64 scope link 
       valid_lft forever preferred_lft forever
47: b_vrouter_pub: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 ⇒
qdisc pfifo_fast state UP group default qlen 1000
    link/ether 12:ee:ca:b2:e2:4e brd ff:ff:ff:ff:ff:ff
    inet 10.20.100.2/24 scope global b_vrouter_pub
       valid_lft forever preferred_lft forever
    inet6 fe80::10ee:caff:feb2:e24e/64 scope link 
       valid_lft forever preferred_lft forever

The nodes (for example compute, Cinder, vCIC nodes) are the first to be assigned IP addresses from the range, followed by the VIP addresses. As such, the VIP address allocation is site-specific, depending on the blade IP allocation.

Reachable Services

The tools netstat and lsof are used to report where services are bound.

The following services are reachable from the public network on a vCIC:

(1)  The Linux networking stack allows accepting IPv4 connections on IPv6 sockets, so the presence of an IPv6 listener implies IPv4 connectivity.

The following services are reachable from the public network on a compute host:

(1)  The Linux networking stack allows accepting IPv4 connections on IPv6 sockets, so the presence of an IPv6 listener implies IPv4 connectivity.

The following services are reachable from the public network on vFuel:

The following services are reachable from the public network on Atlas:

(1)  The Linux networking stack allows accepting IPv4 connections on IPv6 sockets, so the presence of an IPv6 listener implies IPv4 connectivity.

The following services are reachable from the public network on ScaleIO nodes:

For the mapping between port number and service name, refer to the System Hardening Guideline.

TCP Ports Used

The list of TCP ports used are shown in Table 10.

Note:  

For the list of TCP ports in SDN, refer to the following SDN documents:

• Section Interfaces, Ports, and Protocols in the Security User Guide,
• Section Port Filtering with IPv4 Tables in the Cloud SDN Hardening Guideline, Reference [2]

(1)  In apache and haproxy, clients are automatically redirected to HTTPS port 443.

UDP Ports Used

The list of UDP ports used are shown in Table 11.

Note:  

Dynamic ports can change.

10   Example Configuration for IdAM

This output is an example of an IdAM configuration in the config.yaml file.

Note:  

The content of the config.yaml file can be changed at installation time. For details about config.yaml refer to Configuration File Guide.

ericsson:
  idam:
    ldap:
      basedn: dc=cee,dc=ericsson,dc=com
      rootdn: cn=admin
      rootpw: ''
      anonymous_binddn: cn=anon
      anonymous_bindpwd: ''
      manager_binddn: cn=ldapadmin
      manager_bindpwd: ''
      sync_binddn: cn=repl
      sync_bindpwd: ''
    userlist:
    - ceeadm
    - cmha
    - ceebackup
    - ceecore
    users:
      ceebackup:
        idam_tag:
        - admin
        passwd: 'n}Z:1+#-=_$@'
      ceeadm:
        idam_tag:
        - none
        passwd: 'GT$dS4mEP\#E'
        openstack_access:
          os_tenant: admin
          os_create_account: false
          os_password: admin
          os_username: admin
          os_role: admin
      cmha:
        idam_tag:
        - none
      ceecore:
        idam_tag:
        - none

Appendix

11   Command Descriptions

11.1   passwd

Syntax

passwd <username>

Description

The command passwd has to be used to change the password of ceeadm and additional accounts created with the cee-idam tool

The password has to be changed both on vFuel and on one of the vCICs, as the password change does not propagate automatically.

Examples

The following is an example of the execution of the command on vFuel for changing the password of the ceeadm user:

 [root@fuel ~]# passwd ceeadm
 Changing password for user ceeadm.
 New password:
 Retype new password:
 passwd: all authentication tokens updated successfully.

The following is an example of the execution of the command on vCIC for changing the password of the ceeadm user:

 root@cic-1:~# passwd ceeadm
 New password:
 Retype new password:
 LDAP password information changed for ceeadm
 passwd: password updated successfully

11.2   idamsetup

Syntax

idamsetup -u <username> [ -r <remote_user> ] [ -p <password> ] [ -c <credentials_file> ] [ -e <environment_id> ] [-v] [-f]

idamsetup -u <username> [ -r <remote_user> ] [ -p <password> ]⇒
 [ -c <credentials_file> ] [ -e <environment_id> ] [-v] [-f]

Description

This command can be issued on vFuel.

This command requires root privileges, so it must be executed as a user with passwordless sudo privileges of vFuel and the remote nodes , or as root user if no other users exist.

Optional Arguments

(1)  Passing passwords as command arguments can lead to information disclosure and is therefore not recommended. The use of credentials files is recommended instead.

(2)  Multi-region deployment is not possible in this CEE release.

Reference List