---
title: Understanding IAM Policies
description: Detailed additional content for policies within Scaleway IAM.
tags: iam
dates:
  validation: 2025-10-29
---
import image from './assets/scaleway-iam-policy-example.webp'


IAM Policies are statements that define the permissions of users, groups, and applications in Scaleway Organizations.

They are composed of:

- a [principal](#principal) - a user, group, or application,
- one or more IAM rules - consisting of [permission sets](#permission-sets) bound to a [scope](#scope).
- one or more IAM conditions - defined in Common Expression Language (CEL) expressions.

## Principal

A principal is an entity that can be attached to a policy. Currently, you can attach either a [user](/iam/reference-content/users-groups-and-applications/#users), a [group](/iam/reference-content/users-groups-and-applications/#groups), or an [application](/iam/reference-content/users-groups-and-applications/#applications) to a policy. Only one principal can be attached to each policy.

<Message type="tip">
  If a user or application is the principal of multiple policies, whether as sole principal or as part of a group, they benefit from all the permissions defined in each of these policies.
</Message>

## Rules

A rule is the part of a policy that defines the permissions of the policy's [principal](/iam/concepts/#principal), and the [scope](/iam/concepts/#scope) of these permissions. It consists of a **scope** (at Project level or Organization level) and one or more **permission sets** (eg. "list all Instances").

<Lightbox image={image} alt="" />

<Message type="note">
  A policy can have one or many rules. Note that rules can only **give** access to the specified actions/resources. You cannot create a rule that explicitly **denies** access to specific actions/resources. In any case, the default starting point for any user or application other than the Organization's owner, is that they have zero permissions other than those defined via policies attached to them.
</Message>

### Scope

A scope defines where the permission sets should apply. At Scaleway, a scope can be at Project or Organization level.

  - **Projects** group your Scaleway resources (eg. Instances, Object Storage buckets, Managed Databases etc.) together. An Organization may have many Projects, or just one default Project. If you choose to define scope at Project level, you can select one, many, or all Projects. When you then define the permission sets for this scope, you can give access to different resources within the Project(s).
  - an **Organization** is made of one or several Projects. IAM, billing, support and abuse tickets and project management are managed at Organization level, so choose an Organization scope to give access to these features.

### Permission sets

A permission set consists of one or multiple permissions to perform actions on resources or features. Each permission set has a clear description, e.g. `InstancesFullAccess`, `InstancesReadOnly`, `RelationalDatabaseFullAccess`, `BillingReadOnly`.

<Message type="note">
  You can find a detailed list of all permission sets available at Scaleway in the permission sets [reference page](/iam/reference-content/permission-sets/).
</Message>

<Message type="important">
  Keep in mind that, due to replication and caching, any new configuration of permission sets may take up to 1 minute to apply.
</Message>

### Conditions

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](/iam/concepts/#common-expression-language-cel) expressions. In general, a condition expression consists of one or more statements that are joined by logical operators (`&&`, `||`, or `!`).

Conditions 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.

### Example rule

The rule below defines various levels of access to different resources in Project A.

Scope
: Project "A"

Permission set
: `InstancesFullAccess`, `ObjectStorageReadOnly`, `RelationalDatabasesFullAccess`

## Example policy

The policy below states that the application `production-c` can create, list, delete and manage Instances and Databases in Project A, but for Object Storage it can only list and read the resources.

Principal
: IAM Application `production-c`

**Rule 1:**

Scope
: Project "A"

Permission set
: `InstancesFullAccess`, `ObjectStorageReadOnly`, `RelationalDatabasesFullAccess`

**Rule 2:**

Scope
: Project "F"

Permission set
: `ContainerRegistryFullAccess`, `ContainersReadOnly`, `RelationalDatabasesFullAccess`

<Message type="note">
  There is no notion of priority when it comes to IAM policies. Policies do not compete with each other, they simply combine to bestow all the permissions defined within them to any given principal.
</Message>

**JSON policy example**

```
{
  "application": "production-c",
  "rules": [
    {
      "projects": ["A"],
      "permission_sets": ["InstancesFullAccess", "ObjectStorageReadOnly", "RelationalDatabasesFullAccess"]
    },
    {
      "projects": ["F"],
      "permission_sets": ["ContainerRegistryFullAccess", "ContainersReadOnly", "RelationalDatabasesFullAccess"]
    }
  ]
}
```

If necessary, we could add more rules to the policy, giving `production-c` additional permissions in other Projects, or at Organization level.