Manage Security

• 1: Security Overview
• 2: Best Practices
• 2.1: Authentication and Access Control Best Practices
• 2.2: Hosts
• 2.3: Images and Instances
• 2.4: Management Console
• 2.5: Message Security
• 2.6: Networking Modes
• 3: Security Tasks
• 3.1: Configure SSL
• 3.1.1: Configure and Enable SSL for the Management Console
• 3.1.2: Configure and Enable SSL for the UFS
• 3.2: Change Multicast Address
• 3.3: Configure Replay Protection
• 3.4: Configure Session Timeouts
• 3.5: Configure STS Actions
• 3.6: Configure the Firewall
• 3.7: Reserve Ports
• 3.8: Synchronize Components

1 - Security Overview

This topic is intended for people who are currently using Eucalyptus and who want to harden the cloud and underlying configuration.

This topic covers available controls and best practices for securing your Eucalyptus cloud. Cloud security depends on security across many layers of infrastructure and technology:

• Security of the physical infrastructure and hosts
• Security of the virtual infrastructure
• Security of instances
• Security of storage and data
• Security of users and accounts

2 - Best Practices

Best Practices

This topic contains recommendations for hardening your Eucalyptus cloud.

2.1 - Authentication and Access Control Best Practices

This topic describes best practices for Identity and Access Management and the account.

Identity and Access Management

Eucalyptus manages access control through an authentication, authorization, and accounting system. This system manages user identities, enforces access controls over resources, and provides reporting on resource usage as a basis for auditing and managing cloud activities. The user identity organizational model and the scheme of authorizations used to access resources are based on and compatible with the AWS Identity and Access Management (IAM) system, with some Eucalyptus extensions provided that support ease-of-use in a private cloud environment.

For a general introduction to IAM in Eucalyptus, see Access Concepts in the IAM Guide. For information about using IAM quotas to enforce limits on resource usage by users and accounts in Eucalyptus, see the Quotas section in the IAM Guide.

The Amazon Web Services IAM Best Practices are also generally applicable to Eucalyptus.

Credential Management

Protection and careful management of user credentials (passwords, access keys, X.509 certificates, and key pairs) is critical to cloud security. When dealing with credentials, we recommend:

• Limit the number of active credentials and do not create more credentials than needed.
• Only create users and credentials for the interfaces that you will actually use. For example, if a user is only going to use the Management Console, do not create credentials access keys for that user.
• Use and or to get a specific set of credentials if needed.
• Regularly check for active credentials using commands and remove unused credentials. Ideally, only one pair of active credentials should be available at any time.
• Rotate credentials regularly and delete old credentials as soon as possible. Credentials can be created and deleted using commands, such as and .
• When rotating credentials, there is an option to deactivate, instead of removing, existing access/secret keys and X.509 certificates. Requests made using deactivated credentials will not be accepted, but the credentials remain in the Eucalyptus database and can be restored if needed. You can deactivate credentials using and .

Privileged Roles

The eucalyptus account is a super-privileged account in Eucalyptus. It has access to all cloud resources, cloud setup, and management. The users within this account do not obey IAM policies and compromised credentials can result in a complete cloud compromisation that is not easy to contain. We recommend limiting the use of this account and associated users’ credentials as much as possible.

For all unprivileged operations, use regular accounts. If you require super-privileged access (for example, management of resources across accounts and cloud setup administration), we recommend that you use one of the predefined privileged roles.

The Account, Infrastructure, and Resource Administrator roles provide a more secure way to gain super privileges in the cloud. Credentials returned by an assume-role operation are short-lived (unlike regular user credentials). Privileges available to each role are limited in scope and can be revoked easily by modifying the trust or access policy for the role.

2.2 - Hosts

This topic describes best practices for machines that host a Eucalyptus component.Eucalyptus recommends restricting physical and network access to all hosts comprising the Eucalyptus cloud, and disabling unused applications and ports on all machines used in your cloud.

After installation, no local access to Eucalyptus component hosts is required for normal cloud operations and all normal cloud operations can be done over remote web service APIs.

The user-facing services (UFS) and object storage gateway (OSG) are the only two components that generally expect remote connections from end users. Each Eucalyptus component can be put behind a firewall following the list of open ports and connectivity requirements described in the Configure the Firewall section.

