CNCF Authorization Model
The CNCF (Cloud Native Component Framework) authorization model is not a simple adoption of role-based or permission-based approaches, but a unified structure that normalizes them into a consistent runtime decision model.
This article explains the model through its core concepts—capability and guard—and its dual-layer structure: operation-level and resource-level authorization.
Authorization Model Overview
The CNCF authorization model is structured around capability and guard. Capability represents permissions (what is allowed), while guard represents constraints or denials (whether it is allowed in the current context).
By absorbing negative conditions and exceptional constraints into guards, the model prevents combinatorial explosion on the capability side and keeps the system simple.
Authorization mechanisms (Permission, RBAC, ACL, ReBAC, ABAC) are not evaluated directly, but are normalized into capabilities or guards before evaluation.
Capability aggregates mechanisms that grant permissions, such as Permission, RBAC, and ACL. Guard aggregates constraint-based mechanisms such as ReBAC and ABAC.
Why This Model Is Needed
Traditional authorization approaches often suffer from two problems:
-
ad hoc checks scattered across application code
-
overly complex policy systems that are hard to use
CNCF aims to address these issues with the following principles.
-
Provide a baseline level of security with minimal configuration
-
Offer configuration options that are simple enough for everyday development
-
Allow increasing the precision of authorization when needed
Capability: What Is Allowed
In CNCF, authorization is designed around capabilities. A capability represents the minimal unit of "what can be done", and authorization decisions are ultimately based on whether required capabilities are satisfied.
A capability represents a normalized "what you can do".
Examples:
-
collection:blob:create -
collection:blob:read -
association:blob_attachment:create -
store:blobstore:status
All authorization elements are ultimately transformed into capabilities.
This separation keeps the authorization model simple while enabling practical and manageable configurations in real systems.
Capability uses the following three authorization mechanisms.
-
Permission
-
RBAC
-
ACL
Permission
Permissions provide a practical representation of capabilities. They are used to describe access control at the entity level in a compact form.
Entities use a compact owner/group/other permission model.
owner: read/write/execute
group: read/write/execute
other: read/write/executeThis is a compact representation that is mapped to capabilities at runtime.
RBAC
RBAC (Role-Based Access Control) assigns permissions to roles to control access. In CNCF, roles are interpreted as sets of capabilities and serve as a mechanism for supplying capabilities.
Guards: Constraints and Conditions
A guard controls whether a capability can be used and does not grant permissions by itself. ABAC expresses constraints based on attributes, while ReBAC expresses constraints based on relationships between subject and object, complementing cases that are difficult to express with ABAC alone.
Guards use the following two authorization mechanisms.
-
ABAC
-
ReBAC
ABAC
ABAC (Attribute-Based Access Control) controls access based on attributes of users and resources. In CNCF, these conditions are represented as guards.
ReBAC
ReBAC (Relationship-Based Access Control) controls access based on relationships between subject and object. For example, relationships such as "is owner" or "is assignee" are evaluated as guards.
ReBAC is important for expressing authorization constraints based on relationships that are difficult to model with ABAC alone. For example, whether a user is the owner of a specific resource is evaluated as a relationship rather than a simple attribute comparison.
For example, the following relationships are evaluated as guards:
-
author of a post
-
assignee
News Operation Example
Consider an operation on a news article.
For example, attaching an image to an article may appear to be a simple operation.
In reality, however, multiple resources are involved:
-
the article
-
the image
-
the attachment relationship
Whether this operation is allowed depends on the relationship between the subject and the article.
For example, being the author of the article or an assigned editor.
Thus, even a single operation like attaching an image involves both relationships among multiple resources and relationships between the subject and resources.
In such cases, simple Permission or RBAC models are insufficient, and relationship-based authorization (ReBAC) becomes essential.
SecurityObject
There are two types of SecurityObjects that serve as authorization targets.
-
Operation
-
Resource
Summary
The CNCF authorization model reduces complexity and configuration explosion by centering on capability and guard.
Permission, RBAC, and ACL are normalized into capabilities, while ReBAC and ABAC are normalized into guards, resulting in a unified evaluation model.
This structure enables a simple yet extensible authorization foundation.
References
Glossary
- Cloud Native Component Framework (CNCF)
-
Cloud Native Component Framework (CNCF) is a framework for executing cloud application components using a single, consistent execution model. Centered on the structure of Component, Service, and Operation, it enables the same Operation to be reused across different execution forms such as command, server (REST / OpenAPI), client, and script. By centralizing quality attributes required for cloud applications—such as logging, error handling, configuration, and deployment—within the framework, components can focus on implementing domain logic. CNCF is designed as an execution foundation for literate model-driven development and AI-assisted development, separating what is executed from how it is invoked.