Lockdown & support access guide

Transcription

1 Lockdown & support access guide How to lock down your cloud, and enable the OnApp support team to help you with troubleshooting and ticket resolution. Document version 1.4 Document release date 21 st February 2013 document revisions 1

2 Contents 1. About this guide Granting access to OnApp/other trusted users SSH Firewalls Web UI (Control Panel) Other considerations Cleaning VM disks OnApp policies & client responsibilities Authorization to make changes Troubleshooting issues where access cannot be granted OnApp client responsibilities Security audits Opting out Document revisions

3 1. About this guide This guide explains how to lock down your cloud, while allowing the OnApp support team to assist you with troubleshooting and ticket resolution. It also provides a brief explanation of OnApp policies when troubleshooting and configuring your cloud in response to any support tickets you raise. For more information about anything included in this document, please contact the OnApp support team: support@onapp.com. 3

4 2. Granting access to OnApp/other trusted users To access your systems, the OnApp support team needs to be able to connect to your Control Panel server via its Public IP or NAT. Access via VPN or IPMI is not supported. The sections below explain how this access can be granted and secured. 2.1 SSH Our team may require SSH access to your cloud for performing upgrades, troubleshooting or log analysis. We suggest you add the following key to your /root/.ssh/authorized_keys file on your Control Panel server to allow us access without having to exchange a password. The key is formatted so you should be able to copy and paste it without line breaks/spaces etc from interfering (but please double-check it before saving!) ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA49ry72+wSqIoE4c8r7+jFS9b1HPTJtx95CPkBMP8MqK dpy+eironafocdl9kbjd+1vqvn6toykos9xptkmu2+q/oxze+lhcfj/bzkc80tziabsbrvc l+fndsgkgz3akj+83ept0auh7qdhcf5zw3bdeqijat/5pphwqhntmkiljjlxdrgo/k5yp7/ pubhpdv0kecw0lcdkt+awvu88hasf3q+baprqgrmy46eehoptbx6zcd+mf9lrg4myrxf/cv kf4q8eiezfm12cykjem/oebf7ooajwonckxkbkl4ems41ccjayxrh+p6es24f4l2hbzz7pn 90W5v0tE0ABqqtQ== At any time you can comment out the key by placing a # at the start of the line to revoke access for our staff, and then simply remove the # should you need to give us access again. Access from your Control Panel server to other components of your cloud, such as hypervisors and backup servers, is also granted via SSH keys. Consequently there is no need to allow SSH access from the outside world to those servers. If you only connect to OnApp Cloud via SSH keys, you may wish to turn off Password Authentication in your /etc/ssh/sshd_config file: PasswordAuthentication no You may also wish to consider changing the default SSH port on your Control Panel server. Note that you can only do this if you have a separate backup server, as OnApp will use the default SSH port to communicate internally with the backup server. To change the port you can open the /etc/ssh/sshd_config file and edit #Port 22 You will need to uncomment the setting and edit the port number as necessary. You will also need to restart SSH for the settings to take effect. This should not interrupt your current active SSH sessions. 4

5 2.2 Firewalls The Control Panel will need to have incoming traffic allowed to ports 80/443 & >40000, and be able to communicate outbound to our licensing server on port Do not block any communication between the Control Panel and the hypervisors. Where possible we recommend that you use a hardware firewall device or Access Control List (ACL) in front of your management network, as opposed to using iptables directly on the Control Panel server. This will help avoid issues which could be caused by misconfiguration of iptables rules. The example below shows how you can configure iptables on your OnApp Controller server to lock all unnecessary access to your cloud. Please be sure to edit the rules to suit your environment before applying them to your server. If you are allowing global WebUI access then you should only need to change the IP addresses in the example below, since the ports are already configured for you. # Allow default services first iptables -A INPUT -i lo -j ACCEPT iptables -A INPUT -p icmp --icmp-type any -j ACCEPT iptables -A INPUT -p udp --dport d j ACCEPT iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # Allow all traffic from hypervisors (this is critical) iptables -A INPUT -s /24 -j ACCEPT # Allow SSH from administrative IP addresses and lock down globally iptables -A INPUT -s p tcp --dport 22 -j ACCEPT iptables -A INPUT -s p tcp --dport 22 -j ACCEPT # Allow http/https (OnApp WebUI) and console ports globally iptables -A INPUT -p tcp --dport 80 -j ACCEPT iptables -A INPUT -p tcp --dport 443 -j ACCEPT iptables -A INPUT -p tcp --dport 30000: j ACCEPT # Reject all other incoming traffic iptables -A INPUT -j REJECT --reject-with icmp-host-prohibited # Save config and set to start at boot iptables-save > /etc/sysconfig/iptables chkconfig iptables on service iptables start You must not make any changes to the iptables config on your hypervisor servers since this is fully managed by OnApp, and flushing the current rules could lead to downtime for your virtual machines. 2.3 Web UI (Control Panel) At times we are likely to need to access your OnApp Web UI to troubleshoot, replicate and resolve any issues you may report in a support ticket. We recommend putting the following safeguards in place: 5

