Access Management Overview
Klarity ImageFactory uses a robust security model to ensure that only authorized users and systems can interact with your golden image resources. The platform implements a Role-Based Access Control (RBAC) system that provides granular control over every operation.
Access Mechanisms
ImageFactory supports two primary ways to authenticate and interact with the platform.
1. User Access (Auth0/OIDC)
This mechanism is designed for human interaction. It uses Auth0 as the identity provider and supports OpenID Connect (OIDC) for secure authentication.
- Usage: Primarily used by the Web UI and when interacting directly with the GraphQL API through a browser.
- Authentication: Users log in via the Nordcloud single sign-on portal.
- Session Management: Auth0 handles session tokens and renewals automatically within the browser environment.
2. API Key Access (Programmatic)
For automation, CI/CD pipelines, and external integrations, ImageFactory provides API keys.
- Usage: Used by build scripts, deployment tools, and custom integrations.
- Authentication: The secret key is passed in the request header.
- Scope: API keys are tied to a specific customer and inherit permissions through role bindings.
The RBAC Model
The access control system is built on three core concepts: Roles, Rules, and Role Bindings.
Roles and Rules
A Role is a named collection of permissions. These permissions are defined by Rules. Each rule specifies what actions can be performed on which resources.
| Component | Description |
|---|---|
| Resource | The object being acted upon (e.g., TEMPLATE, ACCOUNT). |
| Action | The operation being performed (e.g., VIEW, CREATE). |
Role Bindings
A Role Binding is the link that assigns a Role to a subject. A subject can be either a User (identified by email) or an API Key (identified by its ID).
Permissions are additive. If a user has multiple role bindings, they possess the union of all permissions granted by those roles.
Supported Resources
Permissions can be granted for the following resource types:
- ACCOUNT: Cloud provider credentials and account settings.
- API_KEY: Management of programmatic access keys.
- AUDIT_LOG: Access to system activity records.
- COMPONENT: Image building blocks and custom scripts.
- NOTIFICATION_GROUP: Alerting and notification configurations.
- ROLE: Definition of permission sets.
- ROLE_BINDING: Assignment of roles to subjects.
- TEMPLATE: Golden image definitions and build configurations.
- VARIABLE: Secure customer secrets and build variables.
- ANY: A wildcard that encompasses all resource types.
Supported Actions
The following actions define the level of access:
- VIEW: Read-only access to resource metadata and status.
- CREATE: Permission to provision new resources.
- UPDATE: Ability to modify existing resource configurations.
- DELETE: Permission to remove resources from the system.
- ANY: A wildcard that allows all of the above actions.
Access Scoping
ImageFactory operates with two levels of access scope to maintain multi-tenant security.
Customer-Scoped Access
Most operations in ImageFactory are scoped to a specific customer. A user or API key must have a role binding within that customer's context to view or manage their templates, accounts, and variables. This ensures strict isolation between different organizations using the platform.
Global Admin Access
System administrators who require the ability to manage global components, distributions, and cross-customer settings are granted wildcard access. Users with a wildcard (*) customer assignment have administrative privileges across the entire ImageFactory instance. This level of access is typically reserved for platform operators and support teams.
Permission Evaluation
When a request is made to the ImageFactory API, the system evaluates the subject's permissions:
- Identify the subject (User email or API Key ID).
- Retrieve all active Role Bindings for that subject within the requested customer scope.
- Aggregate all Rules from the associated Roles.
- Check if any Rule explicitly allows the requested Action on the target Resource.
If no matching rule is found, the request is rejected with a 403 Forbidden error.