Changelog

🚨 This release moves official support to FerretDB v2. Users who deployed v1.17.5 or before using Postgres / Sqlite option are using FerretDB v1 and should eventually migrate using the FerretDB v2 Update Guide. Note that this is not a change to Komodo itself, only to the list of supported Mongo stand-ins. Users can update to 1.18.0 and continue to use FerretDB v1 if they wish.

🚨 Admins managing user permissions may need to modify the user access rules. In particular, container logs, docker inspect on containers, and terminal access are now gated behind additional permissions (for non admin users).

Specific Permissions

The main purpose of this release is to refine the access control / permissions system in Komodo. In 1.17.5 and before, access to resources was controlled only via access level (Read, Execute, Write). These levels provide access to the associated /read, /execute, and /write methods on resources, and it worked pretty well to provide RBAC.

Now with more potentially sensitive features, this is not quite enough to provide granular access control. To address this, specific permissions have been introduced in addition to Read, Execute, and Write levels.

• Logs: User can retrieve docker / docker compose logs on the associated resource.
  • Valid on Server, Stack, Deployment.
  • For admins wanting this permission by default for all users with read permissions, see below on default user groups.
• Inspect: User can "inspect" docker containers.
  • Valid on Server, Stack, Deployment.
  • On Servers: Access to this api will expose all container environments on the given server,
    and can easily lead to secrets being leaked to unintended users if not protected.
• Terminal: User can access the associated resource's terminal.
  • If given on a Server, this allows server level terminal access, and all container exec priviledges (Including attached Stacks / Deployments).
  • If given on a Stack or Deployment, this allows container exec terminal (even without Terminal on Server).
• Attach: User can "attach" other resources to the resource.
  • If given on a Server, allows users to attach Stacks, Deployments, Repos, and Builders.
  • If given on a Builder, allows users to attach Builds.
• Processes: User can retrieve the full running process list on the Server.

The above specific permissions are defined in a list alongside their level. This list is open for future expansion / and the associated implementations may be refined in future releases as well. The list is also given here: https://komo.do/docs/permissioning#specific-permissions.

Default User Groups

Sometimes you will want to set a "baseline" set of permissions that all users will have on the Komodo instance. Previously this could only be done in very barebones way, by setting KOMODO_TRANSPARENT_MODE=true on the Komodo Core container. This would give all users a base level of "Read" on all resources.

In addition to the above permissions features, this release also adds an everyone mode to User Groups. If you enable this mode on a User Group, then all users will inherit those permissions as a base.

TOML Examples

As before, you are able to manage User Groups in Resource Syncs.

# Can define default rules in the Everyone group
[[user_group]]
name = "Everyone"
everyone = true
 # Can see servers, but no Logs / Inspect / Terminal permission
all.Server = "Read"
# This doesn't elevate specific stacks from None permissions,
# but if the user gets greater than Read from another permission,
# they will inherit the specific permissions
all.Stack = { level = "None", specific = ["Inspect", "Logs", "Terminal"] }
all.Deployment = { level = "None", specific = ["Inspect", "Logs", "Terminal"] }
# Allow users to see all Builders, and attach builds to them.
all.Builder = { level = "Read", specific = ["Attach"] }

[[user_group]]
name = "Stack Read"
users = ["user1", "user2"]
# Because of the "Everyone" group, don't need to redefine
# the specific permissions. User will have "Inspect", "Logs", etc.
all.Stack = "Read"

[[user_group]]
name = "Immich Manager"
users = ["user1", "user2"]
# Give per-service management to select users
permissions = [
  { target.type = "Server", target.id = "immich-server", level = "Write", specific = ["Logs", "Inspect", "Terminal"] },
  { target.type = "Stack", target.id = "immich", level = "Write"  }
]

[[user_group]]
name = "Dev Manager"
users = ["user1", "user2"]
# Manage wildcard access to specific resources, in this case with the `dev-` name prefix.
# Note. Doesn't work with Sync "Commit". Only "Execute" direction.
permissions = [
  { target.type = "Server", target.id = "dev-*", level = "Read" },
  { target.type = "Deployment", target.id = "dev-*", level = "Write"  },
  { target.type = "Build", target.id = "dev-*", level = "Write"  },
]

Misc.

• Server: Remove limitations on name. Names can now include Capital letters and spaces. They still have to be unique.
  • Also can use any name for Procedures, Actions, Resource Syncs, Builders and Alerters.
  • Stacks / Deployments / Builds / Repos still have the same naming restrictions (no capitals / spaces)
• Alerter: Ntfy endpoints now support configuring email. Note that you must also make sure SMTP is configured on the Ntfy server. By @FelixBreitweiser in #493
• Resource Sync: Fix issue with User Groups showing "Pending" repeatedly / eroneously.
• UI: Fix the inline rename behavior when renaming multiple resources in a row.
• Startup log: Specify pretty_startup_config = true to get more human readable initial config log.
  • Core Env: KOMODO_PRETTY_STARTUP_CONFIG=true
  • Periphery Env: PERIPHERY_PRETTY_STARTUP_CONFIG=true