Integrating Pure Storage FlashBlade S3 with OpenStack: A Practical Guide

Posted on by Simon

Integrating Pure Storage FlashBlade as an object store in OpenStack environments presents unique challenges when bypassing Swift. This guide walks through a practical architecture that uses permanent S3 tokens and external Identity and Access Management (IAM) to provide OpenStack users with direct, secure access to FlashBlade buckets while maintaining fine-grained access control.

Understanding the Architecture

The integration relies on three core components working together: OpenStack’s Keystone for user authentication, an external IAM layer for federation, and FlashBlade’s native S3 access controls. This architecture separates identity assertion from permission management, allowing each system to handle what it does best.

When an OpenStack user needs to access object storage, they first authenticate through Keystone, which issues a token containing their user ID, project assignment, role memberships, and expiration time. This token serves as an identity assertion that the external IAM layer then translates into FlashBlade-specific credentials and policies.

Configuring Keystone for Federation

Before the external IAM can validate Keystone tokens, Keystone must be properly configured with the appropriate projects, users, and roles. Here’s how to set up a typical multi-tenant environment:

# Create projects for different teams/environments
openstack project create --description "Development Project" dev-project
openstack project create --description "Production Project" prod-project
# Create roles that will map to FlashBlade policies
openstack role create object-admin
openstack role create object-user
openstack role create object-readonly
# Create users
openstack user create --project dev-project --password securepass alice
openstack user create --project dev-project --password securepass bob
openstack user create --project prod-project --password securepass charlie
# Assign roles to users within projects
openstack role add --project dev-project --user alice object-admin
openstack role add --project dev-project --user bob object-user
openstack role add --project prod-project --user charlie object-readonly
# Verify role assignments
openstack role assignment list --user alice --project dev-project --names

Setting Up Keystone Federation

To enable federation with Keycloak (or another IdP), configure Keystone’s identity provider and federation protocol:

# Create an identity provider in Keystone for Keycloak
openstack identity provider create --remote-id https://keycloak.example.com/auth/realms/openstack keycloak-idp
# Create a mapping between IdP attributes and Keystone entities
cat > mapping.json << 'EOF'
[
  {
    "local": [
      {
        "user": {
          "name": "{0}"
        }
      },
      {
        "projects": [
          {
            "name": "{1}",
            "roles": [
              {
                "name": "{2}"
              }
            ]
          }
        ]
      }
    ],
    "remote": [
      {
        "type": "OIDC-preferred_username"
      },
      {
        "type": "OIDC-openstack_project"
      },
      {
        "type": "OIDC-openstack_role"
      }
    ]
  }
]
EOF

openstack mapping create --rules mapping.json keystone-keycloak-mapping

# Create federation protocol

openstack federation protocol create --mapping keystone-keycloak-mapping \
  --identity-provider keycloak-idp openid

# Configure Keystone's keystone.conf for federation
# Add to [auth] section:
# methods = password,token,openid,saml2
# [federation]
# trusted_dashboard = https://horizon.example.com/auth/websso/
# sso_callback_template = /etc/keystone/sso_callback_template.html

Token Management

Users interact with Keystone to obtain tokens that prove their identity:

# User authenticates and gets a token

openstack token issue
# Sample token output shows the essential information
# Token ID, User ID, Project ID, Roles, and Expiration
# This token is what gets presented to the external IAM

# Set token as environment variable for subsequent operations

export OS_TOKEN=$(openstack token issue -f value -c id)

# Verify token details

openstack token issue -f json

# Example output:
# {
#   "expires": "2026-01-23T10:30:00+0000",
#   "id": "gAAAAABkx...",
#   "project_id": "a1b2c3d4e5f6",
#   "user_id": "u7v8w9x0y1z2"
# }

Application Credentials for Service Accounts

For automated systems or service accounts that need S3 access, use application credentials:

# Create application credential with specific roles

openstack application credential create \
  --role object-admin \
  --expiration "2026-12-31T23:59:59" \
  s3-service-account

# This generates credentials that can be used for non-interactive authentication

# The external IAM can validate these just like user tokens

This Keystone configuration establishes the identity foundation that the external IAM builds upon for FlashBlade access control.