For more information on securing Red Hat hosts, see the Red Hat Enterprise Linux Security Guide .

2.3 - Images and Instances

Because all instances are based on images, creating a secure image helps to create secure instances. This topic lists best practices that will add additional security during image creation. As a general rule, harden your images similar to how you would harden your physical servers.

• Turn off password-based authentication by specifying the following option in :
• Encourage non-root access by providing an unprivileged user account. If necessary, use sudo to allow access to privileged commands
• Always delete the shell history and any other potentially sensitive information before bundling. If you attempt more than one bundle upload in the same image, the shell history contains your secret access key.
• Bundling a running instance requires your private key and X.509 certificate. Put these and other credentials in a location that is not bundled (e.g. when using , pass the folder location where the certificates are stored as part of the values for the option). AWS provides more in-depth information on .
• Consider installing in the image to help control root and non-root access. If cloud-init isn’t available, a custom script can be used.
• Consider using a tool such as zerofree to zero-out any unused space on the image.
• Consider editing to clear out the swap every time the instance is booted. This can be done using the following command:
• Consider enabling or for your images
• Disable all unused services and ports on the image.
• By default, all images registered have private launch permissions. Consider using to limit the accounts that can access the image. After locking down the image using the steps above, additional steps can be done to further secure instances started from that image. For example, restrict access to the instance by allowing only trusted hosts or networks to access ports on your instances. You can control access to instances using euca-authorize and euca-revoke .

Consider creating one security group that allows external logins and keep the remainder of your instances in a group that does not allow external logins. Review the rules in your security groups regularly, and ensure that you apply the principle of least privilege: only open up permissions as they are required. Use different security groups to deal with instances that have different security requirements.

2.4 - Management Console

This topic describes things you can do to secure the Eucalyptus Management Console.

• Enable HTTPS for communications with the console and configure the console to use a CA-signed certificate.
• We do not recommend the “Remember my keys” option for “Login to AWS” because it stores AWS credentials in your browser’s local storage and increases the security risk of AWS credentials being compromised.
• Change the default session timeouts if needed. For more information, see .
• If you don’t use the Management Console, we recommend that you disable (using ). For more information, see .
• Turn off password autocomplete for the console by setting the configuration option to false in the console’s configuration file.
• If memcached is configured to be used by the console, make sure it’s not exposed publicly because there is no authentication mechanism enabled out of the box. If the default Eucalyptus-provided configuration is used, it accepts connections only from localhost.

2.5 - Message Security

This topic describes which networking mode is the most secure, and describes how to enforce message security.

Replay Detection

Eucalyptus components receive and exchange messages using either Query or SOAP interfaces (or both). Messages received over these interfaces are required to have a time stamp (as defined by AWS specification) to prevent message replay attacks. Because Eucalyptus enforces strict policies when checking timestamps in the received messages, for the correct functioning of the cloud infrastructure, it is crucial to have clocks constantly synchronized (for example, with ntpd) on all machines hosting Eucalyptus components. To prevent user commands failures, it is also important to have clocks synchronized on the client machines.

Following the AWS specification, all Query interface requests containing the Timestamp element are rejected as expired after 15 minutes of the timestamp. Requests containing the Expires element expire at the time specified by the element. SOAP interface requests using WS-Security expire as specified by the WS-Security Timestamp element.

Replay detection parameters can be tuned as described in Configure Replay Protection .

Endpoints

Eucalyptus requires that all user requests (SOAP with WS-Security and Query) are signed, and that their content is properly hashed, to ensure integrity and non-repudiation of messages. For stronger security, and to ensure message confidentiality and server authenticity, client tools and applications should always use SSL/TLS protocols with server certification verification enabled for communications with Eucalyptus components.

By default, Eucalyptus components are installed with self-signed certificates. For public Eucalyptus endpoints, certificates signed by a trusted CA provider should be installed.

2.6 - Networking Modes

This topic describes the recommendations for networking modes.A Eucalyptus deployment can be configured in EDGE (AWS EC2 Classic compatible) or VPCMIDO (AWS VPC compatible) networking modes. In both modes, by default, instances are not allowed to send traffic with spoofed IP and/or MAC addresses and receive traffic that are not destined to their own IP and/or MAC addresses. Security groups should be used to control the ingress traffic to instances (EDGE and VPCMIDO modes) and to control the egress traffic from instances (VPCMIDO mode).

