Concepts

• 1: Architecture
• 2: Identity
• 2.1: Provider & Service Accounts
• 2.2: Project Management
• 2.3: Role Based Access Control
• 2.3.1: Understanding Policy
• 2.3.2: Understanding Role
• 3: Inventory
• 3.1: Inventory Collector
• 3.2: Monitoring
• 4: Monitoring
• 5: Alert Manager
• 6: Cost Analysis

1 - Architecture

Micro Service Architecture

Cloudforet adopts a microservice architecture to provide a scalable and flexible platform. The microservice architecture is a design pattern that structures an application as a collection of loosely coupled services. Each service is self-contained and implements a single business capability. The services communicate with each other through well-defined APIs. This architecture allows each service to be developed, deployed, and scaled independently.

The frontend is a service provided for web users, featuring components such as console and console-api that communicate directly with the web browser. The core logic is structured as independent microservices and operates based on gRPC to ensure high-performance and reliable communication.

Each core logic can be extended by plugin services. Every plugins are developed and deployed independently, and they can be added, removed or upgraded without affecting the core logic.

API-Driven design

API-Driven design in microservice architecture is a pattern where APIs (Application Programming Interfaces) are the primary way that services interact and communicate with each other. This approach emphasizes the design of robust, well-defined, and consistent APIs that serve as the contracts between microservices. Here’s a detailed explanation of the API-Driven design pattern:

gRPC as the Communication Protocol

gRPC is a high-performance, open-source, universal RPC (Remote Procedure Call) framework that is widely used in microservice architectures. It uses HTTP/2 as the transport protocol and Protocol Buffers (protobuf) as the interface definition language. gRPC provides features such as bidirectional streaming, flow control, and authentication, making it an ideal choice for building efficient and reliable microservices.

Loose Coupling

API-Driven design promotes loose coupling between microservices by defining clear and well-documented APIs. Each microservice exposes a set of APIs that define how other services can interact with it. This allows services to evolve independently without affecting each other, making it easier to develop, deploy, and maintain microservices.

Version control

Cloudforet APIs support two types of versioning, core and plugin version. Core version is for communication between micro services for frontend. plugin version of internal communication in a single micro services for implementing API.

API Documentation https://cloudforet.io/api-doc/

Protobuf API Specification https://github.com/cloudforet-io/api

Service-Resource-Verb Pattern

API-Driven design can be effectively explained using the concepts of service, resource, and verb. Here’s how these concepts apply to microservices:

Service

A service in microservice architecture represents a specific business functionality. Each service is a standalone unit that encapsulates a distinct functionality, making it independently deployable, scalable, and maintainable. Services communicate with each other over a network, using lightweight protocols gRPC.

• Example: in the Cloudforet, individual services are identity, repository, or inventory.
  • identity service: manages user authentication and authorization.
  • repository service: manages the metadata for plugins and their versions.
  • inventory service: manages the resources and their states.

Resource

A resource represents the entities or objects that the services manage. Resources are typically data entities that are created, read, updated, or deleted (CRUD operations) by the services.

• Example: in the identity Service, resources include Domain, User, and Workspace.
  • Domain: represents a seperated organization or customer.
  • User: represents a user account.
  • Workspace: represents a logically isolated group contains resources.

Verb

A verb represents the actions or operations that can be performed on resources. These are typically the gRPC methods (get, create, delete, update, list, etc.) in a service. Verbs define what kind of interaction is taking place with a resource.

• Example: in the User resource, verbs include create, get, update, delete, and list.
  • create: creates a new user.
  • get: retrieves the user information.
  • update: updates the user information.
  • delete: deletes the user.
  • list: lists all users.

2 - Identity

2.1 - Provider & Service Accounts

User Experience: Console

Provider

In the context of Cloudforet, a provider is a top-level entity that groups a range of resources. Providers can include cloud providers like Amazon Web Services (AWS), Google Cloud Platform (GCP), and Microsoft Azure, as well as any entity that groups together like software_licence.

Service Account

A service account functions as an identifier for a group of resources within a provider. This means that the service account is used as primary key for distinguishing a specific set of resources.

API Reference

2.2 - Project Management

2.3 - 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.3.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.3.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 - Inventory Collector

How to collect

When user create a collect API call, the collecting task is created, then pushed the queue. Inventory Worker patches the task then execute the task, which is collecting the resources from the plugin.

Collecting Manager

3.2 - Monitoring

4 - Monitoring

5 - Alert Manager

6 - Cost Analysis