Backport/tentacle 20.2.4 cobaltcore storage/keystone project reader

PendingReleaseNotes

@@ -1,3 +1,16 @@
+* RGW: New config option ``rgw_keystone_accepted_project_reader_roles``.
+  A Keystone user whose only access-granting role is one of the configured project-reader
+  roles is capped to read-only access within its project, mirroring the
+  ``project_reader_roles`` behavior of Swift's keystoneauth middleware. A bucket
+  policy naming the user can still grant additional access. The reader role
+  admits the user on its own; it need not also be in
+  ``rgw_keystone_accepted_roles``.
+* RGW: New config option ``rgw_keystone_implicit_deny_roles``.
+  A Keystone user whose only access-granting role is one of the configured
+  implicit-deny roles is authenticated but granted no implicit permissions.
+  Access must be granted explicitly through a bucket policy or IAM policy, and
+  applies only to the buckets and objects the policy names. The role admits the
+  user on its own.
 * ceph-volume: Raw BlueStore OSD preparation now pre-formats NVMe devices and
   skips the slower BlueStore discard phase,reducing mkfs time on
   very large namespaces.

doc/radosgw/keystone.rst

@@ -54,6 +54,88 @@ only use implicit tenants, and the other protocol will
 never use implicit tenants.  Some older versions of ceph
 only supported implicit tenants with swift.
 
+Project-scoped reader role
+--------------------------
+
+By default any Keystone user accepted by the gateway is granted full control
+over its project's object storage. ``rgw keystone accepted project reader
+roles`` designates one or more Keystone roles as *project-scoped readers*
+(the Swift ``project_reader_roles`` equivalent)::
+
+   rgw keystone accepted roles = member
+   rgw keystone accepted project reader roles = objectstore_viewer
+
+When the reader role is the only access-granting role a user holds, the user
+is capped to read-only within its Keystone project: it may read objects and
+inspect bucket configuration (ACLs, policy, versioning, location, ...), but
+not write. Every user of a project maps to the same RGW account (the project
+itself), so a reader lists and reads every bucket the project owns through the
+normal owner-scoped paths, and cannot reach another project (a different
+owner). This scoping is by ownership and holds regardless of ``rgw keystone
+implicit tenants``, which only controls the bucket-name namespace: with it
+off, a reader reaching another project's bucket gets ``403`` (the bucket is
+in the shared namespace, visible but not owned); with it on, it gets ``404``
+(the bucket is in a separate namespace and not visible). Either way the
+reader stays confined to its own project.
+
+Note the following:
+
+- **A project reader role admits the user on its own.** It need not also
+  appear in ``rgw keystone accepted roles`` (mirroring Swift's
+  ``project_reader_roles``): a user whose only granting role is a project
+  reader role is admitted and capped to read-only.
+
+- **The cap is a floor, not a hard ceiling.** A bucket policy that names the
+  user (via a ``keystone:userid`` / ``keystone:role`` condition or a principal
+  ARN) can still grant specific actions such as writes on specific buckets;
+  an explicit policy ``Deny`` can likewise remove access. Only bucket creation
+  and Swift account-metadata writes are refused up front regardless of policy.
+
+- **A role that grants more than read overrides the cap.** If the same user
+  also holds ``admin`` or any other role in ``rgw keystone accepted roles``
+  (for example ``member``), that role wins and the user receives full control.
+  To keep a user read-only, assign it *only* the reader role. Roles that are
+  in no accepted list at all are ignored and do not affect the cap.
+
+Implicit-deny roles
+-------------------
+
+``rgw keystone implicit deny roles`` designates Keystone roles
+that authenticate a user without granting any implicit permissions::
+
+   rgw keystone accepted roles = member
+   rgw keystone implicit deny roles = objectstore_authenticated
+
+A user whose only access-granting role is such a role is denied every
+operation by default. Access must be granted explicitly through a bucket
+policy or IAM policy (for example with a ``keystone:userid`` or
+``keystone:role`` condition), and an explicit ``Allow`` then applies only to
+the buckets and objects the policy names. Unlike a project reader, a user
+with only an implicit-deny role cannot list the buckets of its project;
+bucket creation and Swift account-metadata writes are always refused.
+
+The project-reader notes above apply here as well: the role admits the user
+on its own (no co-listing in ``rgw keystone accepted roles`` needed), an
+explicit policy ``Deny`` always wins, and any role granting more (``admin``,
+a project reader role, or another accepted role such as ``member``) takes
+precedence over the implicit-deny cap.
+
+.. note:: These tiers cap what a request may do at authorization time. They
+   apply to the default Keystone mapping, where each project maps to a plain
+   tenant-scoped gateway user reaching the gateway over S3 or Swift. They do
+   **not** apply in the following cases:
+
+   - **The librgw frontend (NFS-Ganesha).** It authorizes every request with
+     full control, so a gateway reached over that path is not capped. Assign
+     these roles only where clients use S3 or Swift.
+   - **Keystone users associated with an** :doc:`RGW account <account>`.
+     Access for an account is governed entirely by IAM policy (evaluated
+     before the permission mask), so the tiers place no cap there. Use them
+     with the default (non-account) mapping.
+   - **The** ``radosgw-admin`` **command and the admin REST API.** These are
+     backend administration paths that do not authenticate a Keystone user,
+     so they are not subject to these roles at all.
+
 Ocata (and later)
 -----------------
 

doc/radosgw/s3/authentication.rst

