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
Copy file name to clipboardExpand all lines: pages/iam/concepts.mdx
+8-2Lines changed: 8 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -32,6 +32,14 @@ Previously, an API key was associated with a single Scaleway [Project](#project)
32
32
33
33
With the introduction of IAM, an API key is now associated with an IAM [user](#user) or [application](#application). This allows fine-grained access to be defined for the IAM user bearing the API key across different Organizations, Projects, and resources.
34
34
35
+
## Common Expression Language (CEL)
36
+
37
+
The Common Expression Language (CEL) is used to define expressions in [conditions](#conditions) within an IAM policy. CEL allows you to create attribute-based logic expressions that determine whether specific permissions apply. A condition expression typically consists of one or more statements, each defining an attribute-based control rule. IAM conditions use the following CEL features: **Variables**, **Operators**, **Functions**, and **Logical Operators**. Refer to the [Understanding policy conditions](/iam/reference-content/understanding-policy-conditions) documentation page for a detailed description of the supported CEL features.
38
+
39
+
## Conditions
40
+
41
+
A condition is an additional layer of restrictions for your rule. You can allow access to specific user agents or IP addresses, and allow actions to be performed only at certain dates and times. Conditions are defined through [CEL](#common-expression-language-cel) expressions, and can be set up and configured in the Scaleway console. Refer to the [Understanding policy conditions](/iam/reference-content/understanding-policy-conditions) documentation page to learn how they are set up and how you can define them.
42
+
35
43
## Group
36
44
37
45
A group (also known as an IAM group) is a grouping of [users](#user) and/or [applications](#application). Creating groups allows you to attach [policies](#policy) to multiple users and/or applications at the same time.
@@ -91,8 +99,6 @@ Policies control user rights by defining one or more [rules](#rule) to apply to
91
99
92
100
For each policy rule, you specify one or more permission sets (e.g. "list all Instances") and their scope (e.g. "on Project A only"). This therefore defines the actions that the principles can carry out on resources within the scope.
93
101
94
-
<Lightboxsrc="scaleway-iam-policy.webp"alt="" />
95
-
96
102
## Preferred Project
97
103
98
104
You can carry out actions on Scaleway Object Storage resources either via the [Scaleway console](https://console.scaleway.com), or via a third-party API or CLI, such as [the AWS CLI](/object-storage/api-cli/object-storage-aws-cli/), [MinIOClient](/object-storage/api-cli/installing-minio-client/) or [Rclone](/object-storage/api-cli/installing-rclone/). While the Scaleway console gives you the option to specify the [Scaleway Project](/organizations-and-projects/concepts/#project) to carry out your Object Storage actions in, this option is not available via third-party API/CLI tools. These tools are based on a [standard Amazon S3 programming interface](https://en.wikipedia.org/wiki/Amazon_S3#S3_API_and_competing_services), which does not accept Project ID as a parameter. Therefore, when you create a Scaleway API key with IAM, you are prompted to specify the API key's **preferred Project for Object Storage**. This API key will always use this Project when carrying out Object Storage actions via any API/CLI. See our page on [using API keys with Object Storage](/iam/api-cli/using-api-key-object-storage/) for more information.
Rules define the actions that the attached principal will be able to carry out within the Organization. When creating a rule, you first set the **scope** of the rule, and then select the **permission sets** to apply within the scope. See our dedicated documentation for more help with [policies, rules, scopes and permission sets](/iam/reference-content/policy/).
45
+
Rules define the actions that the attached principal will be able to carry out within the Organization. When creating a rule, you first set the **scope** of the rule, and then select the **permission sets** to apply within the scope. You can optionally set up **conditions** for your rule. See our dedicated documentation for more help with [policies, rules, scopes and permission sets](/iam/reference-content/policy/).
46
46
</Message>
47
47
6. Select a **scope** for the rule:
48
48
- To give the principal permissions to view, create, edit and/or delete [resources](/iam/concepts/#resource), select the **Access to resources** scope. Then, select the [Project](/iam/concepts/#project) in which you want the permissions to apply. You can select from **all current and future Projects**, **all current Projects** or select specific Projects.
49
49
- To give the principal permissions to [Organization](/iam/concepts/#organization)-level features such as IAM, billing, support & abuse tickets and project management, select the **Access to Organization features** scope.
50
50
7. Click **Validate** to continue.
51
51
8. Choose the **permission sets** for the rule by selecting the required boxes. You can select as many permission sets as you like. The principal will have the rights defined in these permission sets within the scope you set in **step 6**. See our dedicated documentation for [more help with permission sets](/iam/reference-content/permission-sets/).
52
-
9. Click **Validate**. The rule, with its scope and permission sets, is added to the list of the policy's rules.
53
-
10. Click **Add new rule** and repeat steps 6-8 as many times as required to add multiple rules to your policy.
52
+
9. Click **Validate**.
53
+
10. (Optional) Click **+ Add new** to add one or more conditions. You can allow access to specific user agents or IP addresses, and allow actions to be performed only at certain dates and times.
54
+
<Messagetype="tip">
55
+
Refer to the [Understanding policy conditions](/iam/reference-content/understanding-policy-conditions) documentation page for more details about how to write condition expressions, as well as examples of conditions.
56
+
</Message>
57
+
11. Click **Validate**. The rule, with its scope and permission sets, is added to the list of the policy's rules.
58
+
12. Click **Add new rule** and repeat steps 6 to 8 as many times as required to add multiple rules to your policy.
54
59
<Messagetype="tip">
55
60
You can delete <Iconname="delete" /> or edit <Iconname="edit" /> an existing rule by clicking the relevant button in the top right corner of the rule's summary.
56
61
</Message>
57
-
11. Click **Create policy** to finish.
62
+
13. Click **Create policy** to finish.
58
63
59
64
You are returned to the **Policies** tab, where the newly-created policy now appears in the list.
0 commit comments