Assigning cronus user to cloud_admin project with object storage role…

[dhalimi]

… to support incoming emails.

[wagnerd3]

How were users' keystone tokens validated in the past? I imagine users already come to Cronus with a keystone token?

[sapmli]

Yes, and Cronus already used the service role here

[wagnerd3]

If you do everything else in your application with a technical user scoped to master@ccadmin, there is no reason to switch this to cloud_admin@ccadmin - it's actually better to only use the scope of cloud_admin when you need it, i.e. accessing the users' object store.

[kayrus]

also cloud_admin is not recommended to be used as payload/resource storage

[sapmli]

We would need both (user token validation) and accessing the user's object store's both in a single instance at the same time, and we also need to do it permanently (e.g. when storing an incoming email).
I think it doesn't make sense to switch between the OS projects all the time.
We would not need to store anything in cloud_admin project. @kayrus

Could we just add the cloud_objectstore_admin role to the cronus user in ccadmin/master instead, or will this not be effective then?

[sumitarora2786]

I am not too expert with regards to which project should be used here, admin, cloud_admin or master..
but with respect to permissions, can this be sorted also with objectstore_admin, that also gives enough permissions to operations on buckets.

[kayrus]

@bbobrov could you please check this PR?

[wagnerd3]

Idea: the user should come to Cronus with a token, that has admin rights for object storage, and grant the necessary permissions to a cronus technical user. This technical user could then be subsequently used to operate in the users' object store.

[kayrus]

IMHO, the decision to grant a technical user access to storage should remain firmly in the hands of the customer, and should be controlled at the bucket/container level. If a security incident occurs, the blast radius could be significant. Granting full admin access across all containers in all regions is a major security concern and not something I'd recommend.

cc @drochow

[dhalimi]

IMHO, the decision to grant a technical user access to storage should remain firmly in the hands of the customer, and should be controlled at the bucket/container level. If a security incident occurs, the blast radius could be significant. Granting full admin access across all containers in all regions is a major security concern and not something I'd recommend.

cc @drochow

Is there a role that is limited to writing only? @kayrus, is it still a security concern?

[kayrus]

Is there a role that is limited to writing only?

no

is it still a security concern?

yes. a customer must decide whether to allow a technical user to access buckets or not. or there should be an ability to configure email service to consume customers' credentials.

[dhalimi]

Hi @sumitarora2786, can we create objectstore_write, which is limited to writing objects to buckets?

[kayrus]

can we create objectstore_write

no

[majewsky]

The comment is incorrect. This will only give you access to containers in this project. If you need access to all containers in all projects, you need cloud_objectstore_admin in the scope cloud_admin@ccadmin. (And then you need to traverse account scopes on the Swift API level, see e.g. here in Keppel.)

Alternatively, you could implement a scheme where you get objectstore_admin permissions in each relevant customer project, either by using the user's permissions during an initial setup step to create the role assignment, or by having cloud-admin privileges to Keystone on your service user (for reference, Castellum does the latter in this method).

[dhalimi]

Hi @majewsky,

In the second option, regarding role assignments, do we require the admin role in order to add the default@cronus user to an SCI project with the objectstore_admin role?

@sapmli, could you please confirm that this is all that’s required for incoming emails?

[sapmli]

Hard to tell, because it would require the cloud_admin role to be attached at least somewhere (QA region)...