A recently disclosed set of vulnerabilities, known as IngressNightmare, has raised alarms for Kubernetes users relying on the Ingress NGINX Controller. These vulnerabilities (CVE-2025-24513, CVE-2025-24514, CVE-2025-1097, CVE-2025-1098, and CVE-2025-1974), with a critical CVSS score of 9.8, could allow attackers to gain unauthorized access to a Kubernetes cluster, potentially leading to remote code execution and full cluster compromise. However, OpenShift 4.x customers are not affected by this exploit, as OpenShift uses the OpenShift Ingress Operator, based on HAProxy, as the default ingress controller.

The vulnerabilities affect the Ingress NGINX Controller, which is responsible for managing external traffic and routing it to internal services in a Kubernetes cluster. Specifically, they target the admission controller, which, if exposed without authentication, allows attackers to inject malicious configurations, resulting in remote code execution. Since OpenShift 4.x uses the OpenShift Ingress Operator (based on HAProxy) as the ingress controller, customers are not exposed to these risks.

OpenShift 4.x further enhances security by restricting permissions and not permitting the default ingress controller to access sensitive data, such as secrets stored across Kubernetes namespaces. This design decision helps protect OpenShift customers from potential exploits by preventing unauthorized access to critical cluster resources.

As a result, VSHN Managed OpenShift users can be confident that their clusters remain secure without having to worry about this specific vulnerability.

We are thrilled to announce the general availability of Redis by VSHN, now available in OpenShift through the VSHN Application Marketplace. This powerful, in-memory data structure store, known for its blazing-fast performance and versatility, is now optimized for containerized environments on OpenShift. Whether you’re building microservices, real-time analytics, or caching layers, Redis by VSHN offers the reliability and scalability your applications need.

Why Redis on OpenShift?

Redis has been a favorite among developers for its simplicity, performance, and robustness. By integrating Redis into OpenShift, we are enabling seamless deployment and management of Redis instances within your containerized infrastructure. This means you can now leverage Redis’s capabilities while enjoying the benefits of OpenShift’s orchestration and container management.

Key Features

1. Containerized Deployment: Effortlessly deploy and manage Redis instances in your OpenShift environment.
2. Scalability: Scale your Redis instances up or down based on your application needs.
3. High Availability: Ensure your data is always available with Redis’s built-in replication and persistence mechanisms.
4. Integrated Monitoring: Utilize OpenShift’s monitoring tools to keep an eye on your Redis performance and health.
5. Security: Benefit from OpenShift’s security features to protect your Redis instances and data.

Benefits for Your Containerized Applications

1. Performance: Redis’s in-memory data structure ensures lightning-fast read and write operations, ideal for real-time applications.
2. Flexibility: Support for a variety of data structures, including strings, hashes, lists, sets, and more.
3. Compatibility: Seamlessly integrate with your existing OpenShift applications and services.
4. Developer Productivity: Simplified deployment and management allow developers to focus on building features rather than infrastructure.

Getting Started

To get started with Redis by VSHN, visit our Redis product page on the OpenShift Application Marketplace. Our comprehensive documentation will guide you through the setup process, ensuring you can quickly and efficiently integrate Redis into your workflows.

Do you want to see all our open documentation for how to create or use any of the services in the marketplace? You can find them all openly available here VSHN AppCat User Documentation

Be on the lookout for more services as we continue expanding our marketplace. Let’s keep those containers humming!

Ready to roll?

Contact us now!

We have some fantastic news – our PostgreSQL service is now generally available on OpenShift in our Application Catalog through the VSHN Application Marketplace. After seeing our container-based database solution work wonders for a few lucky customers, we’re excited to open it up for all to enjoy!

Why You’ll Love It

• Always On: our high availability setup keeps your data accessible.
• Safety First: top-notch security features to keep your data safe.
• Grow As You Go: easily scale with your business needs.
• Hands-Free Maintenance: automatic updates and backups? Yes, please!
• Expert Help: our team is always here to support you.

Do you have an application that you run in containers or are moving to containers that uses PostgreSQL? Do you not want the complexity of running your database within a Kubernetes cluster?

Then check out PostgreSQL by VSHN to dive into the details and get started today.

Do you want to see all our open documentation for how to create or use any of the services in the marketplace? You can find them all openly available here VSHN AppCat User Documentation

Be on the lookout for more services as we continue expanding our marketplace. Let’s keep those containers humming!

Ready to roll?

Contact us now!