The Federation Layer: External IAM

The external IAM system acts as a bridge between OpenStack’s identity model and FlashBlade’s S3 user management. Rather than attempting to synchronize permissions across both systems, it maintains mappings that translate OpenStack projects and roles into corresponding FlashBlade accounts and policies.

Implementing with Keycloak

Keycloak is an excellent choice for this federation layer, offering robust identity and access management capabilities that integrate naturally with both OpenStack and S3-compatible storage systems. As an open-source Identity Provider (IdP), Keycloak provides the flexibility needed to implement custom mapping logic while maintaining industry-standard protocols.

In this architecture, Keycloak serves three critical functions:

Token Validation and Federation: Keycloak can be configured to trust and validate Keystone tokens through OpenID Connect or SAML federation. When a user authenticates to OpenStack, Keystone issues a token that Keycloak can validate, establishing the federated identity relationship. This eliminates the need for users to maintain separate credentials for object storage access.

Role and Attribute Mapping: Keycloak’s mapper functionality translates OpenStack projects and roles into FlashBlade-specific attributes. Using Keycloak’s role mappers, you can define sophisticated mapping rules that consider multiple factors—project membership, role assignments, user groups, and custom attributes. For instance, Keycloak can evaluate that a user belongs to dev-project with an object-admin role and map this to the fb-dev-admin FlashBlade account with appropriate policy assignments.

Credential Management and Distribution: Keycloak can securely store and distribute the permanent S3 access keys associated with each FlashBlade account. Through custom service provider interfaces (SPIs) or protocol mappers, Keycloak retrieves the appropriate S3 credentials based on the mapped identity and returns them to the authenticated user. This centralized credential management simplifies key rotation and auditing.

Practical Mapping Implementation

Consider a typical mapping scenario: users in a dev-project with an object-admin role map to a fb-dev-admin FlashBlade account with full access policies, while users with an object-user role in the same project map to fb-dev-user with read and list permissions only. Production projects follow similar patterns with their own isolated FlashBlade accounts and restricted policies.

In Keycloak, this mapping might be implemented through:

  • Realm roles that mirror OpenStack roles (object-admin, object-user, etc.)
  • Client scopes that define which FlashBlade accounts correspond to which project-role combinations
  • Protocol mappers that inject FlashBlade account identifiers and S3 credentials into tokens
  • Custom authenticators that enforce additional security policies before granting access

Configuring Keycloak with CLI

Keycloak provides a powerful command-line admin client (kcadm.sh) for configuration. Here’s how to set up the federation mapping:

# Authenticate to Keycloak admin

kcadm.sh config credentials --server http://keycloak:8080/auth \
  --realm master --user admin --password admin

# Create a realm for OpenStack integration

kcadm.sh create realms -s realm=openstack -s enabled=true

# Create realm roles that mirror OpenStack roles

kcadm.sh create roles -r openstack -s name=object-admin \
  -s description="FlashBlade full access role"

kcadm.sh create roles -r openstack -s name=object-user \
  -s description="FlashBlade read-only role"

# Create a client for FlashBlade S3 access

kcadm.sh create clients -r openstack \
  -s clientId=flashblade-s3 \
  -s enabled=true \
  -s protocol=openid-connect \
  -s publicClient=false \
  -s serviceAccountsEnabled=true

# Add client scope for FlashBlade account mapping

kcadm.sh create client-scopes -r openstack \
  -s name=flashblade-mapping \
  -s protocol=openid-connect

# Create protocol mapper to inject FlashBlade account ID

kcadm.sh create clients/{CLIENT_ID}/protocol-mappers/models -r
openstack \
  -s name=fb-account-mapper \
  -s protocol=openid-connect \
  -s protocolMapper=oidc-usermodel-attribute-mapper \
  -s 'config."claim.name"=fb_account' \
  -s 'config."user.attribute"=flashblade_account' \
  -s 'config."jsonType.label"=String'

# Create role mapper for object-admin -> fb-dev-admin

