Jump toUpdate content

Concepts

Account

An account user is a human with a Scaleway account. Your account bears your personal information and authentication methods for connecting to the Scaleway console. When you create your Scaleway account, an Organization is automatically created, of which you are the Owner.

Application

An application (also known as an IAM application) is a non-human user in an Organization. IAM applications may be used when you want to create an API key that is not linked to a user, to give programmatic access to resources.

Note that applications cannot, by definition, have access to the Scaleway console, as they have only an API key and no account themselves (they are not accounts).

API key

An API key is a unique identifier, used to authenticate requests made to the Scaleway API. An API key consists of an access key and a secret key. The access key is like a unique ID or username, and not a sensitive piece of information. The secret key however is more sensitive, as it is like a password to authenticate the access key.

Previously, an API key was associated with a single Scaleway Project. The API key therefore had full read/write access to all resources on this Project, and only this Project.

With the introduction of IAM, an API key is now associated with an IAM user or application. This allows fine-grained access to be defined for the IAM user bearing the API key across different Organizations, Projects, and resources.

Group

A group (also known as an IAM group) is a grouping of users and/or applications. Creating groups allows you to attach policies to multiple users and/or applications at the same time.

Guest

You are the Owner of the Organization that is created with your Scaleway account. However, when you are invited to another Organization of which you are not the Owner, you are a guest in that Organization.

Similarly, you can invite other users to be guests in your Organization. Whereas Owners have full rights and access to all resources and features in their Organization, guests have only the rights and permissions given to them via policies.

IAM

Identity and Access Management allows you to share access to the management of your Scaleway resources, in a controlled and secure manner.

This is achieved by inviting users to be Guests in your account’s Organization, and creating policies that define in a very fine-grained way exactly what permissions they should have for which resources in which of your Projects or across your whole Organization.

Similarly, you may participate as a Guest in someone else’s Organization, where you will have the precise rights that they accord to you using policies.

You can also create non-human users in your Organization, called IAM applications, in order to give applications programmatic access to your Scaleway resources.

Organization

An Organization is made of one or several Projects. When you create your Scaleway account, an Organization is automatically created, of which you are the Owner. When you create IAM rules you can set their scope at Organization level.

This means you can give access to features managed at Organization level, like Billing and IAM, to users, applications and groups in your Organization.

Owner

You are the Owner of the Organization that is created with your Scaleway account. Owners have full rights and access to all resources and features in their Organization. See also guest.

Preferred Project

You can carry out actions on Scaleway Object Storage resources either via the Scaleway console, or via a third-party API or CLI, such as the AWS CLI, MinIOClient or Rclone. While the Scaleway console gives you the option to specify the Scaleway 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 S3 programming interface, 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.

Permission

A permission is a granular right, which is checked to determine whether to give access to an API endpoint. Permissions are grouped into permission sets to facilitate access management within policies.

Permission set

Permission sets are the main components of IAM rules. They consist of sets of one or multiple permissions.

Permission set names contain descriptions that clearly explain their purpose. For example, a permission set that grants access to all actions you can perform on Instances is called: InstancesFullAccess.

Permissions sets (eg.InstanceReadAccess) and their scope (eg. “on Project A only”) make up IAM rules, which define the access rights that a principal (user, group or application) should have.

Policy

Policies control user rights, by defining one or more rules to apply to the attached principals (users, groups or applications). A policy rule has two parts: permission set and scope.

For each policy rule, you specify one or more permission sets (eg. “list all Instances”) and their scope (eg. “on Project A only”). This therefore defines the actions that the principles can carry out on resources within the scope.

Principal

A principal is the target of a policy. They acquire the rights and permissions defined in the policy. A principal can be an IAM user, an IAM application or an IAM group. Each policy can have a maximum of one principal attached to it.

Project

Projects are groupings of Scaleway resources. Every Scaleway Organization has a default Project, and you can create new projects if necessary. By grouping resources into Projects, you can then define access differently for each Project.

For example, if IAM users within your Organization are working on building two different systems with Scaleway resources, you can group the resources for each system into different Projects. This then allows you to restrict IAM users’ access to only the Project they are working on. It also facilitates the separation of billing between Projects.

Resource

A Scaleway resource is either a product or a feature in the Scaleway Ecosystem. Examples of resources include Instances, Private Networks, Kubernetes Kapsule and Flexible IPs, to name a few.

Rule

A rule (also known as an IAM rule) is the part of a policy that defines the permissions of the policy’s principal, and the scope of these permissions. A policy can have one or many rules. Each rule consists of:

  1. A scope, which 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. Billing, IAM, Project management and support are all managed at Organization level, so choose the Organization scope to give access to these features.
  2. One or more permission sets (eg. “list all Instances”). 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, DatabaseFullAccess, BillingReadOnly.

    The rule below defines various levels of access to different resources in Project A. The principal (user, group or application) can create, list, delete and manage Instances and Databases, but for Object Storage can only list and read the resources:

SCOPE
Project A
PERMISSION SET
InstancesFullAccess, ObjectStorageReadOnly, DatabasesFullAccess

Scope

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

User

A user (also known as an IAM user) is a human user in an Organization. They can be of two types:

  • Owner: You are the Owner of the Organization that was created with your account.
  • Guest: You are a Guest when invited to another Organization of which you are not the Owner. Similarly, you can invite other users to be Guests in your Organization.

Within each Organization, different IAM users can have different rights (defined through policies) to perform actions on resources.