Hey there! We’re thrilled to introduce Keycloak by VSHN – your new go-to for robust, open-source identity and access management (IAM). Bringing together the expertise of VSHN and Inventage, designed to simplify authentication and boost security, our managed service is here to make your life easier and your apps more secure. Let’s dive into what makes Keycloak awesome, and why the VSHN managed version is even better!

What’s the Buzz About Keycloak?

Keycloak is an open-source powerhouse for managing identities and access. With it, you can integrate authentication across your services with little fuss. It’s packed with features like user federation, strong authentication, comprehensive user management, and finely tuned authorization controls. In short, it’s all about making secure access as straightforward as possible.

Why Should Your Enterprise Use Keycloak?

Here are just a few reasons:

• Single Sign-On (SSO) Magic: Log in once and access all your apps without breaking a sweat. Plus, logging out from one logs you out from all – neat, right?
• Integration Ease: Keycloak plays nicely with OpenID Connect, OAuth 2.0, and SAML 2.0, sliding seamlessly into your existing setup.
• Empowering User Federation: Whether it’s LDAP or Active Directory, Keycloak connects smoothly, ensuring all your bases are covered.
• Granular Control: With its intuitive admin console, managing complex authorization scenarios is a breeze.
• Scalable Performance: From startups to large enterprises, Keycloak scales with your needs without skipping a beat.

Open Source vs. Proprietary: Why Go Open?

Choosing Keycloak means embracing benefits like:

• Cost Efficiency: Forget about expensive proprietary license fees; open-source is wallet-friendly.
• Total Transparency: Open-source means anyone can check the code, which helps in keeping things secure and up to snuff.
• Community Driven: Benefit from the innovations and support of a global community.
• Ultimate Flexibility: Adapt and extend Keycloak however you see fit. You’re in control!

What Makes Keycloak by VSHN Special?

• All the Keycloak Goodies: Everything Keycloak offers, we provide, managed and tuned by experts.
• Swiss-Based Hosting: Enjoy top-tier privacy, security, and adherence to Swiss regulations.
• Expert Support: The Keycloak wizards from Inventage and the Kubernetes experts from VSHN are here to help you every step of the way. To learn more visit the Keycloak Competence Center Switzerland (Keycloak Competence Center Switzerland ) run by Inventage.
• Transparent Pricing: What you see is what you get. No surprises here!
• Solid SLAs and High Availability: We promise uptime and smooth operations, come rain or shine.

We Love Open Source!

With VSHN, you’re not just getting a service; you’re tapping into a philosophy. Backed by Red Hat and supported by Inventage, we bring you unparalleled expertise right from the heart of Switzerland.

Why Choose Keycloak?

It’s not just stable and feature-rich; it’s a part of the open-source legacy of Red Hat, enhanced by VSHN’s partnership with Inventage – making us a powerhouse of knowledge and reliability in the container and cloudnative IAM domain.

Ready to Jump In?

Dive into seamless identity management with Keycloak by VSHN. Curious for more? Visit our Keycloak product definition page (Keycloak by VSHN) for all the juicy details and kickstart your journey towards streamlined application security.

Ready to roll? Contact us now!

(This post was originally published on the Crossplane blog.)

Crossplane has recently celebrated its fifth birthday, but at VSHN, we’ve been using it in production for almost three years now. In particular, it has become a crucial component of one of our most popular products. We’ve invested a lot of time and effort on Crossplane, to the point that we’ve developed (and open-sourced) our own custom modules for various technologies and cloud providers, such as Exoscale, cloudscale.ch, or MinIO.

In this blog post, we will provide an introduction to a relatively new feature of Crossplane called Composition Functions, and show how the VSHN team uses it in a very specific product: the VSHN Application Catalog, also known as VSHN AppCat.

Crossplane Compositions

To understand Composition Functions, we need to understand what standard Crossplane Compositions are in the first place. Compositions, available in Crossplane since version 0.10.0, can be understood as templates that can be applied to Kubernetes clusters to modify their configuration. What sets them apart from other template technologies (such as Kustomize, OpenShift Template objects, or Helm charts) is their capacity to perform complex transformations, patch fields on Kubernetes manifests, following more advanced rules and with better reusability and maintainability. Crossplane compositions are usually referred to as “Patch and Transform” compositions, or “PnT” for short.

As powerful as standard Crossplane Compositions are, they have some limitations, which can be summarized in a very geeky yet technically appropriate phrase: they are not “Turing-complete”.