VPCMIDO mode offers many security features not present in EDGE mode. Instances of different accounts are deployed in user-defined isolated networks within a Eucalyptus cloud. A combination of security features including VPC, VPC subnets, security groups, source/destination check configuration, route tables, internet gateways, and NAT gateways can be used to selectively enable and configure network access to/from instances or group of instances.

For more information about choosing a networking modes, see Plan Networking Modes .

3 - Security Tasks

Tasks

This section details the tasks needed to make your cloud secure.

3.1 - Configure SSL

Configure SSL

In order to connect to Eucalyptus using SSL, you must have a valid certificate for the User-Facing Services (UFS).

3.1.1 - Configure and Enable SSL for the Management Console

You can use secure HTTP for your console.To run your console over Secure HTTP:

Install nginx on your console server with the following command: yum install nginx Overwrite the default nginx.conf file with the template provided in /usr/share/doc/eucaconsole-/nginx.conf. cp /usr/share/doc/eucaconsole-/nginx.conf /etc/nginx/nginx.conf Uncomment the ’listen’ directive and uncomment/modify the SSL certificate paths in /etc/nginx/nginx.conf (search for “SSL configuration”). For example:

# SSL configuration
listen 443 ssl;
# ssl_certificate /path/to/ssl/pem_file;
# EXAMPLE:
ssl_certificate /etc/eucaconsole/console.crt;
# ssl_certificate_key /path/to/ssl/certificate_key;
# EXAMPLE: 
ssl_certificate_key /etc/eucaconsole/console.key;
# end of SSL configuration

session.secure = true
sslcert=/etc/eucaconsole/eucalyptus.com.chained.crt
sslkey=/etc/eucaconsole/eucalyptus.com.key

3.1.2 - Configure and Enable SSL for the UFS

This topic details tasks to configure SSL/TLS for the User-Facing Services (UFS)

If you have more than one host (other than node controllers), note the following:

• The keystore must be updated on each host running the eucalyptus-cloud service
• The [key_alias] must be the same on each host
• Use a wildcard certificate (i.e. *.<system.dns.dnsdomain>), since UFS is responsible for all service API endpoints

Create a Keystore

Eucalyptus uses a PKCS12-format keystore. If you are using a certificate signed by a trusted root CA, perform the following steps.

Enter the following command to convert your trusted certificate and key into an appropriate format:

openssl pkcs12 -export -in [YOURCERT.crt] -inkey [YOURKEY.key] \
  -out tmp.p12 -name [key_alias]

Save a backup of the Eucalyptus keystore, at /var/lib/eucalyptus/keys/euca.p12 . Import your keystore into the Eucalyptus keystore on the UFS:

keytool -importkeystore -srckeystore tmp.p12 -srcstoretype pkcs12 \
  -srcstorepass [export_password] -destkeystore /var/lib/eucalyptus/keys/euca.p12 \
  -deststoretype pkcs12 -deststorepass eucalyptus -alias [key_alias] -destkeypass eucalyptus

Enable the UFS to Use the Keystore

To enable the UFS to use the keystore, perform the following steps in the CLC because the UFS gets all its configuration information from the CLC. Run the following commands on the CLC:

euctl bootstrap.webservices.ssl.server_alias=[key_alias]

Optional: Redirect Requests to use Port 443

To allow user facing services requests on port 443 instead of the default 8773, run the following commands on the CLC:

euctl bootstrap.webservices.port=443

3.2 - Change Multicast Address

This topic describes how to change your multicast address for group membership.By default, Eucalyptus uses the multicast address 239.193.7.3 for group membership. Most data centers limit multicast address communication for security measures. We recommend that you use addresses in the administratively-scoped multicast address range.

To change the multicast address for group membership Stop all services, starting from the CC, SC, Walrus, then CLC. For example:

systemctl stop eucalyptus-cluster.service
systemctl stop eucalyptus-cloud.service

Change the eucalyptus.conf on the CC, modifying the CLOUD_OPTS parameter to the new IP address:

CLOUD_OPTS="--mcast-addr=228.7.7.3"

systemctl start eucalyptus-cloud.service
systemctl start eucalyptus-cluster.service

Verify that the configured multicast address is being used via netstat:

