Role/Policy-based Authorization
Role/policy-based permission provided by Identity and Access Management (IAM)Identity and Access Management (IAM) let you control access to CBH. With IAM, you can:
- Create IAM users for personnel based on your enterprise's organizational structure. Each IAM user has their own identity credentials for accessing CBH resources
- Grant only the permissions required for users to perform a task.
- Entrust an account or cloud service to perform professional and efficient O&M on your CBH resources.
If your account does not require individual IAM users, skip this chapter.
This section describes how to assign permissions based on roles and policies. Figure 1 shows the authorization process.
Prerequisites
Learn about the permissions supported by CBH. For details about the permissions of other services, see Permission SetPermission Set.
Authorization Process
- Create a user group and grant permissionsCreate a user group and grant permissions.
Create a user group on the IAM console, and attach the CBH ReadOnlyAccess policy to the group.
- Create an IAM user and add it to the created user groupCreate an IAM user and add it to the created user group.
On the IAM console, create an IAM user and add it to the user group created in 1.
- Log in as the IAM userLog in as the IAM user and verify permissions.
Log in to the CBH console by using the created user, and verify that the user only has read permissions for CBH.
- Hover over Service List and choose Cloud Bastion Host. On the CBH console, click Buy CBH Instance in the upper right corner. If the CBH instance cannot be purchased (assume that the current permission contains only CBH ReadOnlyAccess), the CBH ReadOnlyAccess policy is in effect.
- Choose another service from Service List. If a message appears indicating that you have insufficient permissions to access the service, the CBH ReadOnlyAccess policy is in effect.
Example CBH Custom Policies
Custom policies can be created to supplement the system-defined policies of CBH.
You can create custom policies in either of the following ways:
- Visual editor: Select cloud services, actions, resources, and request conditions. This does not require knowledge of policy syntax.
- JSON: Edit JSON policies from scratch or based on an existing policy.
For details, see . The following lists examples of common CBH custom policies.
- Example 1: Allowing users to change CBH instance specifications and upgrade CBH instance version.
{ "Version": "1.1", "Statement": [ { "Effect": "Allow", "Action": [ "cbh:instance:upgrade", "cbh:instance:alterSpec" ] } ] }
- Example 2: Denying a user request of restarting a CBH instance
A deny policy must be used together with other policies. If the policies assigned to a user contain both Allow and Deny actions, the Deny actions take precedence over the Allow actions.
The following method can be used to create a custom policy to disallow users who have the CBH FullAccess policy assigned to restart a CBH instance. Assign both CBH FullAccess and the custom policies to the group to which the user belongs. Then the user can perform all operations on CBH except restarting a CBH instance. The following is an example of a deny policy:
{ "Version": "1.1", "Statement": [ { "Effect": "Deny", "Action": [ "cbh:instance:reboot" ] } ] }
- Example 3: Defining permissions for multiple services in a policy
A custom policy can contain the actions of multiple services that are of the global or project-level type. The following is an example policy containing actions of multiple services:
{ "Version": "1.1", "Statement": [ { "Effect": "Allow", "Action": [ "cbh:instance:create" ] }, { "Effect": "Allow", "Action": [ "vpc:subnets:get" ] }, { "Effect": "Allow", "Action": [ "ecs:cloudServerFlavors:get" ] } ] }
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.