Resource-level conditions
Resource-level conditions let you scope a rule to specific resources, based on attributes of the resource being targeted by the request — such as its name, ID, or location.
Resource-level conditions are built using CEL expressions. See Understanding policy conditions for the general concepts, operators, and logical operators shared by all condition types.
Variables
| Name | Type | Description |
|---|---|---|
resource.name | String | The name of the resource targeted by the request. |
resource.id | String | The unique ID of the resource targeted by the request. |
resource.locality | String | The location of the resource targeted by the request (format depends on the product; e.g. region or zone). |
resource.name is a mutable attribute: a resource can be renamed at any time. Because of this, a condition based on resource.name may stop matching the intended resource — or start matching a different one — if that resource is later renamed. Use resource.id instead wherever possible, as it does not change over the resource's lifetime.
Supported operators and functions
Resource-level conditions use the same CEL syntax as Request-level conditions and the rest of Scaleway's IAM conditions. For the specific operators and functions supported on resource attributes, refer to the CEL matcher language reference.
The Scaleway console and API only validate the syntax of a condition expression, not whether it is logically possible to satisfy. For example, the following expressions follow the correct syntax but can never evaluate to true, or reference a resource that does not exist:
resource.name == "toto" && resource.name == "tata"resource.name == "tutu"Make sure to double-check the logic of your condition, as Scaleway does not warn you if it is impossible to satisfy.
Resource-level conditions and listing actions
By default, adding a resource-level condition to a rule breaks listing actions, since a list request has no single resource to evaluate the condition against. To preserve listing behavior, add || !has(resource.id) to your condition expression.
For example, to preserve listing behavior alongside the folder example above:
resource.name.startsWith("/folder/") || !has(resource.id)More generally, resource-level conditions can affect console behavior in ways beyond listing actions. We recommend testing your conditions carefully after applying them, to confirm they behave as expected.
Expression examples
Restricting access to a resource folder in Secret Manager
To grant access only to resources within a given folder, you can use the startsWith() function on resource.name:
resource.name.startsWith("/folder/")This expression matches /folder/secret1 and /folder/subfolder/secret2, but not /secret3.
Restricting access by location
The resource.locality attribute lets you scope a rule to resources in a specific region or zone, or to global resources.
To grant access only to resources located in the fr-par region:
resource.locality.startsWith("fr-par")To grant access only to resources in a specific zone, compare resource.locality directly:
resource.locality == "fr-par-1"To grant access only to resources that are not tied to a specific region or zone (global resources, such as IAM resources):
resource.locality == "global"Be careful when combining multiple equality checks on the same attribute with &&. For example, the expression below can never evaluate to true, since resource.locality cannot equal two different values at once:
resource.locality == "fr-par-1" && resource.locality == "fr-par-3"To allow either zone, use || (OR) instead:
resource.locality == "fr-par-1" || resource.locality == "fr-par-3"