Concepts

• 1: Architecture
• 2: Identity
• 2.1: Project Management
• 2.2: Role Based Access Control
• 2.2.1: Understanding Policy
• 2.2.2: Understanding Role
• 3: Inventory
• 3.1: Monitoring
• 4: Alert Manager
• 5: Cost Analysis

1 - Architecture

2 - Identity

2.1 - Project Management

2.2 - Role Based Access Control

How RBAC Works

Define who can access what to who and which organization (project or domain) through SpaceONE's RBAC (Role Based Access Control).

For example, the Project Admin Role can inquire (Read) and make several changes (Update/Delete) on all resources within the specified Project. Domain Viewer Role can inquire (Read) all resources within the specified domain. Resources here include everything from users created within SpaceONE, Project/Project Groups, and individual cloud resources.

Every user has one or more roles, which can be assigned directly or inherited within a project. This makes it easy to manage user role management in complex project relationships.

Role defines what actions can be performed on the resource specified through Policy. Also, a Role is bound to each user. The diagram below shows the relationships between Users and Roles and Projects that make up RBAC.

This role management model is divided into three main components.

• Role. It is a collection of access right policies that can be granted for each user. All roles must have one policy. For more detailed explanation, please refer to Understanding Role.

• Project. The project or project group to which the permission is applied.

• User. Users include users who log in to the console and use UI, API users, and SYSTEM users. Each user is connected to multiple Roles through the RoleBinding procedure. Through this, it is possible to access various resources of SpaceONE by receiving appropriate permissions.

Basic Concepts

When a user wants to access resources within an organization, the administrator grants each user a role of the target project or domain. SpaceONE Identity Service verifies the Role/Policy granted to each user to determine whether each user can access resources or not.

Resource

If a user wants to access a resource in a specific SpaceONE project, you can grant the user an appropriate role and then add it to the target project as a member to make it accessible. Examples of these resources are Server, Project, Alert .

In order to conveniently use the resources managed within SpaceONE for each service, we provide predefined Role/Policy. If you want to define your own access scope within the company, you can create a Custom Policy/Custom Role and apply it to the internal organization.

For a detailed explanation of this, refer to Understanding Role.

Policy

A policy is a collection of permissions. In permission, the allowed access range for each resource of Space One is defined. A policy can be assigned to each user through a role. Policies can be published on the Marketplace and be used by other users, or can be published privately for a specific domain.

This permission is expressed in the form below. {service}.{resource}.{verb} For example, it has the form inventory.Server.list .

Permission also corresponds to SpaceONE API Method. This is because each microservice in SpaceONE is closely related to each exposed API method. Therefore, when the user calls SpaceONE API Method, corresponding permission is required.

For example, if you want to call inventory.Server.list to see the server list of the Inventory service, you must have the corresponding inventory.Server.list permission included in your role.

Permission cannot be granted directly to a user. Instead, an appropriate set of permissions can be defined as a policy and assigned to a user through a role. For more information, refer to Understanding Policy.

Roles

A role is composed of a combination of an access target and a policy. Permission cannot be directly granted to a user, but can be granted in the form of a role. Also, all resources in SpaceONE belong to Project. DOMAIN, PROJECT can be separated and managed.

For example, Domain Admin Role is provided for the full administrator of the domain, and Alert Manager Operator Role is provided for event management of Alert Manager.

Members

All cloud resources managed within SpaceONE are managed in units of projects. Therefore, you can control access to resources by giving each user a role and adding them as project members.

Depending on the role type, the user can access all resources within the domain or the resources within the specified project.

• Domain: You can access all resources within the domain.
• Project: You can access the resources within the specified Project.

Project type users can access resources within the project by specifically being added as a member of the project.

If you add as member of Project Group, the right to access all subordinate project resources is inherited.

Organization

All resources in SpaceONE can be managed hierarchically through the following organizational structure.

All users can specify access targets in such a way that they are connected (RoleBinding) to the organization.

• Domain : This is the highest level organization. Covers all projects and project groups.
• PROJECT GROUP : This is an organization that can integrate and manage multiple projects.
• Projects : The smallest organizational unit in SpaceONE. All cloud resources belong to a project.

2.2.1 - Understanding Policy

Policy

Policy is a set of permissions defined to perform specific actions on SpaceONE resources. Permissions define the scopes that can be managed for Cloud Resources. For an overall description of the authority management system, please refer to Role Based Access Control.

Policy Type

Once defined, the policy can be shared so that it can be used by roles in other domains. Depending on whether or not this is possible, the policy is divided into two types.

• MANAGED: A policy defined globally in the Repository service. The policy is directly managed and shared by the entire system administrator. This is a common policy convenient for most users.
• CUSTOM: You can use a policy with self-defined permissions for each domain. It is useful to manage detailed permission for each domain.

Policy can be classified as following according to Permission Scope.

• Basic: Includes overall permission for all resources in SpaceONE.
• Predefined : Includes granular permission for specific services (alert manager, billing, etc.).

Managed Policy

The policy below is a full list of Managed Policies managed by the CloudONE team. Detailed permission is automatically updated if necessary. Managed Policy was created to classify policies according to the major roles within the organization.

Custom Policy

If you want to manage the policy of a domain by yourself, please refer to the Managing Custom Policy document.

2.2.2 - Understanding Role

Role structure

Role is a Role Type that specifies the scope of access to resources as shown below and the organization (project or project group) to which the authority is applied. Users can define access rights within each SpaceONE through RoleBinding.

Role Example

Example: Alert Operator Role

---
results:
  - created_at: '2021-11-15T05:12:31.060Z'
    domain_id: domain-xxx
    name: Alert Manager Operator
    policies:
      - policy_id: policy-managed-alert-manager-operator
        policy_type: MANAGED
    role_id: role-f18c7d2a9398
    role_type: PROJECT
    tags: {}

Example : Domain Viewer Role

---
results:
- created_at: '2021-11-15T05:12:28.865Z'
  domain_id: domain-xxx
  name: Domain Viewer
  policies:
  - policy_id: policy-managed-domain-viewer
    policy_type: MANAGED
  role_id: role-242f9851eee7
  role_type: DOMAIN
  tags: {}

Role Type

Role Type specifies the range of accessible resources within the domain.

• DOMAIN: Access is possible to all resources in the domain.
• PROJECT: Access is possible to all resources in the project added as a member.

Please refer to Add as Project Member for how to add a member as a member in the project.

Add Member

All resources in SpaceONE are hierarchically managed as follows. The administrator of the domain can manage so that users can access resources within the project by adding members to each project. Users who need access to multiple projects can access all projects belonging to the lower hierarchy by being added to the parent project group as a member. For how to add as a member of the Project Group, refer to Add as a Member of Project Group.

Role Hierarchy

If a user has complex Rolebinding within the hierarchical project structure. Role is applied according to the following rules.

For example, as shown in the figure below, the user stark@example.com is bound to the parent Project Group as Project Admin Role, and the lower level project is APAC. When it is bound to Project Viewer Role in Roles for each project are applied in the following way.

• The role of the parent project is applied to the sub-project/project group that is not directly bound by RoleBinding.
• The role is applied to the subproject that has explicit RoleBinding. (overwriting the higher-level role)

Default Roles

All SpaceOne domains automatically include Default Role when created. Below is the list.

Managing Roles

Roles can be managed by the domain itself through spacectl. Please refer to the Managing Roles document.

3 - Inventory

3.1 - Monitoring

4 - Alert Manager

5 - Cost Analysis