You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
76
+
{.thumbnail}
77
77
78
78
Select the access profile for this user and click `Confirm`{.action}.
79
79
80
-
80
+
{.thumbnail}
81
81
82
82
### Advanced resource access management
83
83
84
+
#### Overview
85
+
86
+
By default, all resources (buckets, objects) and sub-resources (lifecycle configuration, webite configuration, etc.) are private in Object Storage. Only the resource owner, i.e the user account that creates it, has full control.
87
+
88
+
Access to private resources can be granted via access policies. Access policies can be categorized broadly into 2 types :
89
+
90
+
- user based: access policies attached to a specific user are called user policies. A user policy is evaluated using Object Storage IAM permissions and applies only to the specific user it is attached to.
91
+
- resource based : bucket policies and ACLs are policies that are attached directly to specific resources
92
+
93
+
> [!primary]
94
+
>
95
+
> Bucket policies is a feature that is not yet available for Object Storage. This article is about user policies.
96
+
>
97
+
84
98
You can refine your permissions by importing a JSON configuration file. To do this, go to the `Object Storage Policy Users`{.action} tab.
Click on the `...`{.action} at the end of your user's line, then `Import JSON file`{.action}.
89
103
90
104
> [!primary]
91
105
>
92
106
> If you want to change a user's rights, you may need to download the JSON configuration file in advance by selecting `Download JSON File`{.action}.
107
+
>
108
+
109
+
#### Understanding the user policy evaluation process
110
+
111
+
At the moment, user permissions are evaluated as follows:
112
+
113
+
1. if exists, evaluate user policy else fallback to ACLs
114
+
1. check for an explicit deny: if there is an explicit deny, then deny permission, else, check for an explicit allow
115
+
2. check for an explicit allow: if there is an explicit allow, then allow permission
116
+
3. if there is no explicit deny nor explicit allow, then fallback to ACLs
117
+
2. fallback to ACLs
118
+
119
+
> [!primary]
120
+
>
121
+
> This evaluation process will be subject to change with the upcoming implementation of bucket policies.
93
122
>
94
123
95
-
Some examples of JSON configuration files:
124
+
#### Some examples of JSON configuration files:
96
125
97
126
**Read/write access to a bucket and its objects**
98
127
@@ -120,6 +149,24 @@ Some examples of JSON configuration files:
120
149
}
121
150
```
122
151
152
+
**Deny listing of all buckets owned by the parent account**
153
+
154
+
> [!primary]
155
+
>
156
+
> The (`s3:ListAllMyBuckets`) action is allowed by default for a given user. Add the `deny`{.action} effect if you want to explictly refuse the use of the `ListBuckets`{.action} API operation.
157
+
>
158
+
159
+
```json
160
+
{
161
+
"Statement":[{
162
+
"Sid": "DenyListBucket",
163
+
"Effect": "Deny",
164
+
"Action":["s3:ListAllMyBuckets"],
165
+
"Resource":["*"]
166
+
}]
167
+
}
168
+
```
169
+
123
170
**Allow all operations on all project resources**
124
171
125
172
```json
@@ -146,6 +193,80 @@ Some examples of JSON configuration files:
146
193
}
147
194
```
148
195
196
+
**Allow all operations to specific IPs by whitelisting authorized IPs**
197
+
198
+
```json
199
+
{
200
+
"Statement": {
201
+
"Sid": "ExampleStatement01",
202
+
"Effect": "Deny",
203
+
"Action": "s3:*",
204
+
"Resource": [
205
+
"arn:aws:s3:::companybucket",
206
+
"arn:aws:s3:::companybucket/*"
207
+
],
208
+
"Condition": {
209
+
"NotIpAddress": {
210
+
"aws:SourceIp": "10.0.0.5/16"
211
+
}
212
+
}
213
+
}
214
+
}
215
+
```
216
+
217
+
> [!primary]
218
+
>
219
+
> As a consequence of the current authorization process, **implicit** deny is **not** supported by OVHcloud Object Storage if the user is the bucket owner i.e since ACLs are evaluated by default and since the bucket owner has FULL_CONTROL ACL, if the user is the bucket owner and even if there is no explicit allow in the policy file, he will be authorized.
220
+
>
221
+
222
+
The following policy to attempt to allow read access to objects only to specific IPs will **not** work under current conditions if attached to the bucket owner i.e even if the bucket owner makes his requests from IPs that are not in the specified range, he will be authorized.
223
+
224
+
```json
225
+
{
226
+
"Statement": {
227
+
"Sid": "ExampleStatement01",
228
+
"Effect": "Allow",
229
+
"Action": [
230
+
"s3:GetObject",
231
+
"s3:ListBucket",
232
+
"s3:ListBucketVersions"
233
+
],
234
+
"Resource": [
235
+
"arn:aws:s3:::companybucket/*"
236
+
],
237
+
"Condition": {
238
+
"IpAddress": {
239
+
"aws:SourceIp": "10.0.0.5/16"
240
+
}
241
+
}
242
+
}
243
+
}
244
+
```
245
+
246
+
The following policy to attempt to deny read access to objects to specific IPs by blacklisting unauthorized IPs will **not** work under current conditions if attached to the bucket owner because there is no explicit deny and requests from the specified IPs will not match the allow, therefore, we fallback to the ACLs.
247
+
248
+
```json
249
+
{
250
+
"Statement": {
251
+
"Sid": "ExampleStatement01",
252
+
"Effect": "Allow",
253
+
"Action": [
254
+
"s3:GetObject",
255
+
"s3:ListBucket",
256
+
"s3:ListBucketVersions"
257
+
],
258
+
"Resource": [
259
+
"arn:aws:s3:::companybucket/*"
260
+
],
261
+
"Condition": {
262
+
"NotIpAddress": {
263
+
"aws:SourceIp": "10.0.0.5/16"
264
+
}
265
+
}
266
+
}
267
+
}
268
+
```
269
+
149
270
### List of supported actions
150
271
151
272
| Action | Scope |
@@ -176,6 +297,7 @@ Some examples of JSON configuration files:
0 commit comments