What’s new in Mender: Introducing Service Provider tenant and new advanced features

Release highlights

• Simplify managing and securing complex environments with Service Provider tenant
• Publish up-to-date information from Mender leveraging new inventory webhooks
• Streamline user management through Single Sign-On improvements

Important note: Mender no longer has an overall bundle version and will instead use component versioning going forward. For more information, check out Mender versioning: New releases by component

Service Provider tenant

Multi-tenancy has been part of Mender for several years, available in the Enterprise version. With multi-tenancy, a single Mender Server instance can be separated into isolated tenants. The multi-tenancy functionality has been available for operations teams through a command-line interface (CLI) at the server infrastructure. 

Mender Server 4.0 introduces the new Service Provider tenant feature, drastically expanding the functionality and benefits of multi-tenancy with a streamlined tenancy structure and easy management interface. Leveraging a Service Provider tenant simplifies management while enhancing security for complex environments, such as:

• Isolating customers or clients: Security, regulatory, or risk management, isolating customers or clients helps to ensure security, limiting the possibility that one customer will affect another in any way. The Service Provider tenant is a simple way to securely manage multiple tenants, a requirement with scale and growing customers. In this scenario, a Service Provider tenant admin can give unique access to a separate, isolated Mender tenant to each customer. Or, manage your customers’ Mender tenants on their behalf, depending on skillset, control, and service requirements.
  
  
• Isolating development environments: To ensure security and manage risk, distinct, isolated environments are often required throughout the product development process. For example, development, staging, and production may require isolated tenants to avoid any changes from impacting other tenants. Tenants for different regions can also help manage regional regulatory or security requirements. In either scenario, each environment can have its own set of devices and updates, ensuring any actions remain in that environment alone. With a Service Provider tenant setup, it is impossible for test data to interfere with production systems, for example.
  
  
• Isolating business divisions or product lines: Large enterprises typically comprise multiple business units, vertical divisions, and product lines. With a Service Provider tenant, large enterprises can now isolate Mender per business unit, division, or product line, ensuring each does not interfere with the other while retaining central visibility and control over the tenants and their usage.
  
  

The new Service Provider tenant feature in Mender enables a two-level tree structure. Each Service Provider tenant can create and manage one set of child tenants. 

When creating a new child tenant, the Service Provider tenant can:

• Set the device limit. The Service Provider tenant admin will determine the maximum amount of devices the new child tenant can accept. The child tenant's device limit is allocated from the Service Provider tenant’s device limit. For example, in the diagram above, the Service Provider tenant has allocated all of its devices, one hundred in total, to the child tenants it is managing.
  
  
• Assign the initial Admin user. The Service Provider tenant admin can create a new user or assign an existing user to be the first user and Admin of the new child tenant. A single user can exist in multiple tenants; in the event the Service Provider tenant wants to manage the child tenant(s) directly, one would simply add the same user as the initial admin and first user. Importantly, to support distinctly isolated environments, the Service Provider tenant admin cannot log into a child tenant unless explicitly added as a user inside that child tenant.

When using the Service Provider tenancy feature, a user can access multiple tenants and seamlessly switch between them without logging in again.

To learn more and see how to get started, check out the multi-tenancy overview documentation.

For users with multiple existing tenants wanting to unify their management, it is possible to link existing tenants together in a Service Provider tenant structure. For hosted Mender environments, the Mender team offers a service to migrate existing tenants to a Service Provider tenant structure. On-premise Mender environments can learn more about migrating their existing tenants in the multi-tenancy documentation.

Availability: The Service Provider tenant feature is available in the Enterprise version of Mender for both hosted and on-premise deployments. The Service Provider tenant and all child tenants will be on the same version (Enterprise), including any subscribed Mender add-ons.

Introducing inventory webhooks

Building an application-specific portal, dashboard, or even an IoT platform customized to specific use cases and product lines is quite common. For example, a smart energy product may want to show energy consumption, charge levels, and other product metrics. While custom portals, dashboards, or platforms fall outside the scope of Mender, Mender does contain important information about devices and products in the field – data that is desirable and can be used to enrich these use cases.

For instance, it can be interesting to measure product performance following a new software version deployment compared to application-specific metrics. The Mender Server already contains data on software versions, network addresses, sometimes geolocation, and other device inventory information. Today, it is possible to use the Mender API, pulling data often and transferring any changes to Mender data into a separate portal or dashboard. However, leveraging the Mender API is not the most scalable nor a best practice to accomplish a Mender data transfer.

The best way to transfer data from Mender is to use webhooks inside Mender. Mender already supports the device authentication state webhook for such use, allowing external portals and device management systems, like Azure IoT Hub, AWS IoT Core, or custom systems, to stay synced with Mender. If a device changes its authentication state in Mender (such as when it is decommissioned), then Mender can trigger a webhook that also updates the external system.

Mender Server 4.0 introduces a new type of webhook: device inventory. Once configured, the device inventory webhook will call the configured endpoint upon a change in inventory information, such as a new software version. Portals can thereby easily subscribe to events when they occur instead of pulling for this information at pre-configured intervals.

Learn more about the device inventory webhooks in the Webhooks documentation.

Availability: The new inventory webhook is available in the Professional and Enterprise plans. The device authentication webhook is and will continue to be available in all plans as well as open source.

Single Sign-On (SSO) enhancements

