EIM Policy Elements

This topic lists the different elements that you can use in EIM policy documents.

EIM policies are case sensitive. All elements must start with an upper-case letter.

Elements

Statement

Description Examples

The main element, required in every policy-document attribute.

There is one Statement element per policy document that contains an array of one or more individual statements, corresponding to JSON blocks enclosed in curly braces and that contain at least the following elements:

  • Action or NotAction

  • Effect

  • Resource

The order of these elements within the individual statement is not important.

 
{
  "Statement": [
    {
      "Action": ["..."],
      "Effect": "...",
      "Resource": ["*"]
    },
    {
      "Sid": "...",
      "Action": ["..."],
      "Effect": "...",
      "Resource": ["*"]
    }
  ]
}

Sid

Description Examples

The statement ID (Sid) is an optional ID that you can add to individual statements. This enables you to give them a name according to your needs, but is not used by EIM to identify them.

 
"Sid": "Admin1"

Action

Description Examples

Specifies one or more actions that are allowed or denied. Every individual statement requires either the Action or the NotAction element.

To specify an action, you must specify the service followed by a colon, and use the name of an API method (for example DescribeInstances). For more information, see About the APIs.

You must use one of the following codes:

  • For the OUTSCALE API: api

  • For Flexible Compute Unit (FCU): ec2

  • For Load Balancing Unit (LBU): elasticloadbalancing

  • For Elastic Identity Management (EIM): iam

  • For DirectLink: directconnect

  • For all the services above: *

EIM is not compatible with the OUTSCALE Object Storage (OOS) service nor with OUTSCALE Kubernetes as a Service (OKS).

This element is an array that contains one or more actions, enclosed in quotation marks and separated by commas.

You can use asterisks (*) to replace parts of action names and thus specify several actions at the same time. You can for example specify all actions in all services or all actions in a specified service. You can also use asterisks to specify all actions regarding the same object type.

Action element specifying two actions:

"Action": ["ec2:DescribeInstances", "ec2:RunInstances"]

Action element specifying all actions in all services:

"Action": ["*"]

Action element specifying all actions in EIM:

"Action": ["iam:*"]

Action element specifying all actions regarding volumes, that is actions that include the Volume string (AttachVolume, CreateVolume, DeleteVolumes, DescribeVolumes, DeleteVolume):

"Action": ["ec2:*Volume*"]

NotAction

Description Examples

Specifies one or more exceptions to a list of actions. Every individual statement requires either the Action or the NotAction element.

This element format is the same as the Action element one.

You can use this element to create shorter statements instead of specifying a long list of actions in the Action element. You can for example allow all actions using the Action element, except one or more actions that you specify in the NotAction element. As you need to explicitly allow actions, only specifying an action in the NotAction element alongside and allow does not grant permissions to all other actions.

NotAction element that excludes the DescribeInstances action from the permissions:

"NotAction": ["ec2:DescribeInstances"]

  • If this element is associated with "Effect": "Deny" and "Action": ["*"], all other actions than DescribeInstances are explicitly denied.

  • If this element is associated with "Effect": "Allow" and "Action": ["*"], all actions are allowed except DescribeInstances.

Effect

Description Examples

Specifies whether the statement explicitly allows (Allow) or denies actions (Deny).

By default, access to resources is denied until it is explicitly allowed in a policy statement. To enable users to access resources, you must set the Effect element to Allow. Setting the Effect element to Deny overrides any Allow that may be set in another statement.

 
"Effect": "Allow"

Resource

Description Examples

Specifies the resources covered by the statement. This element is required in every statement.

Only the value * is supported, meaning all resources.

 
"Resource": ["*"]

Difference Between Default and Explicit Deny

When a user sends a request, EIM evaluates this request in regards of all applicable inline or managed policies.

If you did not explicitly allow the action contained in the request in a policy statement for this user, the action is denied. This is default deny. However, if you explicitly denied the actions in a policy statement for this user, this action is denied even though another policy statement allows it. This is explicit deny.

In other words, an allow can overrides a default deny, while an explicit deny overrides all allows and cannot be overridden.

The following flow chart shows the process to determine whether the action contained in a request is allowed or denied:

EIM Policy Evaluation Logic

sch EIM PolicyEvaluation

Related Pages

Export to PDF