How does AutoMQ's BYOC mode manage cloud permissions

Editorial Highlight: AutoMQ, the next-gen Kafka, boasts 100% compatibility with Apache Kafka, potential cost reductions up to 10x, and unprecedented elasticity. Its BYOC (Bring Your Own Cloud) strategy facilitates data and control plane deployments within the user's VPC, ensuring robust data privacy - an ideal solution for data sovereignty-driven users. This write-up initially delves into primary cloud provider permission systems, then elucidates how AutoMQ's BYOC model procures permissions. Enjoy this insightful exploration.

Cloud Provider Authorization Mechanisms

Cloud technology service providers need to possess essential capabilities like API integration and a robust user system. These, along with permission and user management functionalities, constitute Identity and Access Management (IAM). IAM typically comprises two critical components - Authentication (Authn) and Authorization (Authz).

• Authentication: Primarily responsible for user identity verification. This includes features like login, essentially distinguishing between User A and User B.

• Authorization: Primarily used for controlling access after user authentication, typically distinguishing resource access restrictions based on various identities. Essentially, it determines if a user is authorized to access certain resources, such as link a or link b, after login.

Next, explore common Authn and Authz solutions offered by cloud service providers:

Sub-account System

In typical application systems, users often register accounts and log in to access various features. This intuitive account system is also employed by initial cloud service providers. For instance, in the case of virtual machines, these are exclusive to the creator, disallowing other users to access or use them.

However, as the number of enterprise customers increases, the existing account system has shown some disadvantages: An enterprise often has many employees, all of whom use the features and services provided by the cloud provider. If each user registers an account and manages resources, the virtual machines within the enterprise will be dispersed among many accounts, making management extremely unfavorable. Therefore, AWS has introduced a master-subaccount system, with accounts divided into two levels: root accounts and sub-accounts. The ownership of resources belongs to the root account, often representing an enterprise or virtual entity. Sub-accounts are created and managed by the root account, can create and use resources, but have no ownership association with resources. The cancellation of a sub-account does not affect the actual resources, which effectively solves the scenario of enterprise customers using cloud resources. However, for individual users, this system is slightly complex, and if the enterprise uses more than one root account for some reason, managing these root accounts is also a complex task. Solutions to this type of problem will be discussed in detail in subsequent articles and will not be further extended at this time.

API Authentication Method

To solve the issue of multi-user cloud resource usage, enterprises may advance the construction of automated systems. This requires the use of APIs to interface with the lifecycle and related operations of resources, making the common username and password login mode unfeasible.

The mainstream API authentication methods currently include the following:

• Basic Auth: This is a basic http authentication scheme that stores static authentication information in the http header. It's simple but poses significant security risks. The authentication information stored in plaintext under the http protocol is easily intercepted and copied. It was less used in the era before the widespread adoption of https, but with the continuous popularization and development of https, it has become the simplest and most efficient authentication method.

• AccessKeyPair: This is the mainstream authentication method currently adopted by cloud vendors. It signs the content of the request, ensuring data security under the http plaintext protocol.

Although AccessKeyPair ensures the security of the transmission process, the Secret on the client side is often stored in plaintext, which still poses a significant security risk. Therefore, many cloud vendors have launched virtual machine authorization schemes based on infrastructure.

Users can directly bind the authorization information to the virtual machine. When accessing the API, they can obtain temporary Access information through the internal interface, thus achieving API authentication without saving AccessKeyPair, significantly reducing the risk of being attacked.

Access Policy

Within the Authz realm, there are numerous authorization management solutions. I will list three common types here:

• ACL: Users are directly bound to permission points. In cases where the number of permission points is low and the domain model is simple, this solution is the simplest and most efficient. Moreover, it supports the application and process of permissions well.

• RBAC: The most common authorization model, RBAC uses the concept of "roles" to aggregate permissions together. This allows users with the same permissions to quickly reuse roles, reducing repetitive authorization operations.

