When deploying OpenStack in production environments, one of the most critical concerns is ensuring that multiple tenants can safely share the same underlying infrastructure without compromising each other’s data or operations. This challenge becomes particularly nuanced when dealing with external block storage arrays, where OpenStack Cinder drivers must interact with sophisticated storage systems while maintaining strict tenant isolation.
The Challenge of External Storage Multitenancy
Unlike local storage where the hypervisor provides natural isolation boundaries, external storage arrays present a unique security challenge. Multiple OpenStack deployments or tenants may share the same physical storage infrastructure, creating potential attack vectors if not properly secured. The question becomes: how do we ensure that a Cinder driver can only affect storage resources it legitimately created, without the ability to maliciously interfere with other storage objects on the backend array?
Cinder’s Approach to Secure Storage Management
OpenStack Cinder addresses this challenge through several key architectural principles:
1. Driver Scope Limitation
Cinder drivers are designed with inherent scope limitations. Each driver instance operates within a well-defined boundary, maintaining metadata about the storage resources it has created. This includes volume UUIDs, snapshot identifiers, and tenant associations that are tracked both in OpenStack’s database and often mirrored in the storage array’s metadata.
2. Privileged Access with Controlled Scope
Cinder drivers require privileged access to external storage arrays to create and manage complex storage constructs like hosts, protection groups, cluster pods, and other infrastructure elements. However, this privileged access is coupled with strict operational controls that ensure the driver only affects resources it has legitimately created, despite having the technical capability to access broader storage infrastructure.
3. Resource Naming Conventions
A critical security feature is the consistent naming strategy employed by Cinder drivers. For example, the Pure Storage FlashArray driver uses well-defined naming conventions for all OpenStack-created resources. Storage objects are prefixed with deployment-specific identifiers and have additional strings appended to the end of OpenStack resource names, creating predictable patterns that clearly associate them with their OpenStack origin. When performing operations, drivers first verify that a storage object follows the expected naming convention before proceeding, ensuring they only operate on resources they legitimately created.
4. API-Level Validation
Before executing any operation on the external storage array, Cinder drivers perform multiple validation checks. These include verifying that the requested operation targets a resource that exists in OpenStack’s database, confirming tenant ownership, validating the resource follows the expected naming convention, and ensuring the operation is within the scope of the driver’s responsibilities.
Best Practices for Deployment
To maximize security when using external storage with OpenStack:
- Secure privileged credentials and limit their exposure through proper credential management
- Use network segmentation to isolate OpenStack management traffic to storage arrays
- Enable audit logging on both OpenStack and storage array sides to track all operations
- Regularly review storage array access patterns to identify any anomalous behavior
Security Considerations Beyond Driver Design
While Cinder’s architectural controls provide strong protection against accidental or casual interference, it’s important to note that if a malicious actor gains access to the Cinder configuration files—where storage credentials are typically stored in plain text—there are much larger security concerns at play. However, some storage vendors like Pure Storage help mitigate this risk by using API tokens rather than username/password strings in their drivers. This approach requires an additional level of technical understanding for an attacker to successfully perform malicious acts, as API tokens must be used through specific programmatic interfaces rather than simple authentication methods. Still, such access would indicate a fundamental breach of the OpenStack control plane that extends far beyond storage driver permissions. In these scenarios, securing the underlying infrastructure, implementing proper access controls, and following security best practices for credential management become paramount.
The Bottom Line
OpenStack Cinder’s architecture inherently prevents drivers from randomly affecting storage items they didn’t create. Through careful scoping, naming conventions, and API-level checks, the system ensures that each driver operates only within its designated boundaries. This design provides the foundation for secure multitenancy, allowing organizations to confidently deploy shared storage infrastructure while maintaining strict tenant isolation.
While no system is completely immune to misconfiguration or sophisticated attacks, Cinder’s layered approach to security provides robust protection against both accidental and malicious interference with external storage resources. Understanding these mechanisms is crucial for administrators deploying OpenStack in multitenant environments where storage security is paramount.
