Rancher, the open source container management platform, uses Fleet to enable its continuous deployment features. Fleet brings GitOps functionality to Rancher. Fleet in Rancher 2.7.0 can fetch Helm charts from OCI registries. Using OCI registries to store Helm charts is an increasingly popular storage method. It allows storing your charts in a registry alongside your container images. This unifies the storage options for charts and reduces friction. Using a chart in an OCI registry is fairly simple.

We are excited to announce that deploying Kubewarden in air gap environments has been simplified and documented! For that, you will need a private OCI registry accessible by your Kubernetes cluster. If you’re unfamiliar with Kubewarden, it’s a policy engine for Kubernetes. Its mission is to simplify the adoption of policy-as-code. Kubewarden policies are WebAssembly modules; therefore they can be stored inside an OCI-compliant registry as OCI artifacts.

The Rancher Team are excited to announce the general availability of Rancher v2.7. Rancher v2.7 is a monumental milestone in the lifecycle of Rancher and introduces the ability to be a truly interoperable, extensible platform through the concept of extensions. The extensions now make it possible for users to build extensions on top of Rancher with complete autonomy.

s3gw is an S3-compatible service, focused on deployments in a Kubernetes environment backed by any PVC, including Longhorn (https://longhorn.io). Since its inception, the primary focus has been on Cloud Native deployments, however, the s3gw can be deployed in a myriad of scenarios, provided there is some form of storage attached.

It’s a fact of life: as the Kubernetes API evolves, it’s periodically reorganized or upgraded. This means some Kubernetes resources can be deprecated and later removed. We deserve to keep track of those deprecations and removals easily. For that, we have just released the new deprecated-api-versions policy for Kubewarden, our efficient Kubernetes policy engine that runs policies compiled to Wasm.

Securing a Kubernetes cluster is far from a simple task. How do you know if you have correctly configured volumeMounts in your in-cluster containers? And what about all those workload resources, such as Deployments, Jobs, Pods, etc? Luckily, you can use Kubewarden, an efficient Kubernetes policy engine that runs policies compiled to Wasm. This means you can run powerful specifically-written policies, our reuse existing Rego policies for example.

The Kubewarden development team is happy to announce the release of the Kubewarden 1.3 stack. In addition to the usual amount of small fixes, this release focused on the following themes. If you’re not familiar with Kubewarden, it is a policy engine for Kubernetes. Its mission is to simplify the adoption of policy-as-code.

The Harvester team is pleased to announce the next release of our open source hyperconverged infrastructure product. For those unfamiliar with how Harvester works, I invite you to check out this blog from our 1.0 launch that explains it further. This next version of Harvester adds several new and important features to help our users get more value out of Harvester. It reflects the efforts of many people, both at SUSE and in the open source community, who have contributed to the product thus far.

We are proud to introduce SUSE Edge 2.0, which will empower customers to accelerate and scale edge infrastructures and transform edge operations.

We are thrilled to announce you can now scan your environment variables for secrets with the new env-variable-secrets-scanner-policy in Kubewarden! This policy rejects a Pod or workload resources such as Deployments, ReplicaSets, DaemonSets , ReplicationControllers, Jobs, CronJobs etc. if a secret is found in the environment variable within a container, init container or ephemeral container. Secrets that are leaked in plain text or base64 encoded variables are detected.