kcadm.sh create clients/{CLIENT_ID}/protocol-mappers/models -r 
openstack \
  -s name=admin-role-mapper \
  -s protocol=openid-connect \
  -s protocolMapper=oidc-hardcoded-claim-mapper \
  -s 'config."claim.name"=fb_account' \
  -s 'config."claim.value"=fb-dev-admin' \
  -s 'config."access.token"=true'

Federated Identity Configuration

To establish trust between Keystone and Keycloak:

# Add Keystone as an identity provider (SAML example)

kcadm.sh create identity-provider/instances -r openstack \
  -s alias=keystone \
  -s providerId=saml \
  -s enabled=true \
  -s 'config.singleSignOnServiceUrl=https://keystone.example.com/v3/OS-FEDERATION/identity_providers/keycloak/protocols/saml/auth' \
  -s 'config.nameIDPolicyFormat=urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress'

# Create identity provider mapper to extract OpenStack project

kcadm.sh create identity-provider/instances/keystone/mappers -r openstack \
  -s name=project-mapper \
  -s identityProviderAlias=keystone \
  -s identityProviderMapper=saml-user-attribute-idp-mapper \
  -s 'config."attribute.name"=openstack_project' \
  -s 'config."user.attribute"=project'

Managing User Attributes

Store FlashBlade credentials as user attributes:

# Set FlashBlade account and S3 key for a user

kcadm.sh update users/{USER_ID} -r openstack \
  -s 'attributes.flashblade_account=["fb-dev-admin"]' \
  -s 'attributes.s3_access_key=["AKIAIOSFODNN7EXAMPLE"]' \
  -s 'attributes.s3_secret_key=["wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"]'

# Query user to verify attributes

kcadm.sh get users/{USER_ID} -r openstack

Security Note: In production environments, S3 credentials should be stored in a secure credential vault (like HashiCorp Vault) and retrieved dynamically via Keycloak’s Vault SPI rather than stored as plain user attributes.

The IAM layer validates incoming Keystone tokens, determines the appropriate FlashBlade user based on these mappings, and either issues or retrieves the permanent S3 credentials for that user. This approach ensures OpenStack tokens never directly manage S3 permissions—they simply prove identity.

Alternative IdP Solutions

While Keycloak is recommended for its flexibility and OpenStack integration capabilities, other identity providers can fulfill this federation role:

  • Auth0 provides sophisticated role mapping and can integrate with custom credential stores through Rules and Actions
  • Okta offers enterprise-grade identity federation with strong audit capabilities and extensive API support
  • Azure AD / Entra ID works well for organizations already invested in Microsoft’s ecosystem
  • Custom IAM services built on frameworks like Spring Security or Django can provide complete control over mapping logic

Regardless of the chosen IdP, the core requirements remain consistent: validate OpenStack identity assertions, map them to FlashBlade accounts, and securely distribute S3 credentials based on those mappings.

Setting Up FlashBlade S3 Users

Before any bucket operations can occur, S3 users must exist on FlashBlade with permanent access keys. The FlashBlade CLI provides straightforward commands for this:

# Create a user in the FlashBlade object store
pureobj secure-user create fbaccount/myuser
# Generate a permanent S3 access key
pureobj secure-user access-key create fbaccount/myuser
# Verify the access keys
pureobj secure-user access-key list fbaccount/myuser

Permanent keys eliminate the complexity of ephemeral token exchanges and reduce operational overhead in multi-tenant environments. Each OpenStack user mapping should have at least one S3 key, and the external IAM can automate this provisioning process as new users and projects are created.

Configuring Access Policies

FlashBlade enforces permissions through policies that must be assigned before users can perform any bucket or object operations. Pure provides predefined policies for common access patterns:

  • pure:policy/full-access — Complete S3 permissions for all buckets and objects
  • pure:policy/object-read — Read object data and metadata
  • pure:policy/object-write — Create and modify objects
  • pure:policy/object-delete — Delete objects
  • pure:policy/bucket-create — Create new buckets
  • pure:policy/bucket-list — List all available buckets

Assigning these policies is straightforward:

# Grant object write permission
purepolicy obj access add --user fbaccount/myuser pure:policy/object-write
# Grant bucket creation permission
purepolicy obj access add --user fbaccount/myuser pure:policy/bucket-create
# Review assigned policies
purepolicy obj access list --user fbaccount/myuser

