Compute
Elastic Cloud Server
Huawei Cloud Flexus
Bare Metal Server
Auto Scaling
Image Management Service
Dedicated Host
FunctionGraph
Cloud Phone Host
Huawei Cloud EulerOS
Networking
Virtual Private Cloud
Elastic IP
Elastic Load Balance
NAT Gateway
Direct Connect
Virtual Private Network
VPC Endpoint
Cloud Connect
Enterprise Router
Enterprise Switch
Global Accelerator
Management & Governance
Cloud Eye
Identity and Access Management
Cloud Trace Service
Resource Formation Service
Tag Management Service
Log Tank Service
Config
OneAccess
Resource Access Manager
Simple Message Notification
Application Performance Management
Application Operations Management
Organizations
Optimization Advisor
IAM Identity Center
Cloud Operations Center
Resource Governance Center
Migration
Server Migration Service
Object Storage Migration Service
Cloud Data Migration
Migration Center
Cloud Ecosystem
KooGallery
Partner Center
User Support
My Account
Billing Center
Cost Center
Resource Center
Enterprise Management
Service Tickets
HUAWEI CLOUD (International) FAQs
ICP Filing
Support Plans
My Credentials
Customer Operation Capabilities
Partner Support Plans
Professional Services
Analytics
MapReduce Service
Data Lake Insight
CloudTable Service
Cloud Search Service
Data Lake Visualization
Data Ingestion Service
GaussDB(DWS)
DataArts Studio
Data Lake Factory
DataArts Lake Formation
IoT
IoT Device Access
Others
Product Pricing Details
System Permissions
Console Quick Start
Common FAQs
Instructions for Associating with a HUAWEI CLOUD Partner
Message Center
Security & Compliance
Security Technologies and Applications
Web Application Firewall
Host Security Service
Cloud Firewall
SecMaster
Anti-DDoS Service
Data Encryption Workshop
Database Security Service
Cloud Bastion Host
Data Security Center
Cloud Certificate Manager
Edge Security
Managed Threat Detection
Blockchain
Blockchain Service
Web3 Node Engine Service
Media Services
Media Processing Center
Video On Demand
Live
SparkRTC
MetaStudio
Storage
Object Storage Service
Elastic Volume Service
Cloud Backup and Recovery
Storage Disaster Recovery Service
Scalable File Service Turbo
Scalable File Service
Volume Backup Service
Cloud Server Backup Service
Data Express Service
Dedicated Distributed Storage Service
Containers
Cloud Container Engine
SoftWare Repository for Container
Application Service Mesh
Ubiquitous Cloud Native Service
Cloud Container Instance
Databases
Relational Database Service
Document Database Service
Data Admin Service
Data Replication Service
GeminiDB
GaussDB
Distributed Database Middleware
Database and Application Migration UGO
TaurusDB
Middleware
Distributed Cache Service
API Gateway
Distributed Message Service for Kafka
Distributed Message Service for RabbitMQ
Distributed Message Service for RocketMQ
Cloud Service Engine
Multi-Site High Availability Service
EventGrid
Dedicated Cloud
Dedicated Computing Cluster
Business Applications
Workspace
ROMA Connect
Message & SMS
Domain Name Service
Edge Data Center Management
Meeting
AI
Face Recognition Service
Graph Engine Service
Content Moderation
Image Recognition
Optical Character Recognition
ModelArts
ImageSearch
Conversational Bot Service
Speech Interaction Service
Huawei HiLens
Video Intelligent Analysis Service
Developer Tools
SDK Developer Guide
API Request Signing Guide
Terraform
Koo Command Line Interface
Content Delivery & Edge Computing
Content Delivery Network
Intelligent EdgeFabric
CloudPond
Intelligent EdgeCloud
Solutions
SAP Cloud
High Performance Computing
Developer Services
ServiceStage
CodeArts
CodeArts PerfTest
CodeArts Req
CodeArts Pipeline
CodeArts Build
CodeArts Deploy
CodeArts Artifact
CodeArts TestPlan
CodeArts Check
CodeArts Repo
Cloud Application Engine
MacroVerse aPaaS
KooMessage
KooPhone
KooDrive

SCP Principles

Updated on 2025-02-25 GMT+08:00

SCP Types

SCPs are classified as either system-defined policies or custom policies, depending on who creates them.

  • 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 available SCP system policies, see System-defined SCPs.

  • Custom policies

If 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 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 set on the right represents a member account, the set of maximum permissions that can be granted to the users and user groups in that account is the intersection of the two sets. If the entity represents a child OU, then the set of maximum permissions that can be granted to that OU is the intersection of the two sets.

    Figure 1 How SCPs work
  • Policy inheritance

    SCPs for an OU or account can be attached directly 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 determined by a combination of 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 a deny list or an allow list.

    • A deny list: 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 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: 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 access to view billing information. 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 is applied.

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 applicable Deny is found, 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 applicable Allow is found, the system returns a final decision of Deny, and the authentication ends.

We use cookies to improve our site and your experience. By continuing to browse our site you accept our cookie policy. Find out more

Feedback

Feedback

Feedback

0/500

Selected Content

Submit selected content with the feedback