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` 

![Screenshot 2025-05-30 at 12 25 55 PM](https://github.com/user-attachments/assets/c05dbb81-3db6-4a90-bb4b-f86bf8fcadb8)