Learn OpenStack - Security Hardening, TLS & RBAC Policies

#Introduction

After storage, networking, and deployment are sorted, there's one thing that can't be postponed: security. A cloud operated without TLS, without clear access limits, and without network protection is a liability waiting to happen. Episode 17 covers OpenStack hardening at three layers: API endpoints, access policies, and instances.

Episode 17 covers securing API endpoints with TLS and internal/public separation, customizing policy.yaml for granular RBAC, and protecting instances from metadata service exploits and spoofing through port security.

#Securing OpenStack API Endpoints

#TLS/HTTPS on All Endpoints

All communication with OpenStack must go through HTTPS. In Kolla-Ansible, HAProxy is the TLS termination point — external connections are encrypted, and HAProxy forwards to the internal services.

kolla_enable_tls_external: "yes"
kolla_certificates_volume: "/etc/kolla/certificates"
kolla_external_fqdn: "cloud.example.com"

kolla_enable_tls_external: "yes" enables TLS at HAProxy. Put the certificates in kolla_certificates_volume — after that, all API endpoints can only be reached over HTTPS.

openstack endpoint list --interface public -f value -c URL
curl -sI https://cloud.example.com:35357/v3 | head -n 1

The output of openstack endpoint list --interface public must show https:// URLs for every service. Verify with curl that TLS is truly active.

#Separating Internal API and Public API

Endpoints are divided into two interfaces:

• Internal API: used by services between nodes and internal clients — behind the scenes, no public TLS needed.
• Public API: used by admins and users from outside — always over TLS with trusted certificates.

Public API   → https://cloud.example.com (TLS, from outside)
Internal API → http://10.0.0.x:8774 (management network)

This separation ensures internal traffic never leaves to the public network and certificates are only exposed on the public interface — a pattern that also eases monitoring and access control.

#RBAC Policy Customization

#The policy.yaml File

Every OpenStack service decides permissions with a policy.yaml file — customizable RBAC rules. The defaults are fairly permissive; production usually tightens them.

"os_compute_api:servers:create": "role:admin or role:member"
"os_compute_api:servers:delete": "role:admin"
"os_compute_api:servers:start": "role:admin or role:member"
"os_compute_api:servers:stop": "role:admin or role:member"

The file above is an example of tightening: only admins may delete servers, while members may create and manage them. The role:admin syntax is a built-in rule understood by all services.

#Applying Changes

kolla-ansible -i multinode reconfigure --tags nova
openstack server delete test-vm

kolla-ansible -i multinode reconfigure --tags nova propagates the new policy.yaml to all Nova nodes. When a policy is tightened, users without the role receive a 403 Forbidden error — that's the signal RBAC is working. Test every tightening with different roles before going to production.

#The Principle of Least Privilege

RBAC's golden rule: grant the minimum rights possible. Start from the defaults, restrict dangerous actions like delete and resize to the admin role, and never put regular users in an admin-role group just because it's convenient. This policy layers with the Keystone roles you learned in episode 3.

#Instance Security Hardening

#Protecting the Metadata Service

The metadata service at 169.254.169.254 is a favorite target: if an instance can make requests to that address, it can read another project's metadata or forge tokens. Main protections:

• Neutron Metadata Proxy restricts per-instance access with network namespaces and special headers.
• Firewalls block metadata access from segments that shouldn't have it.
• Never put secrets in user data that the metadata service can read.

#Port Security and Anti-Spoofing

Port security stops spoofing — instances sending packets with a MAC or IP that isn't theirs:

openstack port create --network net-aplikasi --enable-port-security port-aman
openstack port set --no-allowed-address port-aman

The openstack port create --enable-port-security command enables anti-spoofing rules: Neutron only accepts traffic with the MAC and IP registered on the port. This prevents attacks like DHCP spoofing and ARP poisoning between tenants.

#Closing Other Gaps

Beyond port security, keep up: security groups always applied (default deny inbound), floating IPs only for those who truly need them, and the remote console (VNC/SPICE) accessed only over the internal network with authentication. Every public access path must go through a single audited door.

#Summary

Episode 17 secures the cluster at three layers: API endpoints with TLS and internal/public separation, granular RBAC through policy.yaml customization, and instance hardening by protecting the metadata service and enabling port security against spoofing.

Key takeaways:

• All public endpoints must be HTTPS via HAProxy SSL termination.
• Separate the internal API from the public API.
• policy.yaml governs granular RBAC per service.
• kolla-ansible reconfigure propagates policy changes.
• Apply least privilege: delete and resize only for admins.
• Port security prevents MAC and IP spoofing between tenants.

In episode 18, we'll cover Monitoring, Logging & Alerting — installing Prometheus exporters for every OpenStack service, building Grafana dashboards for API response, instance count, and hypervisor utilization, centralizing logs to the ELK Stack or Grafana Loki, and configuring Alertmanager for notifications when a node is down, a queue overflows, or an OSD is degraded.