Combining IAM and bucket policies to set up granular access to Object Storage

Scaleway Object Storage allows you to manage access to your resources with two features, Identity and Access Management (IAM) and Bucket policies.

You can use IAM when you do not need to configure access to specific buckets, and favor simplicity over granularity. IAM is central, and relies on policies to manage a principal’s rights in the entire Scaleway ecosystem.

Bucket policies operate at the bucket level, and enable you to state clearly who can do what in each bucket.

To configure more granular access to your Object Storage buckets, you can combine both IAM and bucket policies.

Bucket policies and IAM overview

IAM

Identity and Access Management (IAM) allows you to control and manage access to your resources. For users of Scaleway Object Storage, this means that besides configuring access via bucket policies, you can use IAM policies to configure permissions at the Project level.

An IAM policy is used to define the permissions of users, groups, and applications in a given Organization. A policy is composed of a principal (the user, group or application to which it applies) and one or more IAM rules (which describe the permission sets the principal should have, and the scope of those permission sets).

If managing access to resources at the Project level is enough for your Object Storage use cases, use IAM only.

Bucket policies

A bucket policy is a resource-based policy option. It allows you to grant more granular access to Object Storage resources.

By default, all Object Storage resources in a Project are private and can be accessed only by users or applications with IAM permissions. Adding a bucket policy to a bucket allows you to specify who can perform which actions on a bucket and the objects it contains. You can combine the different elements of a bucket policy to tailor your permissions according to your use case.

Combining IAM and bucket policies

In order to perform actions on a bucket, a principal (user or application) must be granted access via an IAM policy, and optionally via a bucket policy.

By properly setting up IAM first, you can restrict access to Object Storage to the desired users and applications, and limit their allowed actions. By adding bucket policies to your critical resources, you can further restrain access and actions directly at the bucket-level, and achieve optimum security.

To set up granular access to your Object Storage resources, you must:

1. List all the users and applications you want to grant access to Object Storage, what rights you want to give them, and which buckets they can access.

2. Create an IAM group that contains every user and application that must access Object Storage.

   Note

   You can create several groups to assign different permission sets to your users and applications.

3. Create an IAM policy for each group created, select the appropriate permission sets (e.g. ObjectStorageReadOnly or ObjectStorageObjectsRead), and attach it to the group.

4. Create and push a bucket policy in each bucket in which you want fine-grained access.

IAM and bucket policy example

Consider an Organization in which a user and an application must perform specific tasks with Scaleway Object Storage in a project named S3-project.

Defining authorizations

• The user must be able to read (GET) and write (PUT) objects in a bucket A.

• The application must be able to read (GET) objects in bucket A, and to write (PUT) and DELETE objects in a bucket B.

Setting up access

1. Create a group named S3-group that contains the user and the application, so they are the only ones to have access to Object Storage.

2. Create an IAM policy named S3-policy in the Scaleway console, with the previously created group as a principal. The members of this group will have the ObjectStorageFullAccess right.

3. Create a bucket policy to manage access to bucket A.

   {
   "Version": "2023-04-17",
       "Id": "bucket-A-policy",
       "Statement": [
           {
               "Sid": "Allow user to GET and PUT objects",
               "Effect": "Allow",
               "Principal":{
               "SCW":"user_id:<USER_ID>"
               },
               "Action": [
                   "s3:GetObject",
                   "s3:PutObject"
               ],
               "Resource": [
                   "bucket-A",
                   "bucket-A/*"
               ]
           },
           {
               "Sid": "Allow application to GET objects",
               "Effect": "Allow",
               "Principal":{
               "SCW":"application_id:<APPLICATION_ID>"
               },
               "Action": [
                   "s3:GetObject",
               ],
               "Resource": [
                   "bucket-A/*"
               ]
           }
       ]
   }
   

4. Create a bucket policy to manage access to bucket B.

   {
   "Version": "2023-04-17",
       "Id": "bucket-B-policy",
       "Statement": [
           {
               "Sid": "Allow application to PUT and DELETE objects",
               "Effect": "Allow",
               "Principal":{
               "SCW":"application_id:<APPLICATION_ID>"
               },
               "Action": [
                   "s3:PutObject",
                   "s3:DeleteObject",
                   "s3:DeleteObjects"
               ],
               "Resource": [
                   "bucket-B",
                   "bucket-B/*"
               ]
           }
       ]
   }
   

5. Push the policies to the corresponding buckets.

• The user can now GET and PUT in bucket A, and the application can now GET in bucket A

• The application can now PUT and DELETE in bucket B, and the user cannot perform any action as they are not EXPLICITLY allowed by the bucket policy.