v1.18.0
moghtech/komodov1.18.0May 30, 2025by mbecker20
AI Summary
This release moves official support to FerretDB v2 and introduces a granular specific permissions system (Logs, Inspect, Terminal, Attach, Processes) alongside an 'everyone' mode for User Groups.
Key Highlights
- Moved official support to FerretDB v2
- Introduced granular specific permissions (Logs, Inspect, Terminal, Attach, Processes)
- Added 'everyone' mode to User Groups for baseline permissions
Breaking Changes
- Container logs, docker inspect, and terminal access are now gated behind specific permissions
- Requires migration from FerretDB v1 to v2 (if using Mongo stand-in)
New Features
- Specific permissions system
- User Group 'everyone' mode
- Name restrictions relaxed for Servers, Procedures, Actions, etc.
- Ntfy email support
- OIDC userinfo endpoint changes
Full Release Notes
# 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](https://github.com/moghtech/komodo/blob/main/bin/util/docs/copy-database.md#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 `Build`, allows users to attach the Build to Deployments
- 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.
```toml
# 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`
