Swift ACL
Overview
In this guide we will go through how to manage user permissions for Swift containers using ACLs.
Due to current limitation of how privilege/role management works, the way to go is to create a separate “Swift project”.
The purpose of so called “Swift projects” ("
The Swift project can be used in two ways - to store/manage Swift containers and/or manage Swift-only users.
How to manage permissions via ACLs
If you want a user to be able to create, manage and upload/download objects for any Swift containers created in the Swift project, inviting and assigning the user the role “Object Store” (known as “swiftoperator” in the API/CLI) in “Management” -> “Access Control” -> “Project Users” should be sufficient.
If you instead want a user to be able to read and/or write to a specific Swift containter created in the Swift project or any another project you have, you will need to invite the user to the Swift project, assign them the role “Project Member” and configure Swift container ACLs for the target container(s). We’ll go through an example below.
In order to configure Swift ACLs you will need:
- A user with the “Object Store” (“swiftoperator”) role in the project that contains the container you want to restrict/provide access to
- The Swift CLI or another API client capable of configuring ACLs (this is currently not supported through Horizon)
- An OpenStack RC file (openrc), “clouds.yml” or environment variables set for authenticating towards the API as the user used to configure ACLs
- Name of the container you want to configure ACLs for
- ID of the project in which the container is stored and the ID for the Swift project if they are not the same (listed under “Identity” -> “Projects” in Horizon or
openstack project list
via the CLI) - ID of the user you want to restrict/provide access for (accessible through “Identity” -> “Users” in Horizon as that user)
In the following example we’ll use the Swift CLI to configure read/write/list access to a specific container created in the Swift project
# Using variables here to make it easier to follow/adapt to new service users and Swift containers
$ SWIFT_PROJECT_ID="b71cd232c8544cf28a7d7aad797cafe9"
$ SWIFT_CONTAINER_NAME="test-container-1"
$ TARGET_USER_ID="whatever_id_it_has"
# Explicitly specifying project ID here, in-case you use an OpenRC/clouds.yml file downloaded from your other projects
$ OS_PROJECT_ID="${SWIFT_PROJECT_ID}" swift post "${SWIFT_CONTAINER_NAME}" --read-acl ".rlistings,${SWIFT_PROJECT_ID}:${TARGET_USER_ID}" --write-acl "${SWIFT_PROJECT_ID}:${TARGET_USER_ID}"
If you want to provide/restrict access to a container that has been created in another project, the process is similar:
# Specifying the ID for the other project instead
$ OS_PROJECT_ID="<project-id>" swift post "${SWIFT_CONTAINER_NAME}" --read-acl ".rlistings,${SWIFT_PROJECT_ID}:${TARGET_USER_ID}" --write-acl "${SWIFT_PROJECT_ID}:${TARGET_USER_ID}"
Note: Replace <project-id>
with the actual Project ID
If you need any clarification, further guidance or have other questions, feel free to reach out to our support.
Known limitations
Currently, cross-project ACLs don’t work if you want to use the S3 compatibility.