Integrating Mender with SSO simplifies user management, managing all users centrally in a directory and not inside Mender (and any other application) separately. Today, Mender supports SSO via SAML, a well-established protocol for SSO.

Mender Server 4.0 adds support for using Personal Access Tokens (PATs) for SSO users. Mender already supported Personal Access Tokens (PATs) for user or password-based authentication and granting machine-access to Mender, such as to a CI/CD system for uploading Artifacts. Now, Mender can also issue PATs when using SSO.

In addition to PATs for SSO, Mender Server 4.0 also introduces support for a newer SSO protocol, OpenID Connect Federated authentication. Together, these improvements ensure Mender works more seamlessly in SSO environments, saving time and effort while improving user security.

Role-based access control (RBAC) support for Releases (Artifacts)

The Enterprise plan of Mender currently supports role-based access control (RBAC) to improve security and lower the risk of user-based incidents. With RBAC, access to groups of devices, how device access is granted, access to Releases, and access to the Audit Log can be limited and controlled on a per-user basis.

Mender Server 4.0 introduces limiting access to Releases based on tags. For example, user access can be different for “development” versus “production” tagged devices, which is very useful for ensuring that development releases are not accidentally rolled out to production devices. In this scenario, simply tag production releases with, for example, “production,” and create a new Role that can only read releases with the “production” tag, as shown below.

Users assigned to this role can only see and deploy Releases that have the “production” tag. The rest of the devices are filtered out and inaccessible. Mender Server 4.0 greatly improves the control and flexibility of RBAC.

Availability: Role-based access control (RBAC) is available in all Enterprise plans.

Mender Gateway implements mutual TLS (mTLS) for devices

Historically, the Mender Server had a separate component (microservice) used to enable mutual TLS (mTLS) via device-side certificates: mTLS Ambassador. The mTLS Ambassador is now deprecated and replaced with the Mender Gateway.

The Mender Gateway 2.0 now serves multiple purposes: caching Artifacts locally, enabling local network access to devices, and enabling mTLS for devices.

For mTLS for devices, Mender Gateway 2.0 can also run in the cloud and grant access to other new features in Mender Gateway.

For Mender customers using mTLS in a hosted deployment, the Mender team has already seamlessly migrated the functionality to Mender Gateway. For customers using mTLS in an on-premise environment, please follow the migration guide from mTLS Ambassador to Mender Gateway.

Availability: mTLS for devices via the Mender Gateway is available in Enterprise plans.

Additional enhancements

Software and Artifact visibility: When looking at a device in the Mender, you can now always see which software and Artifacts it has installed. Mender Server 4.0 also enables reverse visibility of this data, making it possible to see how many and which devices have a given Artifact installed. Viewing deployment data from the Artifact side can be useful to quickly determine which Artifacts are deployed out in the field and to what extent.

Note: Device filtering and dashboard widgets can also monitor specific Artifact distributions.

Network usage tracking: In situations where Mender is used on metered, slow, or expensive networks like cellular and satellite, keeping track of network usage is important from both operational and financial perspectives. For over-the-air (OTA) updates, the most intense use of the network is the Artifact download size. In such cases, delta updates in Mender are preferred to manage network usage. However, since delta updates are seamlessly server-generated in Mender, it could be difficult to understand how much network bandwidth was used. Thus, Mender Server 4.0 introduces a new feature to show how much data is downloaded per device for a given Deployment. Below is an example network usage deployment report.

The overall data usage for the deployment is shown here, and you can see it per device by clicking View details for a given deployment.

Powerful API filtering: For users managing deployments in Mender via its API (e.g., through a custom portal), Mender Server 4.0 releases more powerful filtering capabilities by adding the deployments/v2/deployments endpoint. Now, a single call can filter multiple times for the attributes, such as a single GET request like v2/deployments/deployments?name=berlin&name=paris. For more information, check out the Mender Server API documentation.

Note: The corresponding API v1 endpoint will be deprecated. Everyone using the API v1 endpoint should migrate to the v2 endpoint as soon as possible.

For the full list of Mender enhancements, check out the changelogs for Mender Server, Mender Client, and Mender Gateway.

Try the new features

The hosted deployment of Mender is already updated with all the new features. If you’re an existing customer, check out the new features and functionality in your account today!

If you are new to Mender, we recommend following the Get started documentation and signing up for a Free Trial account. No credit card is required and you get 10 devices for free for 12 months.

Upgrading

Mender follows semantic versioning, and the three components, Mender Server, Mender Client, and Mender Gateway, are all new major version releases.

To upgrade, the required changes are still relatively minor and should not lead to any issues during the upgrade or use.

For the Mender Server, the main change is in the Kubernetes Helm chart, which was simplified in Mender Server 4.0. Some prefixes in the tag names were removed, and some manual editing is required when upgrading. Learn more in the Server upgrade documentation.

In the Mender Client 5.0, the only potential incompatible change is that some Update Modules (deb, docker, rpm, and script) have been removed from the default, supported installation. Learn more in the Client upgrade documentation.

Please take extra care when upgrading and follow the upgrade documentation.

Share your feedback

We appreciate your general feedback on Mender, be it positive or needing improvement, in the Mender Hub General Discussions forum. Your continued feedback ensures Mender will meet your needs even better in the future!

If you believe you have encountered a bug, please submit your report in the Mender JIRA issue tracker.

We hope you enjoy the new features and look forward to hearing from you!