Learn OpenStack - Manila (Shared Filesystem Service) & Barbican (Key Manager)

#Introduction

The two storage types covered in episodes 8 and 9 — block and object — aren't complete without one more: the shared filesystem. Many workloads need the same folder accessed by many instances simultaneously: application clusters, web servers sharing assets, HPC environments. That's what Manila, OpenStack's Shared Filesystem Service, provides.

Episode 10 combines two services that are rarely discussed but important in production: Manila for NFS/CIFS shares, and Barbican as the key manager — the home for secrets, encryption keys, and certificates. Both answer questions that often arise after storage and networking are running: how to share files, and how to secure encryption keys.

#Manila: Shared Filesystem as a Service

#The Share Concept

Manila provides a share — a network filesystem (NFS or CIFS) that several instances can mount simultaneously with read-write access. Imagine a shared network drive inside the cloud. Unlike a Cinder volume, which can only be attached to one instance at a time, a Manila share is designed for multi-access.

        Share NFS/CIFS (backend: CephFS / NFS-Ganesha)
              ↙         ↓          ↘
Instance A     Instance B     Instance C (mounted simultaneously)

Typical scenarios: several web servers reading the same static pages, or an application cluster sharing a data directory. With Manila, the data is stored once and accessed by all nodes.

#Creating and Using Shares

openstack share create --share-type default nfs 100 --name share-data
openstack share access create share-data ip 192.168.100.50
openstack share show share-data -c export_locations

openstack share create nfs 100 creates a 100 GB NFS share. The openstack share access create share-data ip 192.168.100.50 command grants access to a specific instance IP — share security is managed per-IP.

#Mounting from an Instance

From inside an instance, mounting a share works like a regular NFS mount using the export location:

sudo mkdir -p /mnt/share
sudo mount -t nfs 192.168.100.10:/share-data /mnt/share

After mount -t nfs, all allowed instances can read and write the same files. Add an entry to /etc/fstab so the mount survives a reboot.

#Manila Backends

Manila doesn't store data itself — it orchestrates backends:

• CephFS: a modern production backend, integrated with a Ceph cluster.
• NFS-Ganesha: bridges storage such as LVM or Ceph to the NFS protocol.
• NetApp ONTAP: for organizations already using NetApp storage arrays.

#Barbican: Key Management Service

#The Home for Secrets and Keys

Barbican is OpenStack's Key Management Service (KMS) — a secure place to store secrets, encryption keys, and certificates. Instead of keeping passwords or keys in scattered config files, all secrets are stored centrally and accessed through APIs.

openstack secret store --name db-password --payload rahasiaDB123
openstack secret list
openstack secret get db-password -f value -c payload

openstack secret store --payload rahasiaDB123 stores a secret named db-password. Applications and other services then retrieve it through the Barbican API, not from hardcoded config.

#Integration with Storage Encryption

Barbican's greatest value appears when integrated with storage:

• Cinder Volume Encryption: volumes are encrypted with keys stored in Barbican — data is safe even if the storage backend is compromised.
• Nova Disk Encryption: an instance's ephemeral disk can also be encrypted with keys from Barbican.

openstack volume create --type encrypted --size 50 --name volume-encrypt

The openstack volume create --type encrypted command creates an encrypted volume using a storage type that points to Barbican. The encryption keys are fully managed by Barbican — no one ever sees them as plaintext.

#Certificates and PKI Use Cases

Barbican also stores certificates and CA bundles — very useful for managing TLS across many services. Operators can keep internal certificates in Barbican, and OpenStack services retrieve them to secure endpoints — aligned with the TLS topic we'll cover in episode 17.

#Managing Secret Access

Barbican protects secrets with ACL-based access. You can restrict who is allowed to read a secret — specific service accounts, or only certain projects:

openstack secret acl show db-password -f value -c read
openstack secret acl set --user <user-id> db-password

The openstack secret acl set --user <user-id> db-password command adds a specific user to the secret's reader list. Only registered users can retrieve the payload — everyone else gets a 403 Forbidden error. This pattern matters in production: a database secret must not be readable by any random service, only by those that truly need it.

#Understanding the Flow in One Scenario

To test your understanding, follow a complete flow of using a secret during provisioning:

openstack secret store --name web-token --payload "token-internal-2026"
openstack secret get web-token -f value -c payload

The output of openstack secret get web-token -f value -c payload returns the secret as plaintext. In production practice, this value is retrieved by a service or automation script — not a human — so the secret never flashes up on a terminal. Barbican becomes the single place secrets are stored, and all access to them is logged.

#Summary

Episode 10 rounds out your storage and security services: Manila provides NFS/CIFS shared filesystems mountable by many instances with CephFS and NFS-Ganesha backends, while Barbican serves as the central key manager for secrets, encryption keys, and certificates with Cinder volume and Nova disk encryption integration.

Key takeaways:

• Manila provides shares accessed by many instances at once.
• Share access is managed per-IP via openstack share access create.
• CephFS and NFS-Ganesha are commonly used Manila backends.
• Barbican centrally stores secrets, encryption keys, and certificates.
• Cinder and Nova use Barbican for storage encryption.
• Barbican keys must be backed up so they're never lost forever.

In episode 11, we'll cover Horizon Dashboard and OpenStack CLI Mastery — exploring Horizon's UI navigation to manage projects, compute, network, volume, and identity, mastering the unified openstack CLI, using the openrc environment file, and formatting output with -f json, -f table, and -f value.