Skip to main content

Morio v0.10.0

· 9 min read
Joost De Cock
Joost De Cock
Morio Maintainer

We have released version 0.10.0 of Morio, a new minor release that brings support for the Morio client on MacOS and Windows, as well as allowing you to run multiple EdA service instances, multiple tap-threads, there's a new SNMP Proxy service, and a lot more.

Before we look at what is new in the code, here is a housekeeping announcement:

Morio source code is now hosted on Codeberg​

In anticipation of our 0.10 release, we have migrated the Morio repository from Github to Codeberg.

If you have checked out the Morio repository locally, you can migrate by running these commands (the git remote -v merely shows the config):

git remote -v
git remote set-url origin git@codeberg.org:certeu/morio.git
git remote -v

We have also migrated the MorioHub repository so if you have that checked out, run a similar migration:

git remote -v
git remote set-url origin git@codeberg.org:certeu/moriohub.git
git remote -v

If you are preseeding from moriohub, you will need to update your config.
Just replace github.com with codeberg.org:

preseed:
  git:
    moriohub:
      url: "https://codeberg.org/certeu/moriohub.git"
      ref: develop

Transparent, except for our ego

This migration should be completely transparent, with one exception: It means we have lost all the stars on our repository. So if you'd like to help us settle in at our new Codeberg home, why not star our repository there, it does help legitimize our work.

A Morio client for MacOS and Windows​

We now support the Morio client on MacOS and Windows, you can get them here:

Or simply bookmark repo.morio.it which has links to all the packages we support.

This Morio client is just like the one for Linux, that is it bundles Filebeat (for logs), Metricbeat (for metrics), and Auditbeat (for audit), alongside the morio client binary.

That being said, the client for Windows is a bit different in the sense that it also comes with Winlogbeat which collects windows event logs.

Along with these new client releases, we've also published the macos-system and windows-system modules on MorioHub.

A new SNMP Proxy service​

While the Morio client makes collecting observability data easy, you probably have some devices where you cannot deploy it, like your routers and switches for example. These devices can be a bit of a hassle to monitor, as they typically expose their metrics over SNMP.

To facilitate that use-case, Morio now ships with an SNMP Proxy service (snmpproxy) that provides an SNMP-to-HTTP bridge so you can simply point metricbeat to the correct Morio URL, and it will go ahead and fetch the data over SNMP for you, and return it.

We're already using it, and it works great. Under the hood, it uses the Prometheus snmp_exporter.

Support for fine-grained access policies​

Access control in Morio so far has been role-based (role-based access control or RBAC). That is a common approach and works well for things where we -- as developers of Morio -- can make decisions about what role can do what:

  • Users can see metrics
  • Operators can change settings

and so on.

Things get more complicated when it comes accessing data inside Morio:

  • Can Dave from accounting access the metrics of the database server?
  • Can Sheila from the dev team access the logs of the backend API?

We cannot possibly answer these questions, only you can. So rather than rely on RBAC for this, we implemented an additional ABAC layer (ABAC stands for attirbute-based access control) that lets you write a fine-grained access policy.

Below is an example of policy rules:

