Skip to main content
IMHCloud Logo
Back to support home

Security Best Practices for OpenStack Instances

Security

Introduction

Security in OpenStack requires a layered approach. Your instances are only as secure as the controls you place around them, from the network perimeter to the operating system and application layers. Production deployments demand careful attention to security groups, network isolation, authentication mechanisms, and ongoing maintenance.

This guide covers the essential security practices you need to protect OpenStack instances in production environments.

Security Groups: Your First Line of Defense

Security groups act as virtual firewalls that control inbound and outbound traffic to your instances. Every instance must belong to at least one security group, and rules are stateful, meaning return traffic is automatically allowed.

Configure Security Groups Correctly

Start with a deny-all approach and explicitly permit only required traffic. This principle of least privilege limits exposure if an instance is compromised.

Default Rules to Implement:

  • Allow SSH (port 22) only from known IP ranges or bastion hosts
  • Allow HTTP/HTTPS (ports 80/443) only for web servers
  • Deny all other inbound traffic by default
  • Restrict outbound traffic to necessary destinations

In Horizon, navigate to Project > Network > Security Groups to create and manage rules. For each rule, specify:

  • Direction: Ingress (inbound) or Egress (outbound)
  • Protocol: TCP, UDP, or ICMP
  • Port Range: Specific ports or ranges (e.g., 22, 80, 443, 3306)
  • Remote: CIDR blocks (e.g., 10.0.0.0/24) or other security groups

Use Multiple Security Groups for Role-Based Access

Rather than creating one security group with all possible rules, create role-specific groups:

  • web-servers: Allows 80/443 from anywhere, SSH from bastion
  • database-servers: Allows 3306/5432 from web server security group only
  • bastion-hosts: Allows SSH from specific admin IPs, outbound SSH to all instances
  • internal-services: Allows traffic only from other instances in your VPC

Assign instances to multiple security groups as needed. An instance can belong to up to five security groups simultaneously.

Audit Security Group Rules Regularly

Security groups tend to accumulate unnecessary rules over time. Schedule regular audits to:

  • Remove rules for decommissioned services
  • Tighten overly permissive CIDR ranges
  • Verify that production instances have no 0.0.0.0/0 rules except for public web servers
  • Document the purpose of each rule

Network Isolation Strategies

Security groups filter traffic, but network isolation ensures instances cannot reach unauthorized resources in the first place.

Use Private Networks for Internal Communication

Place instances that do not require direct internet access on private networks. Connect these to the internet only through:

  • NAT Gateway: For outbound-only access (software updates, API calls)
  • Load Balancer: For inbound access to web applications
  • Bastion Host: For administrative SSH access

In Horizon, create a private network under Project > Network > Networks. When launching instances, select this private network instead of the public network. Attach a router with a NAT gateway to enable outbound connectivity without exposing instances directly.

Segment by Function and Trust Level

Create separate networks for different tiers of your application:

  • Public Network: Load balancers and reverse proxies
  • Application Network: Web servers and application servers
  • Database Network: Database servers, cache servers
  • Management Network: Monitoring, logging, backup systems

Use Neutron routers to control traffic between networks. Apply security group rules at each boundary to enforce least-privilege access.

Disable Unnecessary Network Services

Each running service is a potential attack vector. Disable unused services on instances:

  • Remove default SSH keys and weak credentials
  • Disable unused protocols (e.g., IPv6 if not required)
  • Turn off services like Telnet, FTP, or RDP that transmit credentials in cleartext
  • Use modern alternatives (SSH instead of Telnet, SFTP instead of FTP)

SSH Key Management

Password-based SSH authentication is vulnerable to brute force attacks. OpenStack instances should exclusively use SSH key pairs.

Generate Strong Key Pairs

Use Ed25519 or RSA keys with at least 4096 bits. Generate keys locally and never reuse keys across environments:

1ssh-keygen -t ed25519 -C "production-environment-key"

In Horizon, upload the public key under Project > Compute > Key Pairs. When launching instances, select this key pair. OpenStack injects the public key into the instance at boot time.

Protect Private Keys