• Compositions don’t support conditions, meaning that the transformations they provide are applied on an “all or nothing” basis.
• They also don’t support loops, which means that you cannot apply transformations iteratively.
• Finally, advanced operations are not supported either, like checking for statuses in other systems, or performing dynamic data lookups at runtime.

To address these limitations, Crossplane 1.11 introduced a new Alpha feature called “Composition Functions”. Note that as of writing, Composition Functions are in Beta in 1.14.

Composition Functions

Composition functions complement and in some cases replace Crossplane “PnT” Compositions entirely. Most importantly, DevOps engineers can create Composition Functions using any programming language; this is because they run as standard OCI containers, following a specific set of interface requirements. The result of applying a Composition Function is a new composite resource applied to a Kubernetes cluster.

Let’s look at an elementary “Hello World” example of a Composition Function.

apiVersion: apiextensions.crossplane.io/v1
kind: Composition
metadata:
  name: example-bucket-function
spec:
  compositeTypeRef:
    apiVersion: example.crossplane.io/v1
    kind: XBucket
  mode: Pipeline
  pipeline:
  - step: handle-xbucket-xr
    functionRef:
      name: function-xr-xbucket

The example above shows a standard Crossplane composition with a new field: “pipeline” specifying an array of functions, referred to via their name.

As stated previously, the function itself can be written in any programming language, like Go.

func (f *Function) RunFunction(_ context.Context, req *fnv1beta1.RunFunctionRequest) (*fnv1beta1.RunFunctionResponse, error) {
    rsp := response.To(req, response.DefaultTTL)
    response.Normal(rsp, "Hello world!")
    return rsp, nil
}

The example above, borrowed from the official documentation, does just one thing: it reads a request object, modifies a value, and returns it to the caller. Needless to say, this example is for illustration purposes only, lacking error checking, logging, security, and more, and should not be used in production. Developers use the Crossplane CLI to create, test, build, and push functions.

Here are a few things to keep in mind when working with Composition Functions:

• They run in order, as specified in the “pipeline” array of the Composition object, from top to bottom.
• The output of the previous Composition Function is used as input for the following one.
• They can be combined with standard “PnT” compositions by using the function-patch-and-transform function, allowing you to reuse your previous investment in standard Crossplane compositions.
• In the Alpha release, if you combined “PnT” compositions with Composition Functions, “PnT” compositions ran first, and the output of the last one is fed to the first function; since the latest release, this is no longer the case, and “PnT” compositions can now run at any step of the pipeline.
• Composition Functions must be called using RunFunctionRequest objects, and return RunFunctionResponse objects.
• In the Alpha release, these two objects were represented by a now deprecated “FunctionIO” structure in YAML format.
• RunFunctionRequest and RunFunctionResponse objects contain a full and coherent “desired state” for your resources. This means that if an object is not explicitly specified in a request payload, it will be deleted. Developers must pass the full desired state of their resources at every invocation.

Practical Example: VSHN AppCat

Let’s look at a real-world use case for Crossplane Composition Functions: the VSHN Application Catalog, also known as AppCat. The AppCat is an application marketplace allowing DevOps engineers to self-provision different kinds of middleware products, such as databases, message queues, or object storage buckets, in various cloud providers. These products are managed by VSHN, which frees application developers from a non-negligible burden of maintenance and oversight.

Standard Crossplane “PnT” Compositions proved limited very early in the development of VSHN AppCat, so we started using Composition Functions as soon as they became available. They have allowed us to do the following:

• Composition Functions enable complex tasks, involving the verification of current deployment values and taking decisions before deploying services.
• They can drive the deployment of services involving Helm charts, modifying values on-the-go as required by our customers, their selected cloud provider, and other parameters.
• Conditionals allow us to script complex scenarios, involving various environmental decisions, and to reuse that knowledge.
• Thanks to Composition Functions, the VSHN team can generalize many activities, like backup handling, automated maintenance, etc.

All things considered, it is difficult to overstate the many benefits that Composition Functions have brought to our workflow and to our VSHN AppCat product.

Learnings of the Alpha Version

We’ve learned a lot while experimenting with the Alpha version of Composition Functions, and we’ve documented our findings for everyone to learn from our mistakes.

• Running Composition Functions in Red Hat OpenShift used to be impossible in Alpha because OpenShift uses crun, but this issue has now been solved in the Beta release.
• In particular, when using the Alpha version of Composition Functions, we experienced slow execution speeds with crun but this is no longer the case.
• We learned the hard way that missing resources on function requests were actually deleted!

