Project

General

Profile

Actions

Feature #62727

closed

Associate notification and topics to an AWS user.

Added by Krunal Chheda 8 months ago. Updated 3 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
Target version:
-
% Done:

0%

Source:
Community (dev)
Tags:
notification
Backport:
Reviewed:
Affected Versions:
Pull request ID:

Description

As part of notification workflow, an AWS user first creates a TOPIC using create_topic() and then subscribes the bucket to topic created using put_bucket_notification_configuration().
Currently when the topic is created, the user information is not stored in the topic rados object, so any user can modify/delete that topic as there is no permission check. To avoid this scenario, it would make sense to hook up AWS user to the topic and not allow any other user to modify/delete the topic owned by itself (apart from radosgw-admin that has admin permission to delete the topic)

The second part is to limit the bucket notification to subscribe to only topics created by the itself. Currently an USER A that has access to a bucket can set up notification on that bucket, and as part of setup it can subscribe the bucket to a topic created by ANY OTHER user. This means any user has potential of spamming any topic broker that it doesn't own. To limit this, an option would be to allow an user to subscribe any bucket to TOPICs that are OWNED by itself.


Related issues 1 (1 open0 closed)

Related to rgw - Support #64547: List topic New

Actions
Actions #1

Updated by Krunal Chheda 8 months ago

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.

Actions #2

Updated by Yuval Lifshitz 8 months ago

according to this: https://docs.aws.amazon.com/sns/latest/api/API_CreateTopic.html
the policy is passed an one of the topic's attributes. this means that there is no validation at the SDK level, as the policy is just a string.
the format of the policy would be following the standard iam policies, and will cover:
  • 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.

optional features:
  • 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" 
    ]
  }]
}

Actions #3

Updated by Krunal Chheda 8 months ago

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

Actions #4

Updated by Krunal Chheda 6 months ago

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.

Actions #5

Updated by Yuval Lifshitz 6 months ago

  • Status changed from New to Fix Under Review
  • Assignee set to Krunal Chheda
  • Pull request ID set to 53848
Actions #6

Updated by Casey Bodley 3 months ago

  • Status changed from Fix Under Review to Resolved
Actions #7

Updated by Casey Bodley 2 months ago

Actions

Also available in: Atom PDF