• ABAC: Attribute-Based Access Control, compared to RBAC, ABAC offers more expandability and programmability. The description of authority not only includes the authority point information but often extends to various functions based on resource attributes, such as restrictions on resources and activation conditions.

Major cloud providers currently adopt the ABAC permission model. Taking Alibaba Cloud and AWS as examples, let's briefly introduce the composition of permission policies:

• Policy: Represents an independent permission policy that can be directly bound to the authorized subject.

• Statement: Represents a permission description statement. A Policy can contain multiple Statements, the logical relationship of which is related to Effect, as described below.

• Effect: An element in the Statement, with two enumerations: Allow and Deny. Allow is most commonly used, indicating that all information described in the statement is permitted, with different Allow statements having a logical OR relationship. Deny indicates a mandatory negative meaning, has the highest priority, and takes precedence when conflicts occur between Allow and Deny, with different Deny statements having a logical AND relationship.

• Action: An element in the Statement, representing the permissions included in the statement, supporting wildcard.

• Resource: An element in the Statement, representing the resources involved in the statement, supporting wildcard.

• Condition: An element in the Statement, the most extendable element, representing the conditions under which the statement takes effect. It has extensive expandability, including matching expressions for tags, attributes, environments, etc.

• NotAction and NotResource: Elements in the Statement, less commonly used, represent permissions and resources not included in the statement, equivalent to a blacklist mechanism.

Roles and STS

In response to conventional management requirements, we have established solutions. With the development of cloud computing, the number of customers using the cloud is increasing. Often, we need to access resources within other root account domains, where conventional IAM management plans can no longer meet the needs. It is in such scenarios that cloud vendors introduce the concept of roles.

Here, the role differs from that in permission management and falls within the same domain as sub-accounts, representing the subject of authorization. It can be bound with permission policies, representing a virtual identity. When using a role, the "assumption" mechanism is often employed, that is, the use scenario of a role. The main types of subjects that can be assumed can be divided into several categories:

• Account: The basic pattern of using APIs across accounts, where authorized users are permitted to assume this role.

• Federated Login IDP: In federated login scenarios, permitted IDP identities can assume this role.

• Cloud Service: The cloud provider's services are allowed to execute authorized APIs in the role of user-managed identities.

• Virtual Machine: Strictly speaking, this also uses the cloud service principal model, used to implement the virtual machine authorization scenarios mentioned above.

Architecture Model of AutoMQ BYOC

As a cloud-native architecture product, AutoMQ leverages the fundamental capabilities of the cloud to provide more modern product abilities. In BYOC (Bring Your Own Cloud) mode, AutoMQ delivers services based on users' own cloud resources, ensuring user independence and security, and maximizing the utilization of users' existing cloud vendor discounts and resource systems.

Virtual Machine Authorization Mechanism

In the BYOC mode, AutoMQ employs virtual machine authorization as the primary authorization mode. Users only need to grant the relevant resource permissions required by AutoMQ to the console's VM to complete the environment initialization. The console propagates permissions to the AutoMQ instance infrastructure through the PassRole method, accomplishing the authorization.

Implementing Tag-Based Permission Constraints

Cloud providers deliver tag-based access control features, effectively narrowing permissions scope and mitigating risks associated with permission escalation.

Currently, all resources created by AutoMQ have been added with the 'automqVendor' tag. Taking Alibaba Cloud as an example, you can add restrictions to 'automqVendor' in the Condition section of the permission Policy, to limit the scope of resource operations:

• Limit the scope of resource creation, only resources with the automqVendor:automq tag can be created.

{
    "Condition": {
        "StringEquals": {
            "acs:RequestTag/automqVendor": "automq"
        }
    }
}

• Restrict the scope of resource usage, operations can only be performed on resources with the automqVendor:automq tag.

{
    "Condition": {
        "StringEquals": {
            "acs:ResourceTag/automqVendor": "automq"
        }
    }
}

Conclusion

This article provides a brief introduction to the basic knowledge of permissions related to cloud providers and some solutions for permission control by AutoMQ. We welcome everyone to pay attention to AutoMQ's products.