Our experience with Composition Functions led us to build our own function runner. This feature uses another capability of Crossplane, which allows functions to specify their runner in the Composition definition:

apiVersion: apiextensions.crossplane.io/v1
kind: Composition
[...]
  functions:
  - name: my-function
    type: Container
    container:
      image: my-function
      runner:
        endpoint: grpc-server:9547

Functions run directly on the gRPC server, which, for security reasons, must run as a sidecar to the Crossplane pod. Just like everything we do at VSHN, the Composition Function gRPC Server runner (as well as its associated webhook and all of its code) is open-source, and you can find it on our GitHub. As of the composition function beta, we replaced the custom GRPC logic with the go-sdk. To improve the developer experience, we have created a proxy and enabled the gRPC server to run locally. The proxy runs in kind and redirects to the local gRPC server. This enables us to debug the code and to test changes more efficiently.

Moving to Beta

We recently finished migrating our infrastructure to the most recent Beta version of Composition Functions, released in Crossplane 1.14, and we have been able to do that without incidents. This release included various bits and pieces such as Function Pipelines, an ad-hoc gRPC server to execute functions in memory, and a Function CRD to deploy them directly to clusters.

We are also migrating all of our standard “PnT” Crossplane Compositions to pure Composition Functions as we speak, thanks to the functions-go-sdk project, which has proven very helpful, even if we are missing typed objects. Managing the same objects with the “PnT” and Composition Functions increases complexity dramatically. As it can be difficult to determine where an actual change happens.

Conclusion

In this blog post, we have seen how Crossplane Composition Functions compare to standard “PnT” Crossplane compositions. We have provided a short example, highlighting their major characteristics and caveats, and we have outlined a real-world use case for them, specifically VSHN’s Application Catalog (or AppCat) product.

Crossplane Composition Functions provide an unprecedented level of flexibility and power to DevOps engineers. They enable the creation of complex transformations, with all the advantages of an Infrastructure as Code approach, and the flexibility of using the preferred programming language of each team.

Check out my talk at Control Plane Day with Crossplane, where I walk you through Composition Functions in Production in 15 minutes.

Yesterday evening, on Monday, July 24th, 2023, at around 21:15 CEST / 12:15 PDT, our security team received a notification about a critical security vulnerability called “Zenbleed” potentially affecting the cloud providers where VSHN’s customers systems run on.

This blog post provides details about Zenbleed and the steps taken to mitigate its risks.

What is Zenbleed?

Zenbleed, also known as CVE-2023-20593, is a speculative execution bug discovered by Google, related to but somewhat different from side channel bugs like Meltdown or Spectre. It is a vulnerability affecting AMD processors based on the Zen2 microarchitecture, ranging from AMD’s EPYC datacenter processors to the Ryzen 3000 CPUs used in desktop & laptop computers. This flaw can be exploited to steal sensitive data stored in the CPU, including encryption keys and login credentials.

VSHN’s Response

VSHN immediately set up a task force to discuss this issue, including the team of one of our main cloud providers (cloudscale.ch) in a call to determine choices of action; among possible options, were contemplated ideas like isolating VSHN customers on dedicated nodes, or patching the affected systems directly.

At around 22:00 CEST, the cloud provider decided after a fruitful discussion with the task force that the best approach was to implement a microcode update. Since Zenbleed is caused by a bug in CPU hardware, the only possible direct fix (apart from the replacement of the CPU) consists of updating the CPU microcode. Such updates can be applied by updating the BIOS on affected systems, or applying an operating system kernel update, like the recently released new Linux kernel version that addresses this vulnerability.

Zenbleed isn’t limited to just one cloud provider, and may affect customers operating their own infrastructure as well. We acknowledged that addressing this vulnerability is primarily a responsibility of the cloud providers, as VSHN doesn’t own any infrastructure that could directly be affected.

The VSHN task force handed the monitoring over to VSHN Canada to test the update as it rolled out to production systems, who stayed in close contact to ensure there were no QoS degradations after the microcode update.

Aftermath

cloudscale.ch successfully finished its work at 01:34 CEST / 16:34 PDT. All VSHN systems running on that provider have been patched accordingly, and the tests carried show that this specific vulnerability has been fixed as required. VSHN Canada confirmed that all systems were running without any problems.

We will continue to monitor this situation and to inform our customers accordingly. All impacted customers will be contacted by VSHN. Please do not hesitate to contact us for more information.