Delivering Secure OpenStack IaaS for SaaS Products

Delivering Secure
OpenStack IaaS for SaaS
Products
Andrew Hay
Chief Evangelist
andrew@cloudpassage.com
twitter.com/andrewsmhay

OpenStack Summit 2012
© 2012 CloudPassage Inc. #cloudsec | #openstack

Who are you?
• Andrew Hay, Chief Evangelist, CloudPassage

• Former
– Industry Analyst @ 451 Research
– Information Security Office @ UofL and bank in Bermuda
– Product, Program and Engineering Manager @ Q1 Labs
– Linux guy at a few ISPs

© 2012 CloudPassage Inc.

What does CloudPassage do?
Security and compliance automation for
public, private and hybrid cloud servers

Dynamic Cloud System Integrity
Firewall Automation Monitoring & IDS

Two-Factor Server Account
Authentication Management

Server Vulnerability Server Security
Scanning Events & Alerting

 Eliminates barriers to cloud hosting adoption
 Enables cloud hosting & IaaS compliance
 Purpose built for cloud from the ground up

Topics for today

Overview of OpenStack security

OpenStack host security

Why the cloud makes security hard

How to secure OpenStack images


Core OpenStack Architecture
Horizon

Quantum

Nova Glance Swift

Cinder

Keystone


OpenStack Security: Quantum
• Quantum
– Network connectivity as a service
– From a flat, shared network to per-tenant routers with private
networks

– API to let 3rd party vendors „plug in‟
• e.g. Nicera Network Virtualization Platform (NVP)
– Supports virtual port isolation, virtual port mirroring, QoS, security
profiles and detailed per-port statistics.


OpenStack Security: Keystone
• Keystone
– Identity service used by OpenStack for authentication (authN)
and high-level authorization (authZ)
– Currently supports token-based authN and user-service
authorization.
– Recently re-architected to allow for expansion to support
proxying external services and AuthN/AuthZ mechanisms
• e.g. oAuth, SAML and openID in future versions.

keystone user-create --name=nova
--pass=Sekr3tPass
--tenant_id=[the uuid of the tenant]
--email=nova@nothing.com


OpenStack Security: Nova
# This is the code for the python-keystoneclient script

• Nova
# Using token auth env variables
export SERVICE_ENDPOINT=http://127.0.0.1:5000/v2.0/
export SERVICE_TOKEN=secrete_token
– Security
keystone user-list groups $ nova secgroup-create openpub "Open for public"
keystone tenant-create --name=demonova secgroup-add-rule openpub icmp -1 -1 0.0.0.0/0
$
– Firewall (iptables) $ nova secgroup-add-rule openpub tcp 22 22 0.0.0.0/0
# Using token auth flags
keystone --token=secrete --endpoint=http://127.0.0.1:5000/v2.0/ user-list
keystone --token=secrete --endpoint=http://127.0.0.1:5000/v2.0/ tenant-create --
name=demo
# nova-manage network create --num_networks=100 --
– VLAN‟s fixed_range_v4=172.16.100.0/24
# Using user + password + tenant_name env variables
export OS_USERNAME=admin
export OS_PASSWORD=secrete
export OS_TENANT_NAME=admin
keystone user-list
keystone tenant-create --name=demo

# Using user + password + tenant_name flags
keystone --username=admin --password=secrete --tenant_name=admin user-list
keystone --username=admin --password=secrete --tenant_name=admin tenant-create --
name=demo

– Identity Management with Keystone

OpenStack Host Security…


Why Secure the Images?
• “We have security groups, infrastructure firewall
rules and Keystone for authentication so we don’t
need to secure the images.” – OpenStack Admin
with a Plan.

“Everyone has a plan
'till they get punched
in the mouth.” – Mike
Tyson


• Network-based security is only so good in
multitenant clouds

• The ultimate target is the endpoint
– So secure it

• You wouldn‟t leave your doors unlocked…
– Would you?



“Son, we live in a world that has
walls, and those walls have to be
guarded by men with guns. Who's
gonna do it? You? You, Lt.
Weinburg?”

No “Natural” Segmentation

Auth DB DB DB
Server

core core
Firewal
l

Load App Load App
Balancer Server Balancer Server

dmz dmz
Firewal
l

public cloud


Cloud Servers are More Exposed

Load
Balancer

App App
Server Server

DB
Master

public cloud


DENY ALL – Helps & Hinders
&$#@$*@?
Load !?!?
Balancer
FW

App App
Server Server
FW FW

DB
Master
FW

public cloud


What About Complex Deployments?

Load Load
Balancer Balancer
FW FW

App App App
Server Server Server
FW FW FW

DB DB
Master Slave
FW FW

public cloud


What About Dynamic Deployments?

Load Load
Balancer Balancer
FW FW

