SCP Principles

SCP Types

SCPs are classified into Huawei Cloud system-defined policies and custom policies, depending on who creates the policies.

• System-defined policies

System-defined policies refer to commonly used SCPs predefined by Huawei Cloud services for Organizations. An organization administrator can directly use these policies when attaching SCPs to OUs or accounts. Such policies cannot be modified. For details about the Huawei Cloud system-defined policies of all cloud services, see System-defined SCPs.

• Custom policies

If Huawei Cloud system-defined policies cannot meet your requirements, you can use the management account to create and modify custom SCPs based on the actions supported by each service. Custom policies extend and supplement Huawei Cloud system-defined policies. You can create custom policies for Organizations in a policy editor or JSON view.

SCP Effects on Permissions

• Permissions boundaries

  SCPs do not actually grant any permissions to an entity. They only set permissions boundaries for the entity. When SCPs are attached to an OU or a member account, they do not directly grant permissions to that OU or member account. Instead, the SCPs only determine what permissions are available for that member account or member accounts under that OU. The granted permissions can be applied only if they are allowed by the SCPs. Users cannot perform any actions that are denied by SCPs even if the actions are granted to the users by IAM policies.

  Suppose that an SCP is attached to a member account. The SCP allows action A but denies action B. The member account then can grant its IAM users the permission to perform action A but not action B. Even if the permission to perform action B is assigned, the permission cannot be applied.

• Permissions intersection

  The final effective permissions of an OU or account are the intersection of the permissions of its own SCPs and the allowed SCPs of its parent OU.

  In the following figure, the oval on the left represents an SCP attached to the parent OU. It allows permissions A, B, and C. The oval on the right represents an SCP attached to the child OU or account. It allows permissions C, D, and E. Because the SCP attached to the parent OU does not allow permission D or E, no child OUs or accounts under the parent OU can use them. Even though the SCP attached to the child OU explicitly allows permissions D and E, they are blocked by the SCP attached to the parent OU. Because the SCP attached to the child OU or account does not allow permission A or B, those permissions are blocked for the child OU or account. In this case, the child OU or account can actually use the permission (permission C in the following figure) in the intersection of its own permissions and the allowed permissions of its parent OU.

  If the entity in the oval on the right represents a member account, then the intersection is a set of maximum permissions that can be granted to the users and user groups in that account. If the entity represents a child OU, then the intersection is a set of maximum permissions that can be granted to that OU.

  Figure 1 How SCPs work
  

• Policy inheritance

  SCPs for an OU or account can be directly attached or inherited from the root OU or the parent OU. When you attach an SCP to a specific OU, all child OUs and accounts under that OU will inherit that policy. The permissions boundaries of an account or an OU are jointly determined by the SCPs attached to all upper-level OUs and the SCPs directly attached to the account or OU. In the following figure, Account y is nested in OU 3, and its permissions boundary is jointly determined by the SCPs inherited from the root OU and the SCPs attached to OU 1 and OU 3 as well as Account y.

  Figure 2 Example SCP inheritance
  

  If you want to allow a service action at the member account level, you must allow that action at every level between the member account and the root OU of your organization. Specifically, you must attach SCPs that allow the given action to every level from the root OU to the member account. You can use either of the following strategies for this:

  • A deny list strategy: This strategy makes use of the FullAccess SCP that is attached by default to every OU and account. This SCP overrides the default implicit Deny and allows all permissions to flow down from the root OU to every account, unless you explicitly deny a permission with an additional SCP that you create and attach to the appropriate OU or account. This strategy adheres to the rule that an explicit Deny in a policy always overrides any Allow. No account below the level of the OU with the deny policy can use the denied action, and there is no way to add the permission back lower in the hierarchy.
  • An allow list strategy: This strategy has you remove the FullAccess SCP that is attached by default to every OU and account. This means that no actions are permitted anywhere unless you explicitly allow them. To allow a service action in an account, you must create your own SCPs and attach them to the account and every OU above it, up to and including the root OU. Every SCP in the hierarchy, starting at the root OU, must explicitly allow the actions that you want to be usable in the OUs and accounts below it. This strategy adheres to the rule that an explicit Allow in an SCP overrides an implicit Deny.
• Deny preceded

  When multiple SCPs are attached to an OU or an account, a Deny statement always overrides an Allow statement. Suppose that two SCPs are attached to a member account, one allowing for full access and the other denying bill viewing. As the Deny statement overrides the Allow statement, the member account is prohibited from viewing the bill. For details, see Differences Between Explicit Deny and Implicit Deny.

• Allow by default

  When SCPs are enabled for an organization, the FullAccess policy is attached by default to all OUs and accounts unless you attach explicit deny policies to the OUs or accounts.

Differences Between Explicit Deny and Implicit Deny

There are two policy effects: Allow and Deny.

If there are no applicable Deny statements but also no applicable Allow statements, all requests are denied by default. This is called an implicit deny. If a policy includes an Allow statement for a given permission and no other policies include a Deny statement for that permission, the Allow statement takes effect.

If a policy includes an applicable Deny statement, requests will be denied. This is called an explicit deny. An explicit Deny always takes precedence over Allow. For example, if the SCP of an OU allows permissions A, B, and C, but the SCP of one of its child OU allows permissions A and B but denies permission C, then no accounts in the child OU or accounts in lower-level OUs can use permission C.

The following figure shows the logic for authenticating an access request.

Figure 3 Authentication logic

1. A principal sends an access request.
2. The system looks for a Deny statement that applies to the request. If the system finds an applicable Deny, it returns a final decision of Deny, and the authentication ends.
3. If no Deny is found applicable, the system looks for an Allow that would apply to the request. If the system finds an applicable Allow, it returns a final decision of Allow, and the authentication ends.
4. If no Allow is found applicable, the system returns a final decision of Deny, and the authentication ends.