6 Create an onapp-support user with the necessary privileges. For troubleshooting we would typically require the Admin role to be assigned to this user. You can also create a new role for this user and assign it the necessary permissions depending on the issue being reported. When you don t have any open support cases, which require us to access your systems, suspend this user via the UI. When you need us to access your system, temporarily activate the user until the ticket has been resolved. You should also create a whitelist for the following IP addresses for this user: Please see the following URLs for guidance on creating users, assigning roles, editing whitelist IPs and suspending actions on accounts: Add User: Changing User Role: Suspend/Activate a User: Permissions List: Whitelisting IP addresses: We strongly recommend that all users with admin level access to the Web UI have an active whitelist to specific IP addresses. 6

7 2.4 Other considerations Our support team will connect via one of the following IP addresses, so also please make sure you allow access from those IPs, for both SSH and the Web UI, in any Firewalls or ACLs you have in front of the cloud: If you do not offer clients direct access to your OnApp UI, you may want to firewall it down just to your office or trusted IP addresses which should be able to interact with the Control Panel server - for example, billing systems that connect to OnApp via the API. Here is an example iptables config that could be used in this situation: # Allow default services first iptables -A INPUT -i lo -j ACCEPT iptables -A INPUT -p icmp --icmp-type any -j ACCEPT iptables -A INPUT -p udp --dport d j ACCEPT iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # Allow all traffic from trusted ip addresses (all ports) iptables -A INPUT -s p tcp -j ACCEPT iptables -A INPUT -s p tcp -j ACCEPT # Reject all other incoming traffic iptables -A INPUT -j REJECT --reject-with icmp-host-prohibited # Save config and set to start at boot iptables-save > /etc/sysconfig/iptables chkconfig iptables on service iptables start 7

8 3. Cleaning VM disks The latest version of OnApp Cloud (v3.0) gives you two ways to clean VM data when deleting or migrating a VM's disk. By default, OnApp Cloud will format the physical disk space used by a virtual machine when that VM's virtual disk is deleted, or when the VM is migrated to another hypervisor. You can also choose to wipe/format a VM's disk (filling it with zeroes) by changing a configuration setting on the OnApp Controller Server. To enable this behaviour: 1. Log in as root on your OnApp Controller Server 2. Edit the following configuration file... /onapp/interface/config/on_app.yml... and set the wipe_out_disk_on_destroy parameter to true 3. Restart OnApp service: service onapp restart The wipe_out_disk_on_destroy value is set to FALSE by default. If you wish to return disk wiping behaviour to the default setting (formatting rather than zeroing disks), simply edit the config file and set the value to FALSE again. PLEASE NOTE: In OnApp Cloud v2.x, disk wiping was enabled by applying a specific LV Wipe patch. If you installed this patch you should remove it before you enable disk wiping under OnApp Cloud v3.0. For uninstall instructions, see the guide here: 8

9 4. OnApp policies & client responsibilities IMPORTANT - Please note! Unless you specify otherwise, we assume that the submission of a support ticket gives us permission to access your OnApp cloud if that is required to investigate and resolve your ticket. If you want only certain data to be seen, and functionality to be used, please assign our support team a role with the necessary permissions. 4.1 Authorization to make changes When you submit a support ticket, we may need to make configuration changes as part of the troubleshooting process, or to implement a fix or workaround. There may be situations where it is necessary to make configuration changes or perform actions on Virtual Machines. In these situations, we will request confirmation from an authorized contact on your account before we make any changes. 4.2 Troubleshooting issues where access cannot be granted We understand that it may not always be possible to grant us access to your infrastructure. In these cases we will do our best to help resolve any issues you are faced with, without having access. Where necessary we will attempt to replicate any issues within our own environments. If this is not possible we may need to request screenshots, logs and steps to replicate in order to resolve the issue. Please note, however, that not having access is likely to increase the time taken to resolve your ticket. It may even prevent full resolution of your problem. In these circumstances we will do our utmost to resolve your issue, but we may need access to provide a complete solution. If access really isn t possible, you might consider setting up a small additional cloud which replicates your environment, but where you can allow outside access. Please contact your OnApp Account Manager to discuss setting up this kind of staging cloud. 4.3 OnApp client responsibilities It is your responsibility to ensure that the measures described in this document are applied to your clouds, and that access is granted and removed as needed. The OnApp support team will not have the ability to disable its own access, and so any access granted will remain in place until you disable it. If you require any assistance securing your servers, or with any of the steps detailed in this document, please contact the OnApp Support team and we ll be happy to advise. 9

10 5. Security audits We may occasionally run security audits on your cloud to ensure that the suggestions in this guide have been followed, and so we can suggest improvements where necessary. If we do test your cloud we will contact you to let you know, whatever the outcome was. These checks are conducted from secure.onapp.com. Please do not whitelist this in your config, as it could lead to false positive results. 5.1 Opting out Most customers find these occasional security checks quite helpful, but if you would rather opt out, just and let us know. Thanks! 10

11 6. Document revisions v1.4, 21 st February 2013 Updated Cleaning VM disks section to reflect new functionality in OnApp Cloud v3.0 v1.3, 28 th January 2013 Updated information in the SSH section. v1.2, 29th October 2012 Updated URLs in the Web UI section to point to new support portal content v1.1, 29th August 2012 Updated URLs in the Web UI section to point at latest online manuals and KB articles v1.0, 29th February 2012 First release 11