Private keys grant full access to instances. Protect them:

  • Store private keys in encrypted directories or credential managers
  • Set restrictive file permissions: chmod 600 ~/.ssh/id_ed25519
  • Never commit private keys to version control or share via unencrypted channels
  • Rotate keys periodically, especially after team member departures

Use Bastion Hosts for SSH Access

Rather than exposing every instance to the internet, place a hardened bastion host in a public network. All SSH traffic routes through this single entry point:

  1. Admin connects to bastion host via SSH with key authentication
  2. Bastion host forwards connection to target instance on private network
  3. All connections are logged for audit purposes

Configure the bastion host with:

  • Minimal installed software
  • Frequent security updates
  • Rate limiting to prevent brute force attacks (e.g., fail2ban)
  • Connection logging to centralized logging system

Operating System Hardening

Even with network controls in place, the instance itself must be secured.

Keep Systems Updated

Unpatched vulnerabilities are the most common attack vector. Automate security updates where possible.

For Ubuntu/Debian:

1sudo apt update && sudo apt upgrade -y
2sudo unattended-upgrades

For CentOS/RHEL:

1sudo yum update -y
2sudo yum install yum-cron
3sudo systemctl enable yum-cron

Enable automatic security updates but test patches in a staging environment before applying to production. Critical patches should be applied within 72 hours of release.

Configure Host-Based Firewalls

Security groups filter traffic at the network level, but host-based firewalls provide an additional layer. Use iptables or firewalld to create rules that mirror your security group configuration.

Example: Allow only SSH and HTTP:

1sudo firewall-cmd --permanent --add-service=ssh
2sudo firewall-cmd --permanent --add-service=http
3sudo firewall-cmd --reload

This defense-in-depth approach ensures that even if security group rules are misconfigured, the instance itself blocks unauthorized traffic.

Disable Root Login Over SSH

The root account is a high-value target. Force users to authenticate as a regular user and escalate privileges with sudo:

Edit /etc/ssh/sshd_config:

1PermitRootLogin no
2PasswordAuthentication no

Restart SSH:

1sudo systemctl restart sshd

Create a dedicated admin user with sudo privileges and ensure that user's SSH key is configured before disabling root access.

Enable Audit Logging

Configure auditd to track security-relevant events:

1sudo apt install auditd
2sudo systemctl enable auditd
3sudo systemctl start auditd

Audit rules can track file access, system calls, and authentication attempts. Forward logs to a centralized logging system for analysis and correlation.

Image Security and Golden Images

Instance security begins at launch. Using trusted, hardened images reduces the attack surface from the start.

Build Hardened Images

Create custom OpenStack images with security configurations pre-applied:

  • All security patches installed
  • Unnecessary services disabled
  • Security tools (intrusion detection, log forwarding) configured
  • SSH keys and passwords removed (injected at launch time)

Use tools like Packer to automate image creation. Store images in a private repository and verify image checksums before use.

Regularly Rebuild and Update Images

Images become outdated as new vulnerabilities are discovered. Schedule regular image rebuilds (monthly or quarterly) with the latest security patches. Launch new instances from updated images and migrate workloads as part of your maintenance cycle.

Verify Image Integrity

Before launching instances, verify that images have not been tampered with. OpenStack supports image checksums and signatures. In Horizon, confirm the checksum under Project > Compute > Images matches your known-good value.

Secrets Management

Credentials and API keys should never be hardcoded in configuration files or source code.

Use OpenStack Barbican for Secrets

Barbican is OpenStack's secret management service. Store sensitive data like database passwords, API keys, and encryption keys in Barbican. Instances retrieve secrets at runtime via the metadata service.

Create a secret in Barbican:

1openstack secret store --name db-password --secret-type passphrase --payload "secure-password"

Retrieve the secret from an instance using the metadata service and Barbican API. Secrets are encrypted at rest and in transit.

Rotate Credentials Regularly

Static credentials are vulnerable if exposed. Implement a rotation policy:

  • Database passwords: Rotate every 90 days
  • API keys: Rotate every 180 days
  • SSH keys: Rotate annually or after personnel changes

