The newly released Mender Server 4.0 changes the Helm chart. These changes are meant to streamline the way services are handled, improve security, and fix issues with sub-chart compatibility. We’ve made some important architectural shifts that may impact how you use the chart and configure your deployments. Let's dive into these updates and what they mean for you as a Helm chart user.
From multiple repos to a monorepo
Prior to the Mender Server 4.0, there was a separate Git repository for each service. Moving to a monorepo simplifies the development and deployment pipeline, allowing us to manage all services in one place. A direct consequence of this architectural choice is the different usage of the Container Registry; the Enterprise images are now published to registry.mender.io/mender-server-enterprise/ instead of registry.mender.io/mendersoftware/. For example:
- registry.mender.io/mendersoftware/deployments-enterprise:mender-3.7 -> registry.mender.io/mender-server-enterprise/deployments:v4.0
- registry.mender.io/mendersoftware/deviceauth-enterprise:mender-3.7 -> registry.mender.io/mender-server-enterprise/deviceauth:v4.0
How does this affect you?
When pulling Docker images, the tags are now much simpler. Previously, the image tags had prefixes like mender-3.7.0, but with the monorepo, those prefixes are dropped. Now, the tag is just the version, like v4.0.0. Simpler tag prefixes help reduce confusion and make it clear which version of the overall system you’re running.
When configuring Helm values, make sure to adapt Docker image configurations accordingly to account for the new prefixes.
To update to Mender Server 4.0, follow the New repositories location and the Drop the "mender-" prefix in the tags names sections in the documentation.
Global keys: A sneaky problem with sub-charts
Defining shared configurations is a useful option within Helm charts, however, the introduction of sub-charts can create problems.
If you set global.image, that value gets applied to all sub-charts, too. This causes conflicts, especially when using other charts like NATS that might also have a global.image key. Moving away from global.image to default.image can fix this problem with sub-charts
For more information follow the Global section deprecations section in the documentation
Security first: Moving away from cleartext passwords
Storing passwords directly in the values.yaml file is a bad practice, as plain text isn’t always secure . Previously, you might have used global.image.username and global.image.password to provide authentication for pulling images which store passwords in plain text.
We’re switching to default.imagePullSecrets, which allows you to configure Kubernetes secrets for authentication, keeping your passwords secure and away from prying eyes.
Your new approach:
Instead of using cleartext passwords, configure your imagePullSecrets and reference those in your values.yaml. Leveraging secrets ensures that your sensitive data is handled securely without sacrificing functionality. Configuring imagePullSecrets is valid only for Enterprise users with active credentials to the Mender Enterprise Registry.
The ImagePullSecrets instead cleartext credentials section in the documentation provides more information
Rootless containers: Security on the GUI frontend
To enhance security, we’ve rebuilt the GUI container to run as a rootless container. As a result, the web application has switched from running on the privileged 80 port to the unprivileged 8090 port.
Why does this matter?
The rebuilt rootless GUI container ensures enhanced security and follows best practices by not running with root privileges. If your deployment relied on port 80, you’ll need to update your configurations to expose port 8090 instead.
Please make sure to follow the Rootless gui container section in the documentation.
Service keys: Automatically generated for your convenience
Finally, we’ve added a nice quality of life (QoL) improvement regarding service key generation. Following this change, if you don’t specify a Deviceauth and Useradm keys in the values.yaml, the Helm chart will automatically generate one for you.
What does this mean for you?
You no longer need to worry about providing a service key every time you access the Helm chart. The Helm chart will automatically handle it for you. Of course, if you want to use your own key, you can still specify it as usual, this change simply reduces manual configuration and helps prevent errors from missing or misconfigured keys
Storage proxy: One domain to rule them all!
Without the storage proxy feature, you’ll end up with two different endpoints. For example, the Mender Server and the Artifacts storage have
https://mender.example.com and https://my-mender-artifacts.s3.amazonaws.com as endpoints.
With the storage proxy enabled, your endpoints will be https://mender.example.com and https://mender.example.com/my-mender-artifacts for the Mender Server and the Artifacts storage, respectively. This storage proxy change is a QoL enhancement so it is enabled by default.
What does this mean for you?
Just specify your domain and your artifacts storage name, and the Mender Server v4.0 will work as a storage proxy for you.
Follow the Storage Proxy enabled by default section in the documentation.
Subcharts enabled by default for convenience
For open source plans, NATS and MongoDB services are now enabled by default in the Mender Helm chart as a subchart in Mender Server 4.0. For Enterprise plans, Redis is also included and enabled, and the open source setup is disabled by default.
The default setup is open source. Please follow the NATS and MongoDB subcharts enabled by default, the Redis subchart disabled by default, and the Enterprise false by default sections in the documentation.
Get started with the updated Helm charts
The updates to Mender Helm charts aim to provide a better experience using Mender. By switching to a monorepo, fixing issues with the global key, enhancing security through secrets and rootless containers, and introducing auto-generated service keys, the Mender Helm chart feature is future-proof, secure, and user friendly.
For complete upgrade documentation, visit the official documentation page.
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!
Recent articles
What’s new in Mender: Introducing Service Provider tenant and new advanced features
The European Union Cyber Resilience Act (CRA): Why remediation requires over-the-air (OTA) updates
CVE-2024-55959 - Insecure permissions on private key file generated by the Mender Client
Learn why leading companies choose Mender
Discover how Mender empowers both you and your customers with secure and reliable over-the-air updates for IoT devices. Focus on your product, and benefit from specialized OTA expertise and best practices.