netstat -nulp

Postrequisites

• Check the firewall after changing the multicast address. See for more information.

3.3 - Configure Replay Protection

You can configure replay detection in Java components (which includes the CLC, UFS, OSG, Walrus, and SC) to allow replays of the same message for a set time period.

euctl bootstrap.webservices.replay_skew_window_sec=[new_value_in_seconds]

If you set this property to 0 , Eucalyptus will not allow any message replays. This setting provides the best protection against message replay attacks.

If you set this property to any value greater than 15 minutes plus the values of ws.clock_skew_sec (that is, to a value >= 920 sec in the default installation), Eucalyptus disables replay detection completely.

When checking message timestamps for expiration, Eucalyptus allows up to 20 seconds of clock drift between the machines. This is a default setting. You can change this value for the Java components at runtime by setting the bootstrap.webservices.clock_skew_sec property as follows:

euctl bootstrap.webservices.clock_skew_sec=[new_value_in_seconds]

3.4 - Configure Session Timeouts

To set the session timeouts in the Management Console:

Modify the session.timeout and session.cookie_expires entries in the [app:main] section of the configuration file. The session.timeout value defines the number of seconds before an idle session is timed out. The session.cookie_expires is the maximum length that any session can be active before being timed out. All values are in seconds:

session.timeout=1800



session.cookie_expires=43200

3.5 - Configure STS Actions

The Security Token Service (STS) allows you to enable or disable specific token actions.By default, the enabled actions list is empty. However, this means that all actions are enabled. To disable actions, list each action in the disabledactions property. To enable specific actions, list them in the enabledactions property.

# euctl tokens
PROPERTY	tokens.disabledactions	{}
PROPERTY	tokens.enabledactions	{}

The values for each property are case-insensitive, space or comma-separated lists of token service actions. If an action is in the disable list it will not be permitted. Eucalyptus returns an HTTP status 503 and the code ServiceUnavailable .

If the enable list is not empty, Eucalyptus only permits the actions specifically listed.

For more information about STS, go to STS section of the AWS CLI Reference .

3.6 - Configure the Firewall

Restricting Network Access

This section provides basic guidance on setting up a firewall around your Eucalyptus components. It is not intended to be exhaustive.

On the Cloud Controller (CLC), Walrus, and Storage Controller (SC), allow for the following jGroups traffic:

• TCP connections between CLC, user-facing services (UFS), object storage gateway (OSG), Walrus, and SC on port 8779 (or the first available port in range 8779-8849)

• UDP connections between CLC, UFS, OSG, Walrus, and SC on port 7500

• Multicast connections between CLC and UFS, OSG, Walrus, and SC to IP 239.193.7.3 on UDP port 8773 On the UFS, allow the following connections:

• TCP connections from end-users and instances on ports 8773

• End-user and instance connections to DNS ports On the CLC, allow the following connections:

• TCP connections from UFS, CC and Eucalyptus instances (public IPs) on port 8773 (for metadata service)

• TCP connections from UFS, OSG, Walrus, and SC on port 8777 On the CC, make sure that all firewall rules are compatible with the dynamic changes performed by Eucalyptus, described in the section below. Also allow the following connections:

• TCP connections from CLC on port 8774 On OSG, allow the following connections:

• TCP connections from end-users and instances on port 8773

• TCP connections from SC and NC on port 8773 On Walrus, allow the following connections:

• TCP connections from OSG on port 8773 On the SC, allow the following connections:

• TCP connections from CLC and NC on TCP port 8773

• TCP connections from NC on TCP port 3260, if tgt (iSCSI open source target) is used for EBS in DAS or Overlay modes On the NC, allow the following connections:

• TCP connections from CC on port 8775

• TCP connections from other NCs on port 16514

• DHCP traffic forwarding to VMs

• Traffic forwarding to and from instances’ private IP addresses

3.7 - Reserve Ports

3.8 - Synchronize Components

To synchronize your Eucalyptus component machines with an NTP server, perform the following tasks.

Enter the following command on a machine hosting a Eucalyptus component:

# ntpdate pool.ntp.org
# systemctl start ntpd.service
# systemctl enable ntpd.service
# ps ax | grep ntp
# hwclock --systohc  

Repeat for each machine hosting a Eucalyptus component.