Ceph » rgw

As discussed in rgw refactoring meeting on 09/06/2023, associating AWS user to a topic seems reasonable and going forward any AWS user that created the topic will be the owner that has permission to modify/delete the topic. To maintain backward compatibility, the permission check will be only applicable for the topic that currently have the user information stored in them, if the user information is not stored, that topic could still be modified/deleted by anyone.

On the bucket front, @Yuval is exploring options on whether create_topic() api supports policies where it can setup policy that allows a AWS user to access the topic, if SDK supports enforcing policies, then the bucket notification can be setup on topics that users owns or user has access to access.

• who is allowed to update the topic ("Action": "sns:CreateTopic") - call create topic on an already existing topic
• who is allowed to access the topic ("Action": "sns:GetTopicAttributes")
• who is allowed to delete the topic ("Action": "sns:DeleteTopic")
• who is allowed to publish to the topic ("Action": "sns:Publish") - this will determine which user may create a bucket notification configuration usign that topic

in AWS, if no policy is set, the default behavior is that only the owner can perform the above actions. however, to preserve backward compatibility in ceph, we should allow topics that are used with an anonymous user (they are actually created with a user, but the user is not stored in them, as in release "reef" and below) to allow all actions from all users.
however, starting from squid, we should follow the more restrictive behavior.

• implement the AddPermission API (see: https://docs.aws.amazon.com/sns/latest/api/API_AddPermission.html) so that policies could be added to a topic in a more structured way (not as a JSON string). if we implement this API, we should also support the ("Action": "sns:AddPermission") policy action, to control who can add policies to the topic other than the owner
• add a global conf variable to revert the default behavior to "allow all", and use the more restrictive behavior only if policy is set on a topic. this is to make it easier for deployments that do not want to handle topic policies at all

policy example for allowing other users to read the topic:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"AWS": ["arn:aws:iam::usfolks:user/fred:subuser"]},
    "Action": "sns:GetTopicAttributes",
    "Resource": [
      "arn:aws:sns:::mytopic" 
    ]
  }]
}

policy example for allowing other users set a bucket notification using a topic:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"AWS": ["arn:aws:iam::usfolks:user/fred:subuser"]},
    "Action": "sns:Publish",
    "Resource": [
      "arn:aws:sns:::mytopic" 
    ]
  }]
}

As discussed with Yuval, its much more clean and easier to implement the AddPermission() and RemovePermission() while managing acls' for topic and notification both.
So will try to support those 2 API which would help in associating the ownership for the topic and notifications

Krunal Chheda wrote:

As discussed with Yuval, its much more clean and easier to implement the AddPermission() and RemovePermission() while managing acls' for topic and notification both.
So will try to support those 2 API which would help in associating the ownership for the topic and notifications

After further reviewing of code, it made more sense to just hook up the notification to support the setting IAM policy just like setting BucketPolicy by passing the JSON policy string to CreateTopic()/SetTopicAttribute(). So as part of [https://github.com/ceph/ceph/pull/53848] adding support for setting policy via CreateTopic/SetTopicAttribute by sending the policy as JSON str. AddPermission() and RemovePermission() will be supported LATER.