Replicated Product Updates

September is a month of change, as summer leaves us and cooler weather for many helps usher in the early part of fall. Still, our classic Replicated fervor is still in full swing, and we’re back again with a fresh batch of exciting new developments and release highlights.

Something else you might notice is ‘new’ — that we are making a shift to talking about our product features more descriptively around the capabilities that they deliver. This is an important change to help clarify our product, Replicated. You’ll still see the original names (KOTS, kURL) when you’re looking at the features in their open-source forms, but when they are in the context of the larger product, you’ll see these features referenced descriptively. So, we’ll be moving forward here by talking about our application manager (previously “KOTS” (Kubernetes Off-The-Shelf), our Kubernetes installer (previously “kURL”), and the vendor portal (previously “Vendor Web”). These changes will begin to appear in other places as well, including Customer Support, Customer Success, and our documentation. 

And just as always, check out the recently shipped features and release highlights for September 2021 below.

What’s New for the vendor portal (previously “Vendor Web”):
What’s New for the application manager (previously “KOTS”):
What’s New for the Kubernetes installer (previously “kURL”): 

Vendor portal: API Tokens Now Better Aligned to RBAC Policies

Another new type of vendor portal API token, Service Account, was added to the vendor portal. A vendor may choose to use service account tokens for a variety of activities that are important to their team, for example, if they wanted to automate their CI/CD process with Replicated, and not have that authentication be tied to a particular individual user.

By having a service account token, any permissions and auditing are tied to the token itself vs an individual. Check out how they work here: 

service account

Historically, teams only had Team tokens to use, which could be created, retrieved, or revoked by anyone in the team. Making Service Account tokens available was particularly important to many of our vendors who wanted to automate a lot of their application management work, but found the security controls around Team Tokens to be lacking. 

This token, along with the previously added user tokens from last month, marks a significant milestone in our team’s plan to improve vendor portal security posture. Service Account tokens allow for non-user-based, admin-controlled, RBAC scoped tokens to be generated. This gives vendors much more granular privilege control to any scripts or software leveraging the Vendor CLI or REST API. 

In lieu of this, the ability to create new team tokens has been disabled. Access and usage of any existing team tokens are not impacted. Our team is recommending that these newer, more secure tokens are used to replace them. If vendors do replace team tokens with service account or user tokens, we also recommend revoking that team token. To help make this process easier, all vendor portal tokens now have a new ‘last active’ date and time stamp so it is easier to know these details when evaluating your team’s next steps for token-based access to the vendor portal.

Application manager: Checks Status of All Individual Status Informers in Admin Console

In version 1.51.0 of application manager, the ‘Application’ tab in the admin console interface now provides a more robust set of details to help explain the application’s status. By clicking on the ‘Details’ link, information for each resource’s corresponding status informer is displayed. By configuring different status informers, vendors can give extended visibility into the different resources for the applications in Kubernetes. When a status informer is configured, the enterprise user can use this view to see the status of the resources — and can better see which resources are impacting the overall status of the application. 

This gives that user more data that they can use for self-service troubleshooting or even open up a ticket with the vendor without running any kubectl commands or reviewing any logs. Vendors could provide details in their knowledge base, for example, about scenarios and conditions that could impact a resource’s status so any sort of initial triage steps can be self-serviced independently. 

Our team recommends that vendors configure a status informer to help make their applications enterprise ready. Here is an example of what this new view looks like:

Kubernetes installer: Signed Software Bill of Materials with Each kURL Release 

A software bill of materials (SBOM) is a list of components that are in a piece of software. When you go to install software, an SBOM can help you understand what exactly it is you’re installing. Software users can leverage an SBOM to, for example, ensure that all parts of a software package are consistent with their licensing policy, or determine if the software is vulnerable to any CVEs.

The kURL project now provides a signed software bill of materials in each release. By providing SBOMs for our software, we help enterprises gain confidence in the software they are installing. Keep your eyes peeled for updates on SBOMs for the KOTS and Troubleshoot projects, too. Go to the kURL releases page to see these artifacts in action, and let us know what you think and how we can make this even more useful for you.

changelog

That’s it for the September 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.