How Komodo DevOps Permission is Working?

Komodo's security model is built on a multi-layered permissioning system, ensuring granular control over access to its resources. This isn't just about simple on/off access; it's a sophisticated system designed for scalability and flexibility, allowing administrators to fine-tune permissions for individual users or groups to match specific roles and responsibilities. Forget clunky, all-or-nothing access controls; Komodo offers a precise, tailored approach.

Instead of assigning permissions directly to individual users – a cumbersome approach that becomes unwieldy as your team grows – Komodo strongly encourages the use of User Groups. Think of these groups as containers for users sharing similar access needs. Permissions are then applied to these groups, providing an efficient way to manage access rights for multiple users simultaneously. This method mirrors the familiar and effective approach used by Linux systems, allowing for a hierarchical and easily manageable system.

This group-based permissioning is particularly vital when dealing with many users. Komodo further enhances this efficiency through Resource Syncs, streamlining the process of defining and assigning User Groups across various resources. This centralized management significantly reduces the administrative burden, especially in large-scale deployments.

At the core of Komodo's permission model are four distinct permission levels:

• None: This is the default for non-admin users and denies all access to the specified resource. The user won't see the resource in the graphical user interface (GUI) or via API queries. Any attempts to interact with the resource, whether viewing or modifying, will be blocked. However, this default behavior can be altered using the environment variable KOMODO_TRANSPARENT_MODE=true, which changes the behavior of the system.

• Read: This grants basic access. Users can view the resource in the GUI, examine its configuration, and access associated logs. However, they are restricted from making any changes or triggering actions. When KOMODO_TRANSPARENT_MODE=true is set, this becomes the base permission level for all resources and all users.

• Execute: This level allows users to perform actions on the resource, such as initiating a build process or triggering a redeployment. Modifications to the resource's configuration, however, remain prohibited.

• Write: This provides complete control. Users with "Write" permission can perform any action, modify the configuration, and even delete the resource. It's the highest level of access.

Komodo's flexibility extends beyond individual resources. It allows for the definition of global permissions. These permissions apply to all resources of a specific type. For example, you can grant a user group "Execute" permission on all Build resources and "Read" permission on all Stack resources. This is defined using TOML configuration, providing a clean and efficient way to manage default access levels. Here's an example of how this global permission configuration would look:

[[user_group]]
name = "groupo"
users = ["mbecker20", "karamvirsingh98"]
all.Build = "Execute"  # Group members can execute all builds (but not modify config)
all.Stack = "Read"     # Group members can view all Stacks and logs (but not deploy or update)
    

This global configuration serves as a baseline. Komodo allows for overriding these global permissions on a per-resource basis. You can grant a user or group a higher permission level for specific resources, even if their global permission is lower. This granular control allows for precise tailoring of access rights to meet specific requirements:

permissions = [
  { target.type = "Stack", target.id = "my-stack", level = "Execute" },
  # Use regex for multiple resources; e.g., grant "john" execute access to all their Stacks
  { target.type = "Stack", target.id = "\\^john-(.+)$\\", level = "Execute" },
]
    

The use of regular expressions in the target.id field provides a powerful mechanism for managing permissions across multiple resources that follow a naming pattern, significantly streamlining the permission management process for large-scale deployments.

Administrators play a crucial role in managing Komodo's permission system. A Super Admin—only the very first user created receives this designation—possesses unrestricted access to all resources and the ability to modify other users' permissions. This role is essential for maintaining the overall security posture of the system. The Super Admin's privileges are defined within the user document in the database using the super_admin: true setting. They have complete oversight and are vital to maintaining the system's security.

The administration interface includes a “Make Admin” button located on individual user pages (/users/${user_id}). This provides a simple and intuitive way for Super Admins to elevate other users to the Admin role.

Komodo admins also manage user accounts. New users, by default, do not have immediate access. This behavior can be altered using the KOMODO_ENABLE_NEW_USERS=true environment variable. Admin intervention is required to activate a user's account, a step performed from the Users tab within the Settings page. Administrators also possess the ability to disable user accounts, effectively revoking all access to both the GUI and the API.

Beyond the resource-specific permissions, Komodo offers configurable global permissions governing the creation of servers and builds. Only users with these permissions, along with admins, can add new servers to Komodo or create new builds, providing an additional layer of control over system expansion and resource management.

Komodo's permissioning system is designed to be robust, scalable, and adaptable. Its multi-layered approach, combined with the use of User Groups, global permissions, and powerful features like regular expression matching for targeted access control, provides a comprehensive solution for managing access rights in complex environments. The system's flexibility ensures that security requirements are met without sacrificing usability or efficiency.