# Allow support staff to manage their EdA instance
access.eda-support:
  when:
    url.glob: /eda-support/**
    label: oidc/sso/group/team.support
  then: allow
# Also allow them read-only access to the infra EdA instance (GET only)
access.eda-infra:
  when:
    url.glob: /eda-infra/**
    label: oidc/sso/group/team.support
    method: GET
  then: allow

We are using the various labels that are set on the account. These labels depend on the identity provider. In this example, they are attributes that are provided by an OIDC identory provider.

In the second rule example, we are further limiting the access to GET requests only, which in the case of the EdA service makes the service read-only.

tip

You can use an access policy to control access to all URLs in Morio. It does not apply to direct access to the broker (native Kafka) for which the broker has its own ACL.

Support for multiple EdA instances​

In v0.9 we added support for Morio's EdA service, which brings event-driven automation. Since then, we've come to rely on this in a big way, it has proven to be so useful that colleagues in other teas have been asking us to be able to use it.

The issue with that is that Node-RED, which underpins the service, does not support multi-tennancy, or even fine-grained access control. We did want to give our colleagues access to all the EdA goodness, but we did not want to hand over access to our EdA service because it was running certain sensitive flows.

So now, you can configure Morio to run multiple instances of the EdA service. You can decide what (flanking) nodes to run them on, and they each have their own URL prefix. This, in combination with our new fine-grained access control policies, allows you to setup different EdA instances for different teams, as we have done.

warning

The EdA service is a low-code tool that gives users great flexibility, including the ability to write their own custom code and have the EdA container run it for you.

As this code runs within a container on the Docker network that spans various Morio services, a malicious user can use this privileged access to bypass access control.

As a result, access to EdA should be considered privileged access, and you should never grant people access to the EdA service if you do not trust them.

Support for multiple Tap threads and metrics​

The Tap service -- Morio's stream processing service -- is one of the hardest working services in Morio. It processes data as it flows through the broker, caching metrics, generating events, and so on.

Previously, you could scale the Tap service horizontally by running it on multiple flanking nodes. However, there is an easier way to scale the service, which is to run multiple threads inside the same Tap container. As long as those threads make sure to use the same Kafka client ID, they will effectively work together to process the messages from the broker.

So, that's exactly what we've implemented, you can now run multiple threads of the Tap service, which will work in tandem so you can scale the service vertically.

Now with metrics

The Tap service has another new trick up its sleeve: It now presents an HTTP endpoint for healthchecks and metrics. Even better, each thread has a unified metrics endpoint that will collect metrics for all threads, so you get a holistic view on how the service is doing with a single API call.

Not that you need to worry about that, we've published the linux-morio-tap module on moriohub to take care of everything.

And a bunch of other improvements​

Client support for joining and leaving inventory groups

You can now join an inventory group (or leave it) from the Morio client.

Custom token endpoint includes container info

Within an EdA instance, you can benefit from a Morio-Vault integration by requesting a custom token that will allow you to authenticated to Vault.

We now will populate that token with info about the container requesting the token, so that you can differntiate between different EdA instances in your Vault policies.

Support for settings overlays on disk

As Morio grows in scope, the settings file also grows. For people looking to manage this with Ansible or another configuration management tool, we now support and overlays.d folder where you can place files with settings overlays.

This allows you to split your configuration into different files making it easier to track changes and more intuitive for support staff.

Auto-create ICMP healthchecks for inventory hosts

For all hosts in the inventory -- or at least all hosts we can resolve -- Morio will now automatically create an ICMP healthcheck.

Ability to configure trusted CAs for health checks

You can no configure trusted CAs so that you can run health checks over TLS to hosts using certificates from internal CAs.

Do not stop non-core containers when stopping moriod service

When stopping the moriod systemd service, we no longer stop all other Morio containers. Instead, we support a new command-line option to do so.

Upgraded various components

  • Upgraded Docusaurus from 3.7.0 to 3.8.0
  • Upgraded Elastic Heartbeat from 8.17.4 to 8.19.11
  • Upgraded Node-RED from 4.0.9 to 4.1.5
  • Upgraded Redpanda from v24.2.21 to v24.3.18
  • Upgraded Redpanda Console from v2.8.5 to v2.8.10
  • Upgraded Rqlite from 8.36.16 to 8.43.4
  • Upgraded StepCA from 0.28.3 to 0.29.0
  • Upgraded Traefik from v3.3.5 to v3.6.8
  • Upgraded Vector from 0.46.1-debian to 0.53.0-debian

Locked ValKey to more specific version

  • We switched from ValKey 8.1 to ValKey 8.1.5 to avoid differences in container images that are running.

Caveats​

As Morio is not in beta yet, we prioritize features and bug fixes, which means that our documentation is somewhat lagging behind for the time being.

If you have any questions about features that are not documented yet, don't hesitate to reach out to us.