@@ -216,6 +216,26 @@ access the same resources when things like Swift user ACLs are in
 play. This is one of the many reasons that you should use S3 bucket
 policies rather than S3 ACLs when possible.
 
+The SNS topic actions are mapped the same way, so that the Keystone
+project-reader role (see :ref:`radosgw-keystone`) can inspect topics but
+not modify them:
+
++---------------------------------------+---------------+
+| Operation                             | Permission    |
++=======================================+===============+
+| ``sns:GetTopicAttributes``            | ``READ``      |
++---------------------------------------+---------------+
+| ``sns:ListTopics``                    | ``READ``      |
++---------------------------------------+---------------+
+| ``sns:CreateTopic``                   | ``WRITE``     |
++---------------------------------------+---------------+
+| ``sns:SetTopicAttributes``            | ``WRITE``     |
++---------------------------------------+---------------+
+| ``sns:DeleteTopic``                   | ``WRITE``     |
++---------------------------------------+---------------+
+| ``sns:Publish``                       | ``WRITE``     |
++---------------------------------------+---------------+
+
 
 .. _Authenticating Requests (AWS Signature Version 4): https://docs.aws.amazon.com/AmazonS3/latest/API/sig-v4-authenticating-requests.html
 .. _Authenticating requests (AWS signature version 2): https://docs.aws.amazon.com/AmazonS3/latest/userguide/auth-request-sig-v2.html

release-management/backports/01a18d83-9554-7c5f-8407-f6a30b7f3c9f.md

@@ -0,0 +1,53 @@
+---
+id: 01a18d83-9554-7c5f-8407-f6a30b7f3c9f
+title: Keystone Project RO/Viewer role + Implicit Deny
+component: rgw
+category: feature
+provenance:
+  type: upstream_pr
+  upstream_prs:
+  - https://github.com/ceph/ceph/pull/70372
+  upstream_pr_state: merged-main
+  upstream_commits:
+  - 87252a5deac6450dafc5d2e279aa0671509d1c1a
+  - ba0c6ade977334f9b5cd01d5dc56354c9ad43507
+  - dcc1de7d4d28bf825b1479cf48018c4ab847bf6a
+  previous_backport: 01a14417-d161-7221-87ad-c32f7e8170ec
+justification:
+  type: customer
+  refs:
+  - cobaltcore-dev/cloud-storage#566
+risk:
+  blast: availability
+  conflict: substantive
+  coverage: strong
+---
+
+## Justification (public)
+
+Adds two Keystone roles: a project reader (`rgw_keystone_accepted_project_reader_roles`), read-only by default, and an implicit-deny role (`rgw_keystone_implicit_deny_roles`), no access by default. Both can be granted more through bucket policy using `keystone:userid` or `keystone:role`.
+
+## Justification (internal)
+
+Customer roadmap feature, mirroring Swift's `project_reader_roles`.
+
+## Risk notes
+
+**blast: availability** — off by default, but it changes how permissions are computed for every Keystone user. A mistake could remove access; no data is at risk.
+
+**conflict: substantive** — tentacle lacks some newer upstream code, so STS, SNS topics and the new unit test needed small manual adaptations. Merged code matches upstream otherwise.
+
+**coverage: strong** — unit tests and live tests against RGW and Keystone pass. They cover read-only and no-access defaults, policy overrides by `keystone:userid` and `keystone:role`, `Deny` precedence and cross-project isolation.
+
+## Behavior change
+
+Two new options, empty by default:
+
+- `rgw keystone accepted project reader roles` — user is read-only within its project.
+- `rgw keystone implicit deny roles` — user has no access without an explicit policy grant.
+
+The most permissive accepted role wins (`member` or `admin` gives full control). A bucket policy naming the user or role can grant more, for that bucket only. Bucket creation and STS `AssumeRole` are always refused for these users.
+
+## Upgrade notes
+
+None. Both options default to empty.

src/common/options/rgw.yaml.in

@@ -879,7 +879,40 @@ options:
 - name: rgw_keystone_accepted_reader_roles
   type: str
   level: advanced
-  desc: List of roles that can only be used for reads (Keystone).
+  desc: Keystone roles granting system-scoped read access.
+  long_desc: >-
+    Keystone roles granting system-scoped read access (Swift
+    system_reader_roles equivalent). The role must also be listed in
+    rgw_keystone_accepted_admin_roles.
+  services:
+  - rgw
+  with_legacy: true
+- name: rgw_keystone_accepted_project_reader_roles
+  type: str
+  level: advanced
+  desc: Keystone roles granting project-scoped read-only access.
+  long_desc: >-
+    Keystone roles granting project-scoped read-only access (Swift
+    project_reader_roles equivalent). A role here admits the user on its own
+    and caps it to read-only. This is a floor, not a hard cap: a bucket
+    policy naming the user can grant more. All members of a project map to
+    the same RGW account (the project), so the reader sees every bucket that
+    account owns; this scoping is by ownership and holds regardless of
+    rgw_keystone_implicit_tenants, which only controls the bucket-name
+    namespace.
+  services:
+  - rgw
+  with_legacy: true
+- name: rgw_keystone_implicit_deny_roles
+  type: str
+  level: advanced
+  desc: Keystone roles granting no implicit permissions.
+  long_desc: >-
+    Keystone roles that authenticate a user without granting any implicit
+    permissions. A role here admits the user on its own; a user whose only
+    access-granting role is such a role is authenticated but denied every
+    operation by default, so access must be granted explicitly through a
+    bucket policy or IAM policy.
   services:
   - rgw
   with_legacy: true