March was an exciting month for us at Replicated, as we released several new features that are sure to have a significant impact on software vendors and enterprises alike. We introduced the ability to install prior versions of an application, mark releases as required so they can’t be skipped during upgrades, and prevent users from deploying applications if preflights fail. We also improved the security posture of Kubernetes installer-created clusters by making them compliant with CIS benchmarks. Read on to learn all about these and other improvements!
New Release Highlights
What’s New for the vendor portal:
- Vendor portal: Releases can be marked as required, so they cannot be skipped during upgrades
- Vendor portal: Custom license fields are now included in the vendor API and Customers CSV download
What’s New for the application manager
- Application manager: Install a specific prior application version
- Application manager: Prevent application deployment if preflights fail
- Application manager: Automatically deploy new versions, even when semantic versioning is not used
- Application manager: Use minimal RBAC for a subset of customers
What’s New for the Kubernetes installer
- Kubernetes installer: Apply node labels when creating a cluster or adding a new node
- Kubernetes installer: Create CIS-compliant clusters
What’s New for Replicated product documentation
- Documentation: New, modern and centralized Replicated Docs Site
What’s New for the vendor portal
Vendor portal: Releases can be marked as required, so they cannot be skipped during upgrades
Some applications require a specific version upgrade order—typically, applications that need to run data migrations expected in later software versions. For these use cases, vendors have asked for the ability to indicate that a given release cannot be skipped during upgrades.
Now, when promoting a release from the vendor portal or the CLI, vendors can mark a release as required. In app manager v1.68.0 and later, if a user has an earlier version deployed and then tries to upgrade to a version later than the required version, they will be prevented until they first deploy the required version. Releases are never required when performing an initial installation—only during upgrades.
For more information on required releases, see Promoting Releases.
Vendor portal: Custom license fields are now included in the vendor API and Customers CSV download
Replicated vendors often create custom license fields. Previously these custom fields were not available in the vendor API or the CSV download of customer data. With recent changes, these custom fields are now available for retrieval.
There is a new API to get customer entitlements. The Customer CSV download ability now includes an “Entitlements” column that includes a JSON array with the name and value for each custom license field.
The video below shows how vendors can download a CSV containing information, including custom license fields, for all customers.
What’s New for the application manager
Application manager: Install a specific prior application version
The installation commands displayed on the release channel cards in the vendor portal will install the latest version of a vendor’s application. But when vendors troubleshoot a bug in a prior version of their software, or when end users perform disaster recovery and do a fresh installation to recover to their original state, they need to be able to install a prior version of the application.
As of app manager v1.67.0, both existing and embedded installations support installing a specific prior application version using the `app-version-label` flag. By passing the version label to the respective installation commands, the admin console will know to install that version of the application after a license is uploaded.
To install a specific prior version of a vendor application, check out the installation documentation for existing clusters and Kubernetes installer-created clusters.
Application manager: Prevent application deployment if preflights fail
Preflight checks, powered by Replicated’s open source project Troubleshoot, run before the application is installed or upgraded. If there are warnings or failures in these preflight checks, end users can still choose to proceed at their own risk and deploy the application. But sometimes, a vendor knows that a particular preflight is a hard requirement and cannot fail. Otherwise, the application installation will not be successful. For these use cases, strict preflights were introduced in application manager v1.67.0.
Consider the scenario in which a vendor knows that their application cannot work without containerd. The vendor can set the new `strict` parameter to true for the container runtime analyzer. Doing this indicates to the app manager that this preflight is a hard requirement and must not fail for the deployment to proceed.
When a strict preflight is included with an application, the end user will be prevented from skipping preflights since the strict preflight must run to determine whether it fails. Further, once the preflights run, there cannot be any failure outcomes for the analyzers that are marked as strict. Suppose any strict preflight has a failure outcome. In that case, the app manager will prevent the user from deploying the application until the failure is remediated, the preflights are rerun, and all strict preflights haven’t failed. Warnings for strict preflights do not block the deployment, nor do failures for preflights that are not marked as strict.
Strict preflights are a great way to increase application installation and upgrade success by ensuring that the end user does not ignore hard requirements. Vendors with hard requirements for their applications should consider using strict preflights to ensure that their customers meet their requirements before deploying.
Application manager: Automatically deploy new versions, even when semantic versioning is not used
Although the admin console has supported automatically deploying new versions of the vendor’s application since app manager v1.58.0, this feature was previously only supported for applications using semantic versions with version labels. As of app manager v1.67.0, we’ve updated this feature to make it more intuitive and allow any customer to use it, regardless of their vendor’s versioning scheme.
If the channel assigned to the user’s license has semantic versioning enabled, the user will be able to select whether they want to deploy new patch versions automatically; new patch and minor versions or new patch, minor, and major versions. Of course, they can also choose not to deploy any new versions automatically.
If the assigned channel does not have semantic versioning enabled, a checkbox enables the automatic deployment of any new version.
New versions are only automatically deployed if preflights pass. Vendors can check out Replicated’s documentation on automatic updates to learn more and help their customers get set up to deploy the latest releases automatically.
Application manager: Use minimal RBAC for a subset of customers
Replicated’s support for minimal RBAC allows a vendor’s application to be installed into a single Kubernetes namespace rather than requiring cluster-scoped permissions. The `requireMinimalRBACPrivileges` field in the Application custom resource indicates to the app manager that minimal RBAC should be used for all installations.
However, there are specific considerations when using minimal RBAC since things like preflight checks can require cluster-scoped access. Therefore, vendors might want to use minimal RBAC for only their customers who require it.
App manager v1.68.0 adds the `supportsMinimalRBACPrivileges` field, which indicates that the application supports minimal RBAC, but minimal RBAC won’t be used by default. For end users to install the app with minimal RBAC, they must pass the new `--use-minimal-rbac` flag to the `kots install` command.
For vendors who would like to use the more permissive cluster scope when possible but who have customers who require minimal RBAC, this new feature is a great way to roll out minimal RBAC on a per-customer basis.
What’s New for the Kubernetes installer
Kubernetes installer: Apply node labels when creating a cluster or adding a new node
Labels are key/value pairs attached to Kubernetes objects to specify identifying information. For example, certain services in a machine learning application might require a GPU, and node labels can be used to determine which nodes have a GPU, so the correct services are placed there.
Applying node labels previously required users to perform an out of band `kubectl` command on each node. With the new node `labels` flag for the Kubernetes installer, introduced in v2022.03.11-0, vendors can provide their customers with a single command to create node labels when using the Kubernetes installer to create a cluster or when adding a node to a cluster.
Here is an example of adding the `labels` flag to an embedded install command from the vendor portal.
The specified labels are applied to the node after the completed embedded cluster install.
From the cluster management page in the admin console, end users can view all labels applied to nodes in the embedded cluster.
Visualizing these labels can help users service their embedded cluster better or make for a better troubleshooting experience. Vendors who want to use node labels or are already using them can check out the `labels` flag to specify those labels in their install and join commands.
Kubernetes installer: Create CIS-compliant clusters
The Center for Internet Security (CIS) benchmarks provide a global security standard to help safeguard against cyber threats. The CIS Kubernetes benchmarks are best practices specifically designed to harden Kubernetes clusters. The Replicated Kubernetes installer can now be configured to install Kubernetes to comply with these benchmarks.
Some of the changes necessary to meet these benchmarks are now on by default when installing the Kubernetes add-on because these changes do not impact existing installations. When users upgrade their embedded cluster using the Kubernetes installer v2022.03.23-0 or later, they will automatically receive these security updates.
Other settings necessary for full compliance require additional considerations and are therefore introduced only when the opt-in `csiCompliance` setting is true. For further details and considerations when using this flag for new installations or upgrades, see Replicated’s documentation on CIS Compliance.
Replicated recommends that all vendors look at this document and consider how they can best transition their new and existing embedded clusters to CIS benchmarks compliance as a step toward an even more robust security posture.
What’s New for Replicated product documentation
Documentation: New, modern and centralized Replicated Docs Site
Replicated’s documentation didn’t always align with our goal of making the distribution and management of applications easy. Vendors often had to navigate different project sites to find their needed information.
The new Replicated docs site, available at docs.replicated.com, is a complete, stand-alone resource containing all of the information a vendor needs to succeed on the Replicated platform. This site includes content already available to vendors on sites like kots.io. It adds new content areas such as Vendor Team Management, organized to match the product workflow better.
The release notes previously found on kurl.sh and kots.io have been moved to the new docs site, under Release Notes. It is now easy for vendors to find all Replicated product updates in one place.
Replicated continues to improve this new Replicated docs site iteratively. For more information about Replicated’s documentation website strategy and how to provide feedback, see this blog.
That’s it for the March release highlights! Want to learn more about these new features and what Replicated does to help vendors and customers install and manage modern apps on-prem? We would love to show you -- click here to schedule a demo.