Without appropriate policies, users cannot create buckets or objects—the system fails closed, ensuring security by default.

Working with Buckets and Objects

Once users have permanent S3 credentials and assigned policies, they can perform standard S3 operations using familiar tools like the AWS CLI:

# Create a bucket
aws s3api create-bucket \
  --bucket mybucket \
  --endpoint-url https://flashblade.example.com \
  --profile fbuser
# Upload an object
aws s3 cp localfile.txt s3://mybucket/ \
  --endpoint-url https://flashblade.example.com \
  --profile fbuser
# List bucket contents
aws s3 ls s3://mybucket/ \
  --endpoint-url https://flashblade.example.com \
  --profile fbuser
# Delete an object
aws s3 rm s3://mybucket/localfile.txt \
  --endpoint-url https://flashblade.example.com \
  --profile fbuser

FlashBlade validates each request against the user’s assigned policies. The OpenStack roles only matter during the initial provisioning step when the external IAM determines which S3 identity to assign.

Advanced Policy Customization

For more granular control, administrators can create custom policies with specific actions, resources, and conditions. Actions correspond to S3 API calls (like s3:CreateBucket or s3:PutObject), while resources define which buckets and objects the actions apply to:

# Restrict write access to a specific bucket and object
purepolicy obj access rule add \
  --action s3:PutObject \
  --rule-name writeRule01 \
  --resource mybucket/myobject \
  fbaccount/myPolicy

Conditions add context-aware constraints such as source IP ranges, S3 prefixes, or delimiters:

# Allow listing only objects with "dev-" prefix from specific subnet
purepolicy obj access rule add \
  --action s3:ListBucket \
  --rule-name listRule01 \
  --resource mybucket \
  --s3-prefix dev- \
  --source-ip 10.0.0.0/24 \
  fbaccount/myPolicy

These granular controls enable sophisticated multi-tenant scenarios where different teams need varying levels of access to shared or isolated resources.

The Complete Access Flow

Understanding the end-to-end process helps clarify how the components interact:

  1. A user authenticates to Keystone and receives a token
  2. The user presents this Keystone token to the external IAM
  3. The IAM validates the token and maps the user’s project and role to a FlashBlade S3 account
  4. The IAM retrieves the permanent S3 access key for that FlashBlade account
  5. The user performs bucket and object operations using standard S3 tools
  6. FlashBlade enforces the assigned policies for each operation

This flow maintains security while keeping the user experience simple. Users don’t need to understand the underlying mappings—they authenticate once to OpenStack and gain transparent access to object storage.

Quick Reference: Essential Commands

TaskCommand
Create S3 userpureobj secure-user create fbaccount/myuser
Create access keypureobj secure-user access-key create fbaccount/myuser
List access keyspureobj secure-user access-key list fbaccount/myuser
Assign predefined policypurepolicy obj access add --user fbaccount/myuser pure:policy/object-write
Create bucketaws s3api create-bucket --bucket mybucket --endpoint-url https://flashblade.example.com
Upload objectaws s3 cp file.txt s3://mybucket/ --endpoint-url https://flashblade.example.com
List objectsaws s3 ls s3://mybucket/ --endpoint-url https://flashblade.example.com

Key Considerations

Three principles underpin this integration approach:

Permanent credentials simplify operations. By using long-lived S3 access keys instead of ephemeral tokens, you eliminate the complexity of constant credential rotation and renewal. This reduces the operational burden on both the IAM layer and end users.

Policies must precede access. FlashBlade requires policies to be assigned before users can create buckets or manipulate objects. This fail-closed approach prevents accidental exposure and ensures explicit authorization for all operations.

External IAM is essential for multi-tenancy. The federation layer provides the necessary isolation and mapping between OpenStack’s project-based model and FlashBlade’s account structure. Without it, maintaining secure multi-tenant object storage becomes unwieldy.

By following this architecture and understanding how the components interact, you can provide OpenStack users with robust, scalable object storage backed by FlashBlade’s performance and reliability, all while maintaining the security and isolation that enterprise environments demand.

Leave a Reply

Your email address will not be published. Required fields are marked *

Published by Simon