Skip to content

Upcoming

Important

This page will be periodically updated with features that are scheduled to roll into Rafay's Preview environment as part of upcoming releases. Learn more about Previews. Learn about our recent releases.

Navigate to our public roadmap for details on what we are working on for future releases.

v2.11-SaaS

Expected rollout dates: October 23, 2024 for Preview Orgs and November 5, 2024 for Production Orgs

Amazon EKS

Pod Identity

The EKS Pod Identity feature simplifies granting AWS IAM permissions to Kubernetes applications running in an Amazon EKS cluster. Support for this feature for clusters managed through the Rafay platform is being added with this enhancement. Support is being added for:

  • Installation of the Amazon EKS Pod Identity Agent Add-on: This agent runs as a DaemonSet on the cluster. This can be installed both on Day 0 for new clusters and Day 2 for existing clusters
  • Creation of Pod Identity Associations: This allows specific Kubernetes service accounts to be associated with IAM roles.
  • Migrating existing IRSA to pod identity associations: This allows migrating existing IAM Roles for service accounts to Pod Identity associations.

Info

To learn more about how to use EKS Pod Identity and its associations with Rafay, please read the following blogs: Introducing EKS Pod Identity and EKS Pod Identity with Rafay.

This feature will be supported through all interfaces including UI, RCTL, Terraform, System Sync and Swagger APIs.

Add-on Deployment in Day 0

PIA Day 0

Add-on Deployment in Day 2

PIA Day 2

Pod Identity Associations

PIA

Migration

Migration

Note

  • Pod identity associations for EKS managed addons is not available in this release and will be included in a subsequent release

  • Permissions Required: To utilize this feature, the following IAM permissions are necessary for the role or user part of cloud credentials:

    "eks:CreatePodIdentityAssociation",
"eks:DescribePodIdentityAssociation",
"eks:DeletePodIdentityAssociation",
"eks:UpdatePodIdentityAssociation"

Info

Click here to learn more about Rafay's support for EKS Pod Identity.

Upstream Kubernetes for Bare Metal and VMs

The features in this section are for Rafay's Kubernetes Distribution (aka Rafay MKS).

Ubuntu 24.04 LTS

Support is being added for the Ubuntu 24.04 LTS operating system. This allows users to leverage Ubuntu 24.04-based nodes for their Rafay MKS clusters.

ubuntu24

Cordon/Uncordon/Drain Node Actions

New node actions have been introduced including Cordon, Uncordon, and Drain. These actions enable users to more efficiently manage nodes. These actions will be supported through UI, RCTL, and Swagger API interfaces. For governance and compliance purposes, for each of these actions, an immutable audit log entry will be added to the centralized audit logging system.

Node Actions

Info

For information on CLI commands, please refer here.

Terraform/OpenTofu Provider

In addition to using the existing interfaces (UI, API, CLI and GitOps SystemSync), users can now also use Terraform or OpenTofu to manage the lifecycle (i.e. configure, provision, upgrade, scale, delete) of Rafay MKS based upstream Kubernetes clusters. Users can leverage this functionality with the latest version of Rafay's Terraform Provider compatible with this release.

Environment Manager

Schedules

There are actions that may be need to be executed against environments one time or on a recurring basis. Examples of these include:

  • Configuring a Time to Live (TTL) policy to shut down environments after a specified time period
  • Configuring a Schedule Policy to shut down environments when not in use (evenings/weekends)
  • Periodically capture a snapshot of K8s resources or run CIS/NSA benchmark checks on a cluster for compliance purposes

Supported actions include

  • Deploy
  • Destroy (to shut down the environment)
  • Custom Workflows (this can be a series of tasks that can be a container, a set of HTTP calls or functions written in Go or Python)

It is also possible for Platform team to configure opt-out policies for Schedules. This includes:

  • Maximum number of times that an end user can opt-out of a configured schedule policy
  • Maximum duration that the user can opt-out for (e.g. if an end user is opting out of a TTL policy, the Platform team can configure the maximum duration that user can specify when opting out)
  • Attaching an approval workflow for opt-out (e.g. integration with a system like ServiceNow or JIRA for raising/recording approvals)

This feature will be supported through all interfaces including UI, RCTL CLI, Terraform, System Sync and APIs. Schedule policies can be defined as part of the environment template configuration.

Drivers/Workflow Handlers