Automate rotation where possible using tools like HashiCorp Vault or Barbican combined with configuration management.

Monitoring and Incident Response

Security is not set-and-forget. Continuous monitoring detects threats before they escalate.

Deploy Intrusion Detection Systems

Host-based intrusion detection systems (HIDS) like OSSEC or Wazuh monitor file integrity, log files, and system calls for suspicious activity. Deploy agents on each instance and forward alerts to a central dashboard.

Configure alerts for:

  • Failed SSH login attempts
  • Unexpected changes to system files
  • Unusual outbound network connections
  • Privilege escalation attempts

Centralize Logs for Analysis

Forward logs from all instances to a centralized logging platform (e.g., Elasticsearch, Splunk, or Graylog). This enables:

  • Correlation of events across instances
  • Detection of coordinated attacks
  • Forensic analysis after incidents
  • Compliance reporting

Use tools like Fluentd or Filebeat to ship logs in real time.

Establish an Incident Response Plan

When a security incident occurs, response speed matters. Document your incident response procedures:

  1. Detection: How alerts are generated and escalated
  2. Containment: Isolate affected instances from the network
  3. Eradication: Identify and remove the threat (patch vulnerability, remove malware)
  4. Recovery: Restore services from clean backups or rebuild instances
  5. Lessons Learned: Update security controls to prevent recurrence

Practice incident response with tabletop exercises or simulated attacks.

Backup and Disaster Recovery

Backups protect against data loss from security incidents, hardware failures, or human error.

Implement Regular Snapshot Schedules

OpenStack supports instance snapshots and volume snapshots. Create snapshots:

  • Daily: For critical production instances
  • Weekly: For less critical workloads
  • Before Changes: Prior to updates or configuration changes

Automate snapshots using OpenStack's built-in scheduler or tools like OpenStack Heat.

Store Backups Securely

Snapshots should be stored in a separate location from the production environment. Use object storage (Swift or S3-compatible) with:

  • Encryption at rest
  • Access controls (IAM policies or RBAC)
  • Immutable backups to prevent ransomware deletion

Test backup restoration regularly. A backup you cannot restore is worthless.

Document Recovery Procedures

Write runbooks for common recovery scenarios:

  • Restore a single instance from snapshot
  • Rebuild an environment from backups after compromise
  • Migrate to a different availability zone or region

Ensure multiple team members can execute recovery procedures.

Compliance and Governance

Security best practices often overlap with compliance requirements for standards like PCI DSS, HIPAA, or SOC 2.

Implement Role-Based Access Control

Use OpenStack Keystone to define roles and permissions. Follow the principle of least privilege:

  • Developers have read-only access to production
  • Operations team has deployment permissions
  • Security team has audit access to all resources

Review permissions quarterly and remove access for departing team members immediately.

Enable Multi-Factor Authentication

For administrative access to Horizon and the OpenStack API, enable multi-factor authentication (MFA). Keystone supports MFA through TOTP (Time-based One-Time Password) or external identity providers like LDAP or Active Directory.

Maintain Audit Trails

Enable API logging in Keystone to track all actions performed in OpenStack:

  • Who created, modified, or deleted resources
  • When changes were made
  • Source IP addresses of API calls

Store audit logs for the duration required by your compliance framework (typically 1-7 years).

Summary

Securing OpenStack instances requires a multi-layered approach:

  • Security groups control network traffic with deny-by-default rules
  • Network isolation limits blast radius through private networks and segmentation
  • SSH key management eliminates password-based authentication risks
  • Operating system hardening includes patching, host firewalls, and disabled root login
  • Image security starts with hardened, regularly updated base images
  • Secrets management keeps credentials out of code and configuration files
  • Monitoring and incident response detect and contain threats quickly
  • Backups and disaster recovery ensure resilience against attacks and failures
  • Compliance and governance enforce least-privilege access and audit trails

Implement these practices systematically. Start with the foundational controls (security groups, key management, patching) and layer on additional protections over time. Regular audits and continuous improvement keep your OpenStack environment secure as threats evolve.