## Least Privilege Developer Access for Kubernetes Clusters In our [recent release in July](https://docs.rafay.co/releasenotes/2023/july/), we enhanced our [**zero trust kubectl**](https://docs.rafay.co/accessproxy/overview/) service to address the needs to **two completely different cohorts** of customers. At a high level, users of the Rafay Platform fall into two ends of the **access spectrum** when it comes to answering the following question. > Should developers be allowed to view **[Kubernetes Secrets](https://kubernetes.io/docs/concepts/configuration/secret/)?**. Should they be allowed to **exec into running containers/pods** for troubleshooting purposes? ## In-Place Upgrades to Amazon EKS v1.26 using Rafay In our [recent release in July](https://docs.rafay.co/releasenotes/2023/july/), we added support for in-place upgrades of existing [EKS clusters](https://docs.rafay.co/clusters/eks/overview/) to Kubernetes v1.26. Customers tell us that they wish to be extremely careful with **in-place upgrades** of their **existing** EKS clusters because there is no benefit in rushing this and impacting mission critical applications etc. Provisioning of **new** EKS v1.26 clusters using Rafay has been [supported](https://docs.rafay.co/blog/2023/06/08/amazon-eks-v126-clusters-using-rafay/) for a while now. Note Organizations that wish to perform sophisticated checks for API deprecation etc are strongly recommended to use Rafay's **Fleet Operations** for Amazon EKS. ## Declarative Cluster Lifecycle Management Every Kubernetes user is familiar with the **[kubectl apply](https://kubernetes.io/docs/reference/kubectl/)** command. This is used to **create** or **modify** Kubernetes resources as defined in a manifest file. This pattern is referred to as **Declarative** usage where the state of the resource is "declared" in the manifest file and the command is used to implement the declared state. Unlike an imperative approach where the user needs to specify both **what** and **how** to perform a task, with the declarative approach, the user just needs to specify **what to do** and not worry about **how to do it**. The **apply** approach is preferred and recommended because it is well suited for version control. The **kubectl apply** command works extremely well for resources inside the Kubernetes cluster. > What if there was a way to bring this declarative approach for **cluster lifecycle management** as well? ## Auto Inject Project Name in Cluster Labels In our [July 2023](https://docs.rafay.co/releasenotes/2023/june/) release, we added support automatic injection of **project name** as a **cluster label**. In Kubernetes, labels are key/value pairs that are attached to objects such as Pods, nodes etc. Support for labels in Kubernetes ends at a node level. We extended the "label" construct to **clusters** over two years back as **cluster labels**. Cluster labels are critical for **multi cluster workflows** and have been the backbone of several unique and differentiated features in the Rafay Kubernetes Operations Platform. In this release, we have automated the **injection** of the "name of the project" as a cluster label to all clusters in the project. Read on to understand some of the use cases that are enabled by this feature. Note In a separate blog, we will describe how **cluster labels** powers various multi cluster workflows and operations. ## Display Workload's Details for Enhanced Developer Experience Many of our customers are **platform teams** that are focused on providing their end users (application developers) a great **developer experience** especially with ease of use with deploying and managing their applications on remote clusters. In our [July 2023](https://docs.rafay.co/releasenotes/2023/june/) release, we have enhanced the existing developer experience further by providing developers with a facility to **quickly verify** details about the workload under management. Important This enhancement was requested by multiple enterprise customers. ## Integrated FinOps Role for Cost Management In our [June 2023](https://docs.rafay.co/releasenotes/2023/june/) release, we added support for a new turnkey [role](https://docs.rafay.co/security/rbac/roles/) in the Rafay Kubernetes Operations Platform specifically targeted at users in a [FinOps](https://www.finops.org/) function. This new role allows the FinOps team to **access and view** cost and usage data in the Rafay Kubernetes Operations Platform. Users with this role do not have the ability to impact infrastructure or applications. ## Kubernetes v1.27 for Rafay MKS Our [recent release update in June](https://docs.rafay.co/releasenotes/2023/june/) adds support for a number of new features and enhancements. This blog is focused on support for [Kubernetes v1.27](https://kubernetes.io/blog/2023/04/11/kubernetes-v1-27-release/) with [Rafay MKS](https://docs.rafay.co/clusters/upstream/baremetal_vm/overview/) (i.e. upstream Kubernetes for bare metal and VM based environments). Both new cluster provisioning and in-place upgrades of existing clusters are supported. As with most Kubernetes releases, this version also deprecates and removes a number of features. To ensure there is zero impact to our customers, we have made sure that **every feature** in the Rafay Kubernetes Operations Platform has been validated on this Kubernetes version. ## Upstream Kubernetes on Rocky Linux 9 OS In our [June 2023](https://docs.rafay.co/releasenotes/2023/june/) monthly release, we added support for lifecycle management of Rafay managed [upstream Kubernetes](https://docs.rafay.co/clusters/upstream/baremetal_vm/overview/) clusters on nodes based on [Rocky Linux](https://rockylinux.org/). Rafay has supported CentOS as an operating system for upstream Kubernetes clusters. With the [EOL of CentOS](https://endoflife.date/centos), several customers asked us to support Rocky Linux as an **alternative**. ## Rafay's AI Hackathon 2023: Advancements To Improve Our Customer Experience We just wrapped up our annual hackathon earlier this month. The theme and focus for this hackathon was **AI and Generative AI** and our teams had the opportunity to prototype and demonstrate fascinating solutions esp. based on Generative AI. We had **eleven (11)** fully functioning submissions spanning both "external" and "internal" use cases. The panel that reviewed and judged the submissions observed extensive use of the following technologies associated with Generative AI. ## Org-wide Dashboards for OPA Gatekeeper In our [recent release in May](https://docs.rafay.co/releasenotes/2023/may/), we enhanced our turnkey integration with [OPA Gatekeeper](https://open-policy-agent.github.io/gatekeeper/website/). In this blog, I describe why we worked on this enhancement. Many of our customers that operate mission critical applications on Kubernetes clusters have to comply with **organizational policies and best practices**. These customers depend on and use Rafay's turnkey integration with **OPA Gatekeeper** in the Rafay Kubernetes Operations platform. Prior to this release, our customers would use Rafay to - Centrally **orchestrate and enforce** OPA Gatekeeper policies, and - Centrally **aggregate** OPA Gatekeeper violations in the audit logging system They would then use Rafay's [audit log aggregator](https://docs.rafay.co/integrations/siem/overview/) to **push** the OPA violations in **real time** to their corporate SIEM such as Splunk etc. Since most "Infrastructure and Operations" personnel and "App Developers" are not provided access to the corporate SIEM, they have been asking Rafay to develop **dashboards** that will help them answer some **critical questions** related to compliance with policies. > What is my current posture (i.e. summary) and how has my posture evolved over time? (i.e. trend)?