App App App
Server Server App
Server
FW FW Server FW

IP

DB DB
Master Slave
FW FW

public cloud


From De-Provisioned to AHHH!!!

Load Load
Balancer Balancer
FW FW

App App
Server Server App
FW FW Server
IP

DB DB
Master Slave
FW FW

public cloud


Securing OpenStack Nova
Images


Imagine There‟s No Network
• It‟s easy if you try…

• We should protect our servers as if
they are directly connected to the
Internet
– Because in some cases, they are.


Why secure the OS?
• A hardened OS often is the last line of
defense in the event of a security
compromise.

• It is important to note that hardening is
not a panacea for security.
– It is just another layer in a good security
model.

• By definition, any machine that is
accessible on a network and running
services is potentially insecure.
– (i.e. pretty much any server)


Top 5 Easy Things to Start
Securing Your OpenStack Images
1. Disable unnecessary services

2. Remove unneeded packages

3. Restrict access to sensitive files & directories

4. Remove insecure/default configurations

5. Allow administrative access ONLY from trusted
servers/clients


Disable unnecessary services
• Only what is needed…is needed

• Shutdown and disable
unnecessary services
– e.g. telnet, r-services, ftpd, etc.


Remove unneeded packages
• If it isn‟t being used…why keep it?

• If the server doesn‟t need to
serve web pages
– Remove PHP, Apache/nginx

• If it‟s not a database server
– Remove MySQL/PostgreSQL


Restrict access to sensitive files & directories

• Protect what‟s important from prying/malicious eyes

• Ensure file permissions restrict access to
sensitive files and directories
– E.g. /etc/shadow, /etc/ssh/sshd_config,
– E.g. /var/tmp/, /tmp/


Remove insecure/default configurations
• Disable password authentication for SSH
– Force public key authentication
– Also, disable empty passwords for users

• SSH
– Ensure only v2 protocol connections are allowed

• Apache
– Minimize loadable modules
– Disable ServerTokens and ServerSignature directives


Allow administrative access ONLY from trusted
servers/clients
• Leverage the firewall and other tools
– Source of corporate network / admin
network range
– 3rd-party tools like fail2ban

• Don‟t allow „server hopping‟
– Most people use keys without passwords to
make things easier 

• Facilitate on-demand access using two-
factor authentication


If only we had more time…
• More documentation to review:
– NIST SP800-123: Guide to General Server Security
• http://csrc.nist.gov/publications/nistpubs/800-123/SP800-123.pdf
– Halo Configuration Policy Rule Checks
• http://support.cloudpassage.com/entries/22033142-configuration-policy-rule-
checks
– CIS Red Hat Enterprise Linux 6 Benchmark v1.1.0
• http://benchmarks.cisecurity.org/en-us/?route=downloads.show.single.rhel6.110
– NSA Security Configuration Guides
• http://www.nsa.gov/ia/mitigation_guidance/security_configuration_guides/operatin
g_systems.shtml#linux2


Number 6 – Employ Tools Designed for
Cloud Environments
• You‟ve locked down your server
based on the Top 5
– And other guides

• Now What?

• Rely on a tools built for continuous
cloud security:
Dynamic Cloud Server Vulnerability Server Account
Firewall Automation Scanning Management
Two-Factor
System Integrity Server Security
Authentication
Monitoring & IDS Events & Alerting


Summary

Cloud deployments require a
new approach to security

Get your house in order before
adding tools on top

Use tools that work on/with/in
cloud environments

Summary++
• Don‟t be in such a rush to get to cloud that you trip
yourself up…


Try Halo FREE - 5 Minute Setup

Register at Free
Trial!
cloudpassage.com

Install daemons on cloud
servers

Configure security policies
in Halo web portal


We Work Everywhere!


The End
• Ask questions!
– Lots more info: community.cloudpassage.com
– Small bits of info: @cloudpassage

• Tell me what you think!
– Email: andrew@cloudpassage.com
– Twitter: @andrewsmhay
BTW,
• We’re hiring! We’re
Sales Engineers, cloud/security Hiring!
analysts, rails devs and UX devs
– Email: jobs@cloudpassage.com


Thank You!
Andrew Hay
andrew@cloudpassage.com
@andrewsmhay

@cloudpassage
#CloudSec | #OpenStack


Delivering Secure OpenStack IaaS for SaaS Products

Recommended

Recommended

More Related Content

What's hot

What's hot (19)

Viewers also liked

Viewers also liked (20)

Similar to Delivering Secure OpenStack IaaS for SaaS Products

Similar to Delivering Secure OpenStack IaaS for SaaS Products (20)

More from CloudPassage

More from CloudPassage (18)

Recently uploaded

Recently uploaded (20)

Delivering Secure OpenStack IaaS for SaaS Products