Hello o/ Interesting find, this is somewhat complex and it’s not clear to me if this was intentional during the design or not.
A Barbican secret is in fact owned by a Keystone user and not by the project, even if the secret is “placed in the project” nobody in the project actually has access to the secret except for the owner unless the project-access is set to True on the secret in Barbican. This is why a user with access to the project needs to create a Barbican ACL that allows the rgw_keystone_barbican_user configured user read access on the secret regardless of project. So while the secret in theory might be "in the project", it’s not sure a certain that the secret itself can be used by anybody in the project, which I assume also is somewhat of a flaw on the RGW implementation, as this was assumed during design(?). I do not have enough history or can’t find any specification when the feature was designed if any of this was already considered, perhaps Casey (cc) has history on the topic? So if we go by the route that the we wan’t to restrict – we need to take into account that, due to it’s long history and how this works now – any S3 consumer (keystone user accessing the S3 API) might be using a Barbican secret of a project it’s not a member of, as read acl on the secret has been shared to the rgw_keystone_barbican_user user. So we need to be thorough here as this, in it’s current form, will be a breaking change. I don’t know if you can actually retrieve the encrypted data from S3, and as such, be privy access to data encrypted by a secret and then use that for bruteforcing the secret itself, one potential attack vector I see here is that if you also have the Swift API enabled you can just download the object using the Swift API and it will be encrypted and thus get access to the encrypted blob of the object. /Tobias > On 17 Oct 2025, at 10:21, Vignesh Varma <[email protected]> wrote: > > Hi Team, > > Lab Environment > > * Ceph: 19.2.x (Squid) > * OpenStack: Caracal > * OS: Ubuntu 22.04 LTS > * Deployment: `cephadm` > > --- > > Setup Summary > > We have a working Ceph RGW + Barbican integration with: > > * Keystone auth: `rgw_s3_auth_use_keystone = true` > * SSE-KMS backend: `rgw_crypt_s3_kms_backend = barbican` > * Single RGW Barbican service user under a single project: > > ``` > rgw_keystone_barbican_user = rgw-barbican > rgw_keystone_barbican_project = service > rgw_keystone_barbican_domain = default > rgw_barbican_url = http://controller:9311 > rgw_crypt_s3_kms_backend = barbican > rgw_crypt_s3_kms_encryption_keys = > {"coke":"<COKE_KEY_ID>","pepsi":"<PEPSI_KEY_ID>"} > rgw_crypt_require_ssl = false > ``` > > Each tenant (e.g., Coke, Pepsi) has: > > * Its own OpenStack project > * Separate EC2 credentials > * Its own Barbican AES-256 key (with `rgw-barbican` added to the secret ACL > for read) > > S3 operations work for both tenants using their own EC2 credentials. > > --- > > Observed Issue > > Cross-tenant Barbican key usage is allowed: > > | Tenant | Key Used | Result | > | ----------------- | ---------- | -------------- | > | Coke → Coke key | ✅ Success | expected | > | Pepsi → Pepsi key | ✅ Success | expected | > | Coke → Pepsi key | ⚠️ Success | unexpected | > | Pepsi → Coke key | ⚠️ Success | unexpected | > > If a client supplies any valid Barbican key UUID (one that `rgw-barbican` can > read via ACL), RGW accepts it—even if the key belongs to a different project. > This suggests RGW does not validate that the Barbican key is owned by (or > scoped to) the same project as the authenticated S3 user. > > --- > > Minimal Repro > > 1. Create projects `coke` and `pepsi`; create per-project EC2 creds. > 2. Store one Barbican key per project; grant `rgw-barbican` read ACL on both > secrets. > 3. Configure RGW as above with the `rgw_crypt_s3_kms_encryption_keys` > mapping. > 4. Using Coke EC2 creds, run `put-object` with Pepsi key UUID via > `--ssekms-key-id <PEPSI_KEY_ID>`. > → Upload succeeds; encryption uses Pepsi key. > > --- > > What We Need > > * A way for RGW to validate that the SSE-KMS key used in the request belongs > to the same OpenStack project (tenant) as the authenticated S3 user. > * Cross-project use of KMS keys should fail with `AccessDenied` (or similar). > > --- > > Questions for Guidance > > 1. Is there a supported (or planned) way to restrict RGW so the Barbican key > must belong to the same project as the authenticated S3 user? > 2. Can RGW be configured to derive the project scope from the S3 auth context > when requesting the key from Barbican (instead of always using the fixed > `rgw_keystone_barbican_project` for the token)? > > --- > > Best Regards, > Vignesh > _______________________________________________ > ceph-users mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ ceph-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
