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
@@ -164,53 +193,57 @@ Some examples of JSON configuration files:
164
193
}
165
194
```
166
195
167
-
168
-
**Allow read access to objects only to specific IPs**
196
+
**Allow all operations to specific IPs by whitelisting authorized IPs**
169
197
170
198
```json
171
199
{
172
200
"Statement": {
173
201
"Sid": "ExampleStatement01",
174
-
"Effect": "Allow",
175
-
"Action": [
176
-
"s3:GetObject",
177
-
"s3:ListBucket",
178
-
"s3:ListBucketVersions"
179
-
],
202
+
"Effect": "Deny",
203
+
"Action": "s3:*",
180
204
"Resource": [
205
+
"arn:aws:s3:::companybucket",
181
206
"arn:aws:s3:::companybucket/*"
182
207
],
183
208
"Condition": {
184
-
"IpAddress": {
209
+
"NotIpAddress": {
185
210
"aws:SourceIp": "10.0.0.5/16"
186
211
}
187
212
}
188
213
}
189
-
}
214
+
}
190
215
```
191
216
192
-
**Allow all operations to specific IPs by whitelisting authorized IPs**
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.
193
223
194
224
```json
195
225
{
196
226
"Statement": {
197
227
"Sid": "ExampleStatement01",
198
-
"Effect": "Deny",
199
-
"Action": "s3:*",
228
+
"Effect": "Allow",
229
+
"Action": [
230
+
"s3:GetObject",
231
+
"s3:ListBucket",
232
+
"s3:ListBucketVersions"
233
+
],
200
234
"Resource": [
201
-
"arn:aws:s3:::companybucket",
202
235
"arn:aws:s3:::companybucket/*"
203
236
],
204
237
"Condition": {
205
-
"NotIpAddress": {
238
+
"IpAddress": {
206
239
"aws:SourceIp": "10.0.0.5/16"
207
240
}
208
241
}
209
242
}
210
-
}
243
+
}
211
244
```
212
245
213
-
**Deny read access to objects to specific IPs by blacklisting unauthorized IPs**
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.
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
@@ -164,53 +193,57 @@ Some examples of JSON configuration files:
164
193
}
165
194
```
166
195
167
-
168
-
**Allow read access to objects only to specific IPs**
196
+
**Allow all operations to specific IPs by whitelisting authorized IPs**
169
197
170
198
```json
171
199
{
172
200
"Statement": {
173
201
"Sid": "ExampleStatement01",
174
-
"Effect": "Allow",
175
-
"Action": [
176
-
"s3:GetObject",
177
-
"s3:ListBucket",
178
-
"s3:ListBucketVersions"
179
-
],
202
+
"Effect": "Deny",
203
+
"Action": "s3:*",
180
204
"Resource": [
205
+
"arn:aws:s3:::companybucket",
181
206
"arn:aws:s3:::companybucket/*"
182
207
],
183
208
"Condition": {
184
-
"IpAddress": {
209
+
"NotIpAddress": {
185
210
"aws:SourceIp": "10.0.0.5/16"
186
211
}
187
212
}
188
213
}
189
-
}
214
+
}
190
215
```
191
216
192
-
**Allow all operations to specific IPs by whitelisting authorized IPs**
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.
193
223
194
224
```json
195
225
{
196
226
"Statement": {
197
227
"Sid": "ExampleStatement01",
198
-
"Effect": "Deny",
199
-
"Action": "s3:*",
228
+
"Effect": "Allow",
229
+
"Action": [
230
+
"s3:GetObject",
231
+
"s3:ListBucket",
232
+
"s3:ListBucketVersions"
233
+
],
200
234
"Resource": [
201
-
"arn:aws:s3:::companybucket",
202
235
"arn:aws:s3:::companybucket/*"
203
236
],
204
237
"Condition": {
205
-
"NotIpAddress": {
238
+
"IpAddress": {
206
239
"aws:SourceIp": "10.0.0.5/16"
207
240
}
208
241
}
209
242
}
210
-
}
243
+
}
211
244
```
212
245
213
-
**Deny read access to objects to specific IPs by blacklisting unauthorized IPs**
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.
0 commit comments