Morio v0.9.0
We have released version 0.9.0 of Morio, a new minor release that brings event-driven automation to Morio.
The new EdA service for event-driven automation
From the very start, we've used the Connect | Stream | Observe | Respond tag line to try and capture the essence of Morio in a few words, and we're happy to announce that with this release we're delivering the final step of that chain: Respond.
Specifically, we've added a new event-driven automation (EdA) service to Morio that is backed by Node-RED. If you're unfamiliar with Node-RED, it is a low-code programming environment for event-driven applications, with a focus on real-time data. Suffice to say it's an excellent fit with Morio and we're really excited about this feature. As a matter of fact, in the short time since we've added it, we've already leveraged it for a number of our own internal automations. (At CERT-EU we run Morio's canary release in production, so we've had access to this feature for a while now).
As a new flanking service in Morio, we have ensured proper integration by writing our own storage adapter to store Node-RED data in Morio's database. We've also added custom nodes to facilitate working with Morio data, such as nodes to read and write to Kafka topics in Morio, get or set data in the Morio KV store, or get a JSON Web Token signed by Morio to benefit from existing Morio integrations such as with Hashicorp Vault / OpenBao.
Morio is now an OIDC Provider
Morio can now act as an OIDC provider. This unlocks Sign in with Morio functionality in your own applications or websites. We use this to allow users to submit incoming webhooks to Morio via self-service forms, which triggers automation flows in the EdA service.
OIDC clients are handled just as API keys, which means that any user can create a client. Note that we only support the Authorization Code Flow with mandatory PKCE in line with Oauth 2.1.
Morio can now be deployed as a subordinate CA
We've added support for setting up Morio as a subordinate Certificate Authority (CA).
Morio comes with an on-board CA which is needs to generate certificates for clients and services. If you already have an internal CA that is trusted by your clients, you can setup Morio as a subordinate CA. This way, you can benefit from the established trust for your internal CA when your clients access Morio.
Cross-Cluster Database and Cache Access
Initially, Morio services would access the database and cache services over the internal Docker network. Which works fine, assuming that the service is running locally.
However, flanking nodes do not run the database service, and the cache service only runs on a single node. This release brings cross-cluster access to both the database and cache service. It is fully transparent, reaching out to database or cache will now just work no matter what cluster node you are on.
And a bunch of other improvements
Full proxy support
Morio can now be deployed in an environment where internet access is only possible
through a proxy server.
To further facilitate such environments, Morio now uses the .internal TLD for all
cross-container connections, thus making it easy to include a proxy exception for them.
Endpoints for managing inventory assets
We have added API endpoints for managing inventory assets, as well as UI integration for these.
Support for remapping OIDC label names
We already supported mapping
OIDC attributes to labels, but we've added support for renaming attributes
rather than using them as-is.
Inventory groups and vars in Ansible inventory
The exported Ansible inventory will now create groups for all inventory groups,
and also add all group vars to them.
Support for configuring CORS headers
We've added support for configuring CORS headers for both the API and EdA service.
Support for setting environment variables on spawned containers
This was required for proxy support everywhere, but can also be used to set
custom configuration variables.
Selective deployment of flanking services
You can now configure on which node(s) you want each flanking service to run.
Guarding against memory leaks in API & Core services
Both the API and Core service now run in the PM2 process manager and will
automatically restart when memory use exceeds 250MB.
Upgraded various components
- Upgraded Redpanda from v24.2.20 to v24.2.21
- Upgraded StepCA from 0.28.2 to 0.28.3
- Upgraded Vector from 0.45.0-debian to 0.46.1-debian
- Upgraded Redpanda Console from v2.8.3 to v2.8.5
- Upgraded Rqlite from 8.36.12 to 8.36.16
- Upgraded Docusaurus from 3.7.0 to 3.8.0
- Upgraded Traefik from v3.3.4 to v3.3.5
- Upgraded Elastic Heartbeat from 8.16.5 to 8.17.4
Caveats
You may have noticed that our release cadence has slowed down since the start of this year. This is due to legislative changes that impact the priorities of CERT-EU, as well as organizational changes that have resulted in resources taken away from Morio to shore up other endeavors.
Nevertheless, we remain committed to our long-term vision, and keep moving forward. As a pragmatic choice under these circumstances, we have opted to 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.