It is possible today to execute custom workflows by packaging them as a container and/or through a set of HTTP calls. Support is being added to Drivers/Workflow Handlers to execute code written in Go or Python with this enhancement.

Drivers/Workflow Handlers can be leveraged at multiple places including as part of:

  • Resource templates through the Custom Provider option
  • Hooks attached to the resource/environment template configuration (e.g. Approval is need in ServiceNow before an environment provisioning is initiated)
  • Schedule policy (e.g. capture snapshot of K8s resources every 24 hrs)

The ability to execute custom code written in Go or Python will be supported through RCTL CLI, Terraform, System Sync and APIs interfaces initially. Support for UI interface will be added in a subsequent release. For more information on this feature, please refer here.

Template Designer & Visualizer Studio

A Designer Studio for Environment Manager is being added to the platform with this enhancement. The first version of the studio will support visualizing the relationship between different objects that constitute an environment template. This makes it easier for the Platform teams to debug/verify the templates before it is ready to be shared with other teams. Upcoming versions will add the ability to create templates from the scratch using the studio.

GitOps

UI enhancements: Pipelines and Approvals

A number of UI improvements are being implemented for the Pipelines and Approvals pages. These are intended to make it easy to get visibility around recent pipeline runs & pending approvals.

Pipelines page:

  • Ability to search by pipeline name
  • Ability to sort by columns
  • Additional columns, "Created At" and "Last Run"

Pipeline

Approvals page:

  • Ability to search by pipeline name
  • Ability to filter by Status (pending or approved)

Approval

System to Git Sync

In scenarios where the Platform team has standardized on GitOps as the choice of interface for the SRE/end user teams (i.e. all actions are driven through spec files in the Git repo), there are challenges around educating SRE/end user teams on folder structure that needs to be used for various resources (e.g. clusters).

With this enhancement, the required folder structure (empty folders) is automatically created for all resources that have been selected as part of the System Sync pipeline on the first System to Git sync. This makes it extremely easy for Platform teams to onboard new teams (create a project, a system sync pipeline and hand-off to the SRE/end user teams).

Role Based Access

Break Glass Workflows

There are scenarios where users (e.g. developers) may require elevated privileges for a specific period of time, example includes troubleshooting an application running in a production cluster. This new feature allows Platform teams (Org admins) to

  • Temporarily assign users to override groups with elevated privileges
  • Integrate with external systems of record such as ServiceNow or Jira to enable workflows where access can be granted upon approval
  • Centralized audit logs capture the temporary access assignment/delete action and Platform teams (Org Admins) have full visibility into users who have temporary access across the organization
  • Stream the audit logs to the organization's SIEM such as Splunk
  • Export the audit logs as a CSV

Administrators can configure and use this feature through all interfaces supported by the Rafay Platform: UI, RCTL CLI, Terraform, GitOps System Sync and APIs.

Shown below is an example of a break glass configuration

Break Glass Access

Shown below is an example of the audit logs for break glass

Break Glass Access

Info

To learn more about the concepts behind break glass, please read our recent blogs: An Introduction to Break Glass Workflows for Developer Access to Kubernetes Clusters. For more information about this feature, please refer here.

Cost Management

Google Cloud Platform (GCP)

Support is being added to configure Cost Profiles for GCP with this enhancement. This allows customers to leverage the chargeback and cluster/application rightsizing capabilities available today for GKE clusters as well.

GCP

Info

For more information on this feature, please refer here.

Audit Logs

Namespace Operations

Audit logs are being added for namespace creation/delete operations that were handled implicitly by the controller. An example for this is an implicit namespace creation as part of an add-on deployment during the blueprint sync process.

User Experience in Rafay Console

Namespace Admin users

A number of improvements are being implemented to improve the user UX for namespace admin roles. These include filtering objects in the UI based on the access that the role provides and the ability to download kubeconfig for a specific cluster (versus a consolidated kubeconfig).

Page Size Selection

With this enhancement, any changes that the user makes to the 'rows per page' selection will be persisted across pages for that specific browser session.

Bug Fixes

Bug ID Description
RC-30381 Backup/restore jobs are not cleaned up when the cluster is deleted
RC-37499 Upstream k8s: Unable to add worker nodes to existing clusters in certain scenarios
RC-36543 Blueprint sync operation is not successful when updating the blueprint version to remove an undesired add-on
RC-28677 UI: 404 error when pod metrics are unavailable
RC-33389 Modified time is updated and audit log entries are created on a workload publish action even when there are no changes