Skip to content

Commit 915fc96

Browse files
OVH-Team-GuidesOVH-Team-Guides
authored
Merge pull request #4288 from ovh/fp-storage
Fp storage new guides
2 parents 3e72c7d + 9bf7fef commit 915fc96

31 files changed

+5850
-0
lines changed

‎pages/cloud/storage/object_storage/s3_bucket_acl/guide.de-de.md

Lines changed: 239 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,239 @@
1+
---
2+
title: Object Storage - Bucket ACL (EN)
3+
slug: s3/bucket-acl
4+
section: Tutorials
5+
order: 150
6+
updated: 2023-03-09
7+
routes:
8+
canonical: 'https://docs.ovh.com/gb/en/storage/object-storage/s3/bucket-acl/'
9+
---
10+
11+
**Last updated on 9th March 2023**
12+
13+
## Overview
14+
15+
By default, all resources (buckets, objects) and sub-resources (lifecycle configuration, webite configuration, ...etc) are private in OVHcloud S3 Object Storage. Only the resource owner, i.e the user account that creates it, has full control.
16+
17+
Access to private resources can be granted via access policies.
18+
19+
Access policies can be categorized broadly into 2 types :
20+
21+
- user based
22+
- resource based : bucket policies and ACLs are policies that are attached directly to specific resources
23+
24+
### User based
25+
26+
Access policies attached to a specific user are called user policies. A user policy is evaluated using OVHcloud S3 Object Storage IAM permissions and applies only to the specific user it is attached to.
27+
28+
### Resource based
29+
30+
#### ACL
31+
32+
An ACL is a list of permissions granted to identified grantees. ACLs are typically used to grant basic read/write permissions to other accounts.
33+
34+
ACLs can either be attached at bucket level or at individual object level.
35+
36+
Although ACLs are the legacy way to manage permissions, they are still relevant and not deprecated. However based on the situation, you might want to use policies to apply fine grained control of your resources.
37+
38+
#### Bucket policy
39+
40+
Akin to user policies, a bucket policy controls permissions for a bucket and the objects in it. The difference is that whereas user policies control permissions for a specific user to a list of resources, a bucket policy controls permissions to a specific bucket and its objects for a list of users.
41+
42+
![policies](images/s3_bucket_acl-20230228171656561.png)
43+
44+
> [!warning]
45+
>
46+
> Bucket policies is a feature that is not yet available for OVHcloud S3 Object Storage.
47+
>
48+
49+
## Manage permissions with ACLs
50+
51+
### Supported grantees
52+
53+
OVHCloud Object Storage supports 2 types of grantees:
54+
55+
- Public Cloud account users
56+
- Predefined groups
57+
58+
#### Public Cloud account
59+
60+
Public Cloud account users are identified by a canonical user id. When you grant access rights, the canonical user id is specified by `id=<value>` where `<value>` equals `<project_name>:<user_name>`.
61+
62+
Example: if you have a Public Cloud project named `my_project` and you have created a user named `storage-user` then you get `id=my_project:storage-user`
63+
64+
#### Predefined groups
65+
66+
Supported predefined user groups are the following and are identified by a URI:
67+
68+
- **log delivery group**: this group contains the applicative users used by OVHcloud services to write server access logs inside buckets (read our [Server Access Logging](https://docs.ovh.com/de/storage/object-storage/s3/server-access-logging/) guide for more information)
69+
70+
```console
71+
http://acs.amazonaws.com/groups/s3/LogDelivery
72+
```
73+
74+
- **authenticated users group**: this group contains all the OVHcloud Public Cloud account users
75+
76+
```console
77+
http://acs.amazonaws.com/groups/global/AuthenticatedUsers
78+
```
79+
80+
- **all users group**: this group is the default group that contains all users in the world and is equivalent to anonymous users
81+
82+
```console
83+
http://acs.amazonaws.com/groups/global/AllUsers
84+
```
85+
86+
### Permissions
87+
88+
The managed permissions are listed below. Note that depending on the level (bucket or object), not all permissions can apply.
89+
90+
| Permission | Bucket level | Object level |
91+
| --- | --- | --- |
92+
| READ | allows list/download all objects in the bucket | allows list/download object and its metadata |
93+
| WRITE | allows creation/deletion/overwrites of objects in the bucket | n/a |
94+
| READ_ACP | allows read of the bucket ACL | allows read of the object ACL |
95+
| WRITE_ACP | allows creation/deletion/overwrites of the bucket ACL | allows creation/deletion/overwrites of the object ACL |
96+
| FULL_CONTROL | shorthand for READ, WRITE, READ_ACP, WRITE_ACP on the bucket | shorthand for READ, READ_ACP, WRITE_ACP on the object |
97+
98+
### Predefined ACLs
99+
100+
Predefined ACLs have a predefined set of grantees and permissions and are a convenient shorthand for the most common use cases.
101+
102+
| ACL | Description | Bucket | Object | Comment |
103+
| --- | --- | --- | --- | --- |
104+
| private | default behavior, owner has FULL_CONTROL | x | x | |
105+
| public-read | owner has FULL_CONTROL<br>AllUsers group has READ | x | x | |
106+
| public-read-write | owner has FULL_CONTROL<br>AllUsers group has READ, WRITE | x | x | |
107+
| authenticated-read | owner has FULL_CONTROL<br>AuthenticatedUsers group has READ | x | x | |
108+
| bucket-owner-read | object owner has FULL_CONTROL<br>bucket owner has READ | | x | currently not managed yet |
109+
| bucket-owner-full-control | object owner and bucket owner both have FULL_CONTROL | | x | currently not managed yet |
110+
| log-delivery-write | LogDelivery group has WRITE, READ_ACP | x | | |
111+
112+
### Instructions
113+
114+
#### Set ACL on a bucket
115+
116+
You can set the ACL on a bucket at its creation or afterwards, by calling the `put-bucket-acl` endpoint.
117+
118+
Example:
119+
120+
```bash
121+
$ aws s3api create-bucket --bucket my-bucket --region gra --acl public-read
122+
```
123+
124+
In this example, we created a bucket named "my-bucket" using a predefined ACL "public-read".
125+
126+
To verifiy that ACL are set correctly, you can use the following command to return the ACL:
127+
128+
```bash
129+
$ aws s3api get-bucket-acl --bucket my-bucket
130+
```
131+
132+
```json
133+
{
134+
"Owner": {
135+
"DisplayName": "2171889990277389:user-xxxxxxxxxxxx",
136+
"ID": "2171889990277389:user-xxxxxxxxxxxx"
137+
},
138+
"Grants": [
139+
{
140+
"Grantee": {
141+
"Type": "Group",
142+
"URI": "http://acs.amazonaws.com/groups/global/AllUsers"
143+
},
144+
"Permission": "READ"
145+
},
146+
{
147+
"Grantee": {
148+
"DisplayName": "2171889990277389:user-xxxxxxxxxxxx",
149+
"ID": "2171889990277389:user-xxxxxxxxxxxx",
150+
"Type": "CanonicalUser"
151+
},
152+
"Permission": "FULL_CONTROL"
153+
}
154+
]
155+
}
156+
```
157+
158+
159+
160+
To change the ACL, you can call the `put-bucket-acl` endpoint by using the AWS cli:
161+
162+
```bash
163+
$ aws s3api put-bucket-acl --bucket acl-bucket --grant-write id=po-training:user-yyyyyyyyyy
164+
```
165+
166+
Here, we change the ACL to give account user "user-yyyyyyyyyy" the permission to write in the bucket.
167+
168+
Again, to verify that ACL are set correctly:
169+
170+
```bash
171+
$ aws s3api get-bucket-acl --bucket my-bucket
172+
```
173+
174+
```json
175+
{
176+
"Owner": {
177+
"DisplayName": "2171889990277389:user-xxxxxxxxxxxx",
178+
"ID": "2171889990277389:user-xxxxxxxxxxxx"
179+
},
180+
"Grants": [
181+
{
182+
"Grantee": {
183+
"DisplayName": "po-training:user-yyyyyyyyyy",
184+
"ID": "po-training:user-yyyyyyyyyy",
185+
"Type": "CanonicalUser"
186+
},
187+
"Permission": "WRITE"
188+
}
189+
]
190+
}
191+
```
192+
193+
#### Set ACL on an object
194+
195+
Similar to bucket level, you can set the ACL on an object at its creation or afterwards.
196+
197+
Example:
198+
199+
```bash
200+
$ aws s3api put-object --bucket my-bucket --body file.txt --key file --grant-full-control id=po-training:user-yyyyyyyyyy
201+
```
202+
203+
In this example, we created an object named "file" and we gave "FULL_CONTROL" on that object to account user "user-yyyyyyyyyy".
204+
205+
## Best practices
206+
207+
### When to use ACLs?
208+
209+
#### At object level
210+
211+
As mentioned before, ACLs can be attached at object level.
212+
213+
You might consider the following scenarios to use object ACL.
214+
215+
- the bucket owner and the object owner are not the same: in a scenario where the bucket owner has granted another account to write objects inside the bucket, access to those objects must be granted through ACLs
216+
- permissions vary from individual object to individual object
217+
218+
#### At bucket level
219+
220+
We stongly advise you to use policies instead for a better and more fine grained access control over the bucket and its objects. However, for very basic permission control needs, you might consider using bucket ACLs to grant permissions to the objects and ACLs related to the bucket.
221+
222+
### When to use bucket policies?
223+
224+
You might consider using bucket policies if you want to set **cross-account** permissions over the resources related to a specific bucket.
225+
226+
### When to use user policy?
227+
228+
You might consider using user policies if you want to set **cross-resource** permissions for a specific account.
229+
230+
> [!warning]
231+
>
232+
> **Important**
233+
>
234+
> ACLs and policies can be combined. However the principle of least privilege will always be applied and can be summerized as "**allow only if there is an explicit allow and no explicit deny, else, deny all**"
235+
>
236+
237+
## Go further
238+
239+
Join our community of users on [https://community.ovh.com/en/](https://community.ovh.com/en/).

0 commit comments

Comments
 (0)