RGW admin capabilities

Why this matters in production

The admin REST API is how self-service portals and automation manage RGW users and buckets without shell access to a Ceph node. Capabilities are what scope that access, and granting them broadly hands over the whole deployment.

Granting

radosgw-admin caps add --uid=portal --caps="users=read,write"
radosgw-admin caps add --uid=portal --caps="buckets=read"
radosgw-admin caps add --uid=auditor --caps="usage=read;metadata=read"

radosgw-admin user info --uid=portal | jq '.caps'
radosgw-admin caps rm --uid=portal --caps="users=write"

The capability types

Each takes read, write, or read,write.

metadata=write is the dangerous one: it permits direct manipulation of the metadata objects underlying users and buckets, bypassing the consistency the higher-level operations maintain.

Using the admin API

# list users
curl -s -X GET "https://rgw.example.com/admin/user?format=json" \
     --aws-sigv4 "aws:amz:default:s3" \
     --user "$ACCESS_KEY:$SECRET_KEY"

# create a user
curl -s -X PUT "https://rgw.example.com/admin/user?uid=newuser&display-name=New%20User" \
     --aws-sigv4 "aws:amz:default:s3" \
     --user "$ACCESS_KEY:$SECRET_KEY"

# bucket statistics
curl -s -X GET "https://rgw.example.com/admin/bucket?stats=true&format=json" \
     --aws-sigv4 "aws:amz:default:s3" \
     --user "$ACCESS_KEY:$SECRET_KEY"

Requests are signed with the capable user’s S3 credentials, so the admin API needs no separate authentication mechanism.

Scoping for automation

Grant only what the automation calls. A provisioning service does not need buckets=write, and a reporting service does not need users=write.

Auditing

for u in $(radosgw-admin user list | jq -r '.[]'); do
  caps=$(radosgw-admin user info --uid="$u" | jq -c '.caps')
  [ "$caps" != "[]" ] && printf '%-24s %s\n' "$u" "$caps"
done

Any user with capabilities is an administrative identity and belongs in the same review as cephx entities with elevated privileges.

Quiz

Production discipline

Treat any RGW user holding capabilities as an administrative identity and include it in the same access review as elevated cephx entities. Grant capabilities from the functions the automation actually performs and add only what demonstrably fails, rather than granting broadly to avoid a second conversation.

Cross-course references

• Kubernetes: a controller ServiceAccount scoped to the verbs it calls follows the same discipline
• Linux: sudo rules listing specific commands rather than ALL is the identical practice