Software supply chains have become more complex and increasingly targeted, making container image security a fundamental requirement for building trust in modern delivery pipelines.

By signing images with Cosign and protecting signing keys in OVHcloud KMS, teams can keep cryptographic material out of local environments and CI/CD variables, all while making image signing easier to control, audit and integrate into delivery pipelines.

In this blog post, you will learn how to use the OVHcloud KMS plugin for Cosign to generate a key, sign a container image with this key and verify that the OCI image has been correctly signed.

Cosign

Cosign is a tool from the Sigstore project used to sign, verify, and attest OCI container images and software artifacts.

Cosign supports several signing modes, including keyless signing through Sigstore, where short-lived certificates are generated at signing time based on your identity (via GitHub, Google or another OIDC provider), as well as ephemeral key generation, hardware and KMS-backed signing and custom PKI integration.

Cosign supports multiple KMS providers to generate and sign keys. Several external KMS providers are supported, including HashiCorp Vault, AWS KMS, GCP KMS and Azure Key Vault.
Cosign can now also be integrated with OVHcloud KMS through the Sigstore Cosign OVHcloud KMS plugin 💪.

OVHcloud Key Management Service (KMS)

OVHcloud KMS, often called OKMS, is a managed service that centralizes the creation, storage, and management of encryption keys. Its main goal is to help businesses secure data and control cryptographic operations from a single platform.

Each KMS is associated with a region, so the keys stored in that region are guaranteed to stay in that region. You can order multiple KMSs, either in different regions or in the same region.

Prerequisites

To be able to use the Sigstore KMS OVHcloud provider, you need to follow some prerequisites:

• Have an OVHcloud account
• Have created an OKMS domain (“305db938-1234-5678-9012-3a0a29291661” for example in this blog post)
• Have created an IAM local user (“cosign-305db938-1234-5678-9012-3a0a29291661” for example in this blog post)
• Have installed the OVHcloud CLI
• Have uuidgen CLI installed

💡The cosign OVHcloud plugin supports both token and mTLS authentication. For the purposes of this blog post, we will use the token authentication mode. Please follow the Sigstore Cosign KMS plugin for OVHcloud guide if you wish to use mTLS authentication mode.

Generate a PAT token (for token authentication only)

List the OKMS domains:

$ ovhcloud okms list
┌──────────────────────────────────────┬─────────────┐
│                  id                  │   region    │
├──────────────────────────────────────┼─────────────┤
│ 305db938-1234-5678-9012-3a0a29291661 │ eu-west-par │
│ xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx │ eu-west-par │
└──────────────────────────────────────┴─────────────┘

Save the OKMS ID in an environment variable:

export KMS_RESTAPI_OKMSID="305db938-1234-5678-9012-3a0a29291661"

The cosign OVHcloud plugin needs the permission to create and fetch keys from the OVHcloud KMS.

If you want to use token autentication, you’ll need a token (PAT). You can use the ovhcloud CLI to do that:

PAT_TOKEN=$(ovhcloud iam user token create <iam-local-user-name> --name pat-<iam-local-user-name> --description "PAT cosign for domain $KMS_RESTAPI_OKMSID" -o json  | jq .details.token |  tr -d '"')

echo $PAT_TOKEN

You should have a result like this:

$ PAT_TOKEN=$(ovhcloud iam user token create cosign-305db938-1234-5678-9012-3a0a29291661 --name pat-cosign-305db938-1234-5678-9012-3a0a29291661 --description "PAT cosign for domain 305db938-1234-5678-9012-3a0a29291661" -o json  | jq .details.token |  tr -d '"')
2026/05/07 08:48:34 Final parameters:
{
 "description": "PAT cosign for domain 305db938-1234-5678-9012-3a0a29291661",
 "name": "pat-cosign-305db938-1234-5678-9012-3a0a29291661"
}

$ echo $PAT_TOKEN
eyJhbGciOiJFZE...ASgXy55_DDFHdy4Z5uSq8lww-Bw

Save the KMS information

Save the KMS information in environment variables. For example:

export KMS_RESTAPI_ENDPOINT=$(ovhcloud okms get $KMS_RESTAPI_OKMSID -o json | jq .restEndpoint | xargs)
export KMS_RESTAPI_TYPE="token"
export KMS_RESTAPI_TOKEN=$PAT_TOKEN

Display the saved information:

$ echo $KMS_RESTAPI_ENDPOINT
https://eu-west-par.okms.ovh.net

$ echo $KMS_RESTAPI_OKMSID
305db938-1234-5678-9012-3a0a29291661

$ echo $KMS_RESTAPI_TYPE
token

$ echo $KMS_RESTAPI_TOKEN
eyJ...BIoHCA

Cosign KMS plugin installation

Install the plugin locally:

curl -fsSL https://raw.githubusercontent.com/ovh/sigstore-kms-ovhcloud/main/install.sh | sh

⚠️ The binary is installed in $HOME/.local/bin by default (created if it does not exist). Make sure this directory is in your PATH.

Or follow the other installation methods.

Now you can use the OVHcloud KMS plugin directly in the cosign command 🎉.

Let’s use Cosign with the OVHcloud KMS!

Generate a key

First, to sign an image, we need to generate a key pair. To do that we need to generate a UUID and use it in the cosign generate-key-pair command.

export KEY_ID=$(uuidgen)
cosign generate-key-pair --kms ovhcloud://$KEY_ID

The signing key is created in OVHcloud KMS, and the public key is written locally.

You should see an output like this:

$ export KEY_ID=$(uuidgen)
$ cosign generate-key-pair --kms ovhcloud://$KEY_ID

Public key written to cosign.pub

The command generates a key pair using the ECDSA algorithm and writes the public key to cosign.pub.

Check the keys have been created:

$ ls -l cosign.pub
-rw-------  1 avache  staff  178 18 juin  16:06 cosign.pub

$ cat cosign.pub

-----BEGIN PUBLIC KEY-----
MFkw...QgwA==
-----END PUBLIC KEY-----

Once the key pair has been generated, use the corresponding OVHcloud KMS key ID in the ovhcloud://$KEY_ID URI when signing and verifying images.

Or get an existing public key (optional)

Instead of creating a new public key, you can retrieve an existing one with the following command:

cosign public-key --key ovhcloud://$KEY_ID --outfile cosign-ovhcloud.pub

Sign an image

Replace the $IMAGE@sha256:$HASH parameter with the URI to your image and the hash to your image and execute this command:

cosign sign --key ovhcloud://$KEY_ID $IMAGE@sha256:$HASH

You should see an output like this:

$ cosign sign --key ovhcloud://$KEY_ID 12345678.c1.de1.container-registry.ovh.net/my-project/my-image@sha256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Verify the image has been signed

cosign verify --key ovhcloud://$KEY_ID $IMAGE@sha256:$HASH

You should see an output like this:

$ cosign verify --key ovhcloud://$KEY_ID 12345678.c1.de1.container-registry.ovh.net/my-project/my-image@sha256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Verification for 12345678.c1.de1.container-registry.ovh.net/my-project/my-image@sha256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxx --
The following checks were performed on each of these signatures:
  - The cosign claims were validated
  - Existence of the claims in the transparency log was verified offline
  - The signatures were verified against the specified public key

[{"critical":{"identity":{"docker-reference":"12345678.c1.de1.container-registry.ovh.net/my-project/my-image@sha256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxx"},"image":{"docker-manifest-digest":"sha256:b1202...2334e2"},"type":"https://sigstore.dev/cosign/sign/v1"},"optional":{}}]

Conclusion

In this blog post, we have shown how to use Cosign with the OVHcloud KMS plugin to generate a key pair, sign a container image and verify its signature.

By keeping signing keys in a managed KMS, teams can reduce secret sprawl, protect sensitive cryptographic material and make image signing easier to integrate into secure CI/CD workflows.

Feel free to take a look at our Cloud Roadmap & Changelog to follow the latest features coming to OVHcloud Public Cloud products.

In a previous blog post, I explained how to use OVHcloud S3-compatible Object Storage as a Terraform backend for storing Terraform/OpenTofu state files.

Since then, we’ve enhanced OVHcloud Object Storage, and one of the coolest improvements is the support for conditional writes. By preventing concurrent overwrites, this feature enables Terraform’s native S3 state-locking mechanism to work seamlessly with OVHcloud Object Storage.

In practice, Terraform/OpenTofu can create a .tflock object only if it does not already exist. If another operation has already created the lock file, the conditional write fails and the second operation is blocked.

With this blog post, I explain how we can configure our Terraform/OpenTofu backend to store our states in an OVHcloud S3-compatible Object Storage with S3 state locking.

Terraform/OpenTofu S3 State Locking feature

State locking is a critical feature for collaborative Terraform/OpenTofu workflows. It ensures that only one operation can modify a state file at any given time, preventing concurrent writes that could lead to inconsistencies or state corruption.

Concretely, when a user runs terraform apply (or tofu apply), Terraform creates a .tflock file in the S3 bucket. This lock file indicates that an operation is currently in progress and that the state file is being used. If another user attempts to run terraform apply (or tofu apply) while the lock is active, Terraform detects the existing lock and aborts the operation with an error message. This prevents concurrent modifications of the state file and helps avoid state corruption.

Prerequisites

To be able to store your Terraform/OpenTofu states and activate the use_lockfile feature, you need to follow some prerequisites:

• Have an OVHcloud account
• Created a S3-compatible Object Storage (enable bucket versioning for your state bucket so previous state versions can be recovered if needed)
• Installed the Terraform CLI or OpenTofu CLI (version 1.10 or >)
• Installed the OVHcloud CLI

Save the s3 user credentials in environment variables (that allows you to access and store files in the bucket):

export AWS_ACCESS_KEY_ID="xxxxxxxxx"
export AWS_SECRET_ACCESS_KEY="yyyyyyyyy"

Configure it

Create a new folder, named my-app (for example), and go into it.

Create a provider.tf file with the following content, and replace the bucket value witht he name of the bucket you created:

terraform {
    backend "s3" {
      bucket = "terraform-state-3az" # the name of YOUR bucket
      key    = "my-app.tfstate" # the name of the state of your app
      region = "eu-west-par" # the region of the bucket
      endpoints = {
        s3 = "https://s3.eu-west-par.io.cloud.ovh.net/" # the endpoint
      }
      skip_credentials_validation = true
      skip_region_validation      = true
      skip_requesting_account_id  = true
      skip_s3_checksum            = true

      use_lockfile = true  # activation of the S3 native state locking feature
    }
}

💡The use_lockfile = true argument enables native S3 state locking. Terraform/OpenTofu uses the .tflock object to prevent two operations from writing to the same state file at the same time.

Test it!

Create a resource.tf file with an example resource to create (only for the testing purpose):

resource "null_resource" "test" {}

Initialise Terraform:

$ terraform init

Initializing the backend...

Successfully configured the backend "s3"! Terraform will automatically
use this backend unless the backend configuration changes.
Initializing provider plugins...
- Finding latest version of hashicorp/null...
- Installing hashicorp/null v3.3.0...
- Installed hashicorp/null v3.3.0 (signed by HashiCorp)
Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

As you can see, Terraform is using “s3” backend and initialized the provider plugins. 💪

💡Note that .terraform.lock.hcl is the provider dependency lock file created during initialization. The state lock file used for S3 backend locking is the .tflock file shown in the bucket during terraform apply.

Execute the apply command (without answering “yes”):

$ terraform apply

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # null_resource.test will be created
  + resource "null_resource" "test" {
      + id = (known after apply)
    }

Plan: 1 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value:

Check if a new file appears in the S3 bucket:

$ ovhcloud cloud storage object object list terraform-state-3az

┌───────────────────────┬──────┐
│          key          │ size │
├───────────────────────┼──────┤
│ my-app.tfstate.tflock │ 219  │
└───────────────────────┴──────┘
💡 Use option -o json or -o yaml to get the raw output with all information

A .tflock file appears! 💪

You can also check it in the OVHcloud Control Panel:

This .tflock file means that someone is working on this infrastructure. After answering “yes” to the terraform apply command, the resources will be deployed, the state will appear and the lock file will disappear:

$ terraform apply

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # null_resource.test will be created
  + resource "null_resource" "test" {
      + id = (known after apply)
    }

Plan: 1 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

null_resource.test: Creating...
null_resource.test: Creation complete after 0s [id=2048943220587414471]

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.


$ ovhcloud cloud storage object object list terraform-state-3az
┌────────────────┬──────┐
│      key       │ size │
├────────────────┼──────┤
│ my-app.tfstate │ 612  │
└────────────────┴──────┘
💡 Use option -o json or -o yaml to get the raw output with all information

🎉

Why this Terraform state locking feature is useful?

If a user executes terraform apply command (without answering yes) and another user executes the same command, an error message will be displayed:

$ terraform apply

╷
│ Error: Error acquiring the state lock
│
│ Error message: operation error S3: PutObject, https response error StatusCode: 412, RequestID: tx7b439680a0104339a2fc7-xxxxxxxxxxxx, HostID: tx7b439680a0104339a2fc7-xxxxxxxxxxxx, api error
│ PreconditionFailed: At least one of the pre-conditions you specified did not hold
│ Lock Info:
│   ID:        xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
│   Path:      terraform-state-3az/my-app.tfstate
│   Operation: OperationTypeApply
│   Who:       avache@xxxxxxxxxx
│   Version:   1.14.9
│   Created:   2026-06-09 13:09:05.562244 +0000 UTC
│   Info:
│
│
│ Terraform acquires a state lock to protect the state from being written
│ by multiple users at the same time. Please resolve the issue above and try
│ again. For most commands, you can disable locking with the "-lock=false"
│ flag, but this is not recommended.
╵

This error is expected. It means another Terraform/OpenTofu operation has already acquired the state lock, so the second operation cannot modify the state file at the same time. The user should wait until the first operation is complete and the lock file has been released, then retry. Although Terraform allows locking to be disabled with -lock=false, this is not recommended because it can lead to concurrent state changes and potential state corruption.

Conclusion

In this blog post, we have seen one use case of conditional writes, but the feature goes far beyond that. Support for conditional writes does not only help prevent accidental overwrites; it also enables safer concurrent workflows, such as Terraform/OpenTofu state locking.

Our team is working on the improvement of Object Storage, so stay tuned for more. And please, as alays, share your thoughts with us!

Every month, the OVHcloud Developer Advocate team creates content, shares knowledge, and connects with the tech community. Here’s a look at what we did in May 2026. 🚀

🎙️ “Tranches de Tech” – Our monthly podcast

A new episode of our French-language podcast Tranches de Tech 🥑 just dropped!

🎧 Episode 28: La dream team au complet

In this episode of Tranche de Tech, Stephane and Aurelie welcome former team member Thierry for a wide-ranging conversation on tech, conferences, and community.
They reflect on recent events like Devoxx France and MiXiT, sharing highlights from talks, trends, and the growing role of AI in today’s software landscape.
The discussion explores how AI is evolving from pure model innovation toward software patterns, developer tooling, and more practical, structured usage.
Thierry also introduces CALM, his weekly Twitch show, and revisits the inspiring story behind Mixtine, a kids’ tech initiative that brings programming and digital culture to younger generations.
More than a tech recap, this episode is a celebration of curiosity, knowledge sharing, and the importance of building inclusive communities around technology.

See episode shownotes

📺 Live on Twitch

We streamed live on Twitch this month! Here’s what we covered:
🎥 Rémy Vandepoel discussed with Magali De Labareyre about ou human resource management and the OVHcloud culture.
Catch the replay on YouTube ▶️.

🎤 Conference Talks

The team hit the road (and the stage) at several conferences this month:

🏴󠁧󠁢󠁥󠁮󠁧󠁿 Devoxx UK, Londres 🏴󠁧󠁢󠁥󠁮󠁧󠁿

Stéphane gave a talk: 🧰 Dev Containers: the ultimate toolbox for developers?

🇫🇮 KCD Helsinki, Helsinki 🏴󠁧󠁢󠁥󠁮󠁧󠁿

Aurélie Vache gave a talk: The Ultimate Kubernetes Challenge: An Interactive Trivia Game on concepts, components, usage…

🇨🇭 Devopsdays Geneva, Geneva 🇫🇷

Stéphane Philippart gave a workshop Développer avec l’IA : et si c’était aussi simple qu’ajouter une librairie ?

📝 Our latest blog posts

Here are the articles our team published on the OVHcloud Blog this month.

📝 Devoxx France 2026: feedback and highlights – by Aurélie Vache

This blog post explains what stood out at Devoxx France 2026, from major conference highlights to the key technology trends shaping the developer ecosystem.
It shows how AI dominated the event, with strong attention on agentic systems, governance, production use cases, and the broader impact of AI on software engineering.
The article also highlights OVHcloud’s strong presence through its booth, community engagement, and a large number of accepted talks and speakers.
Beyond AI, it captures wider themes such as platform engineering, security, cloud resilience, developer experience, open source, and digital sovereignty.
Overall, it offers both a conference recap and a clear snapshot of where the industry is heading in 2026.

📝 Navigating OVHcloud Enterprise File Storage (EFS) with Trident CSI On Kubernetes clusters (MKS) – by Aurélie Vache

This blog post explains how to connect OVHcloud Enterprise File Storage (EFS) to Managed Kubernetes Service (MKS) clusters using NetApp Trident CSI.
It walks readers through provisioning the required OVHcloud resources with Terraform, including EFS, OAuth2 credentials, IAM policies, and vRack Services networking.
The article then shows how to install Trident, configure the backend securely, and integrate EFS as dynamic shared storage for Kubernetes workloads.
It highlights key capabilities such as high availability, predictable performance, and ReadWriteMany access for production-ready persistent storage.
Overall, it serves as a practical step-by-step guide for teams that need scalable shared file storage in OVHcloud Kubernetes environments.

📝 Copy.Fail (CVE-2026-31431): How to Rapidly Protect OVHcloud MKS Clusters from the Linux Kernel Zero-Day – by Aurélie Vache

This blog post explains how the Copy.Fail (CVE-2026-31431) Linux kernel zero-day can rapidly compromise systems through reliable privilege escalation.
It shows how the flaw abuses the algif_aead crypto module to hijack trusted binaries in memory without changing files on disk, making detection harder.
The article highlights the risks for Kubernetes clusters, CI/CD runners, shared environments, and multi-tenant infrastructure.
It also provides an immediate DaemonSet-based mitigation that OVHcloud MKS users can deploy while waiting for patched cluster versions.
Overall, it serves as a practical guide to reducing exposure quickly, while reminding readers that the official security patch is the proper long-term fix.

🎙️ Podcasts / Videos 📺

Aurélie was invited in the podcast “Biztrot Café #2 – IA Gen or not IA Gen ?“.
During this second episode of the podcast, Marian, Julien, Jean-Phi and Aurélie discussed about a recurring question: “AI Gen or not AI Gen?” and the growing use of generative AI in the tech community. Together, they discuss how AI is being used to create conference talks, presentation slides, blog posts, and even sketchnotes. They share both the benefits and the limitations of these tools, highlighting how generative AI can accelerate content creation while still requiring careful review, creativity, and significant iteration to achieve high-quality results.
Watch the replay on YouTube ▶️.

🗓️ Coming up next

Here’s a sneak peek at what’s coming next.

🗓️ – June, 3 – 1h PM CET – Very Tech Talk Twitch about Quantum

📺 OVHcloud Twitch channel

🗓️ – June, 11 & 12 Dev Quest Niort (Niort, France)

🎤 Aurélie Vache is giving one talk (Thursday the 11th at 2h30 PM): Comprendre Kubernetes de manière visuelle

🎤 Stéphane Philippart is giving one workshop (Friday the 12th at 10h AM): Ajouter de l’IA à nos applications : et si c’était aussi simple qu’ajouter une librairie ?

🗓️ – June, 24, 25 & 26 – BreizhCamp (Rennes, France)

🎤 Stéphane Philippart is giving two talks:
– JBang, un fichier Java pour les gouverner tous ? 💍 (Thurdsay the 25th at 5h PM)
– 🧰 Les dev containers, la boîte à outils ultime pour les devs ? (Friday the 26th at 4h PM)

🗓️ New “Tranches de Tech” podcast episode

🎧 All episodes are available on Ausha and all your favorite podcast applications!

💬 Stay in Touch

Want to chat with us, share your thoughts, or just say hi? Here’s how to get in touch with the Developer Advocate team:

• 🟣 Discord: OVHcloud Discord server
• 🐦 X / Twitter: @OVHcloud
• 💼 LinkedIn: OVHcloud LinkedIn
• 🐙 GitHub: github.com/ovh

See you next month! 👋

Aurélie Vache and Stéphane Philippart attended as dit 19 other OVHcloud employees. In this blog post, they share their thoughts and feedback from this 14th edition of Devoxx France.

Devoxx France 2026: The AI Edition

Devoxx France 2026 is one of Europe’s biggest independent developer conferences. Formerly focused centrally on Java, over the past few years, the conference has also focused on Architecture, Data & Analytics, Development practices, Front-end & UX, Java/JVM, Security & Privacy, Cloud and non-technical talks about people and culture.

Key figures from the 2026 edition:

• 4,980 attendees (The largest attendance on record)
• 307 speakers
• 259 talks
• 70+ sponsors

As might be expected, AI was the central theme of this edition, with a large number of the talks focused on AI topics. Indeed, there were 65 sessions out of 259 about AI and Agentic Systems, the most discussed topic!

Notably this year, and perhaps even more than in previous years, we could clearly see attendees arriving early to secure seats for their favorite talks. Even so, there ended up being a lot of disappointment – especially on the first day – as several sessions were already at full capacity minutes before they even started.

This was particularly true for sessions featuring multiple OVHcloud speakers 💪.

Keynotes

The keynote sessions (“plenary sessions”) were also heavily centered on Artificial Intelligence, but with a notably broader lens beyond pure technology. Rather than focusing only on tools or LLM implementation, the talks explored AI through the intersecting dimensions of power, governance, cybersecurity, human transformation, and geopolitics.

Some highlights from the keynotes:

• “In 50 years, AI has multiplied its power, along with the challenges of governance and cybersecurity” – Laurence Devillers (@lau_devil)

• Jean-Gabriel Ganascia (@Quecalcoatle) questioned the promise of AI as a force that could free humans from effort, raising deeper reflections on what this means for our relationship with work and meaning.

• Loup Cellard (@CellardLoup) examined the implications of foreign investments in AI infrastructure, shedding light on the geopolitical and strategic stakes behind these technologies.

Meet & Greet

Devoxx France consists of three days of conferences, sponsor booths to discover, and Thursday evening’s unmissable annual tradition: the Meet & Greet.

Thursday night’s Meet & Greet is a major community event built around networking and social sessions like BOFs (Birds of a Feather) and seed networking. It’s one of the signature traditions of the conference, beyond talks and sponsor booths.

This evening event is free, open to the public with pre-registration, and offers a genuine moment for connection, sharing, and conversation over a drink and a plate of charcuterie and cheese 😇.

It’s also the opportunity to discover the fun of “Voxx Jam”, the community-party, music-oriented side of Devoxx/Voxxed culture 🎸.

OVHcloud Presence

At the OVHcloud booth, we were a team of 8 speakers and 11 colleagues from Tech, HR, and Sales, and their dynamic presence really made a difference. Engaging in topics like AI, Public Cloud, Domain Names, Observability, Quantum technologies, and more, we had many insightful conversations throughout the event.

We also discussed AI topics at the booth, which was of course the main theme of the conference, but not the only one.

A lot of conversations also focused on sovereignty. Three years ago, people were saying: “I don’t care about sovereignty, I’ll just choose the cheapest option.” This year, the tone has clearly changed, “How can we use your sovereign products?”

There is a real shift happening, and once again, being present at events like this is essential to witness and take part in these evolving discussions.

It was truly a top-tier booth experience for all of us💪.

Of course, the goal of our booth was so attendees could discuss with our teams, but also so we could engage them through our very own video game, “Gaming Camp: Beat Cloud Villains!”. The specially designed video game’s description: “Join the fight against the villains of the cloud. Take on Hidden Cost, Jailor Stack, and Autonomous Zero, and prove yourself as a true Guardian of the Cloud.”

Players were welcomed to step into a two-player fighting game inspired by the style of Street Fighter, where strategy and skill are your best weapons. Game on!

We also wanted to say a word about the success of our Schrödinger cat (Quantum) swag – socks, keychains, badges – they were a huge hit, and often sparked great conversations throughout the event.

OVHcloud Speakers & Talks

Getting accepted to Devoxx France is not easy, so we were proud to be included with 8 speakers and 11 talks! We were the most represented company in terms of talks at Devoxx France 2026, and ranked in the top 3 by number of speakers 💪.

Congratulations to Benoit Masson, Fanny Bouton, Mathieu Busquet, Sébastien Ferrer, Théo Bougé, and Héla Ben Khalfallah, Stéphane Philippart & Aurélie Vache for their talks 👏. A large number of attendees joined, and the sessions were all very high quality.

Find here the topics of their talks:

“Question pour un cluster Kubernetes : Quiz sur Kubernetes & ses concepts”

🏴󠁧󠁢󠁥󠁮󠁧󠁿 “The Ultimate Kubernetes Challenge: An Interactive Trivia Game on concepts, components, usage…”

🎤 Speaker: Aurélie Vache

“Kubernetes est devenu le standard de facto pour déployer et exploiter des applications conteneurisées. Nous l’utilisons, ainsi que son ecosystème, au quotidien, mais le connaît-on si bien ?

Tout au long de ce talk, avec un mix de quiz et de démos en live, vous découvrirez (ou redécouvrirez) les concepts clés de Kubernetes (pods, secrets, services, namespaces…), les composants interne mais aussi les bonnes pratiques d’utilisation.

Un format original avec un quiz, du fun et des démos, qui conviendra aussi bien aux débutants qu’aux confirmés, afin d’apprendre, réviser et challenger vos connaissances du merveilleux monde de Kubernetes et de son écosystème, tout en s’amusant.

Soyez là ou le plus rapide pour tenter de gagner des cadeaux !”

🏴󠁧󠁢󠁥󠁮󠁧󠁿 Kubernetes has become the de facto standard for deploying and operating containerized applications. We use it, as well as its ecosystem, on a daily basis, but do we know them as well as we think we do?

With a mix of quiz and live demos, come learn and/or improve your knowledge. You will discover (or rediscover) the key concepts of Kubernetes (pods, secrets, services…), internal components but also best practices.

In this fun and dynamic talk, come compete throughout the quiz and explore the wonderful world of Kubernetes.
Icing on the cake: the first will win some swags.

🎥 Replay.

“QR Codes : suivez les points sans vous perdre !”

🏴󠁧󠁢󠁥󠁮󠁧󠁿 “QR codes: follow the dots without getting lost!“

🎤 Speaker: Benoît Masson & Sébastien Chedor (OnePoint)

“Les QR Codes, tout le monde connaît et les utilise régulièrement. Mais savez-vous vraiment comment ils fonctionnent, pourquoi c’est aussi rapide et fiable, même avec une caméra de faible qualité ou un code en partie caché ou détérioré ?

Nous vous proposons de coder ensemble un lecteur de QR Codes, avec un minimum d’outils :
* capture et analyse de la vidéo issue de la webcam pour détecter la position du code, à l’aide d’OpenCV
* extraction et décodage du contenu, avec correction d’erreur grâce à l’algorithme de Reed-Solomon.

À la fin de cette session, vous devriez être capables de décoder un QR Code à l’oeil nu 🕵️ (et un brouillon…)”.

🏴󠁧󠁢󠁥󠁮󠁧󠁿 “Everyone knows QR codes and uses them regularly. But do you really know how they work, and why they are so fast and reliable, even with a low-quality camera or a partially hidden or damaged code?

We propose coding a QR code reader together, using a minimum number of tools:
* capturing and analysing webcam video to detect the position of the code, using OpenCV
* extracting and decoding the content, with error correction using the Reed-Solomon algorithm

By the end of this session, you should be able to decode a QR code with the naked eye 🕵️— and a rough sheet of paper…”

🎥 Replay.

“Noms de domaines : la grande histoire des petites extensions”

🏴󠁧󠁢󠁥󠁮󠁧󠁿 “Domain names: the big story behind small extensions”

🎤 Speakers: Benoît Masson & Theo Bougé

“Derrière les quelques lettres qui suivent un point (.com, .fr, .ai…) se cache un univers riche de stratégies techniques, d’enjeux géopolitiques et de batailles commerciales.

À l’approche du nouveau round de l’ICANN prévu en 2026 qui va autoriser de nouvelles extensions, il est temps de revenir sur les fondations techniques du DNS, ainsi que sur les grands épisodes de cette aventure méconnue. Des TLD historiques aux extensions détournées, des dramas autour du .web aux ambitions du Web3, nous explorerons l’évolution d’un système devenu central dans les logiques de souveraineté numérique et d’innovation commerciale.

Une plongée dans les coulisses d’un Internet en perpétuelle transformation.”

🏴󠁧󠁢󠁥󠁮󠁧󠁿 “Behind the few letters that follow a dot — .com, .fr, .ai and others — lies a rich world of technical strategies, geopolitical issues and commercial battles.

As the new ICANN round planned for 2026 approaches, which will authorise new extensions, it is time to revisit the technical foundations of DNS, as well as the major episodes in this little-known story. From historic TLDs to repurposed extensions, from the drama around .web to the ambitions of Web3, we will explore the evolution of a system that has become central to digital sovereignty and commercial innovation.

A deep dive behind the scenes of an Internet in constant transformation.”

🎥 Replay.

“Informatique quantique, ce coup-ci on vous dit tout !”

🏴󠁧󠁢󠁥󠁮󠁧󠁿 “Quantum computing: this time, we tell you everything!”

🎤 Speaker: Fanny Bouton, Olivier Ezrati (Quantum Energy Initiative) & Guillaume Schurck (Alice & Bob)

“Informatique quantique pour développeurs : comprendre, coder, passer à l’échelle

L’informatique quantique sort du laboratoire et devient progressivement accessible aux développeurs via des SDK open source, des notebooks, des simulateurs et des QPU disponibles dans le cloud. En 2026, la question n’est plus « qu’est-ce que le quantique ? » mais « comment un développeur peut-il s’en emparer concrètement ? »

Nous commencerons par poser les bases essentielles pour comprendre le modèle de calcul quantique : qubit, superposition, intrication, et ce que ces concepts impliquent pour un développeur.
Nous passerons ensuite au code : écrire et exécuter des circuits quantiques, utiliser des SDK modernes, travailler dans des notebooks, tester sur simulateur puis sur de vrais QPU. Vous verrez à quoi ressemble un workflow quantique aujourd’hui.

Enfin, nous aborderons les cas d’usage concrets, illustrés par le retour d’expérience d’un grand compte : ce qui fonctionne déjà, les limites actuelles, et comment les équipes tech expérimentent le quantique de manière réaliste et industrielle.

Une session technique pensée pour les développeurs qui veulent anticiper la prochaine évolution majeure du calcul.”

🏴󠁧󠁢󠁥󠁮󠁧󠁿 “Quantum computing for developers: understand, code and scale up.
Quantum computing is moving out of the laboratory and becoming progressively accessible to developers through open source SDKs, notebooks, simulators and QPUs available in the cloud. In 2026, the question is no longer ‘What is quantum?’ but ‘How can developers make practical use of it?’

We will begin by laying out the essential foundations needed to understand the quantum computing model: qubits, superposition, entanglement, and what these concepts mean for developers.

We will then move on to code: writing and running quantum circuits, using modern SDKs, working in notebooks, testing on simulators and then on real QPUs. You will see what a quantum workflow looks like today.

Finally, we will address concrete use cases, illustrated by the experience of a large account: what already works, the current limitations, and how tech teams are experimenting with quantum computing in a realistic and industrial way.

A technical session designed for developers who want to anticipate the next major evolution in computing.”

🎥 Replay.

“Développer avec l’IA : et si c’était aussi simple qu’ajouter une librairie ?”

🏴󠁧󠁢󠁥󠁮󠁧󠁿 “Developing with AI: what if it were as simple as adding a library?”

🎤 Speakers: Mathieu Busquet & Stéphane Philippart

“Intégrer de l’intelligence artificielle (IA) dans nos développements peut nous paraître plus complexe que de les utiliser dans notre quotidien.

Dois-je apprendre un nouveau langage ou une nouvelle stack ?
Durant ce workshop nous vous proposons de vous donner tous les éléments pour intégrer l’IA sans quitter votre langage de prédilection : Java 😍. Ce sera l’occasion de découvrir les Frameworks du moments : LangChain4j, Quarkus, …

Nous vous invitons à découvrir toutes les facettes d’un chatbot avec l’IA générative (customiser un prompt, rajouter vos données (RAG), appeler des outils locaux ou distants (MCP) et créer des agents) mais aussi parce que l’IA ne se limite pas aux chatbots : faire de la transcription, créer de l’audio ou même faire un traducteur.

Et, toujours pour vous simplifier la vie, venez juste avec votre ordinateur et un navigateur Internet, on se charge du reste pour vous construire un environnement de développement aux petits oignons grâce aux CDE.

À la suite de ce talk vous repartirez avec une boîte à outils vous permettant d’intégrer simplement la puissance des modèles d’IA au sein de vos développements de tous les jours.”

🏴󠁧󠁢󠁥󠁮󠁧󠁿 “Integrating artificial intelligence into our developments can seem more complex than using it in our daily lives.

Do I need to learn a new language or a new stack?

During this workshop, we will give you all the tools you need to integrate AI without leaving your favourite language: Java 😍. It will be an opportunity to discover some of today’s key frameworks, including LangChain4j and Quarkus.

We invite you to explore all the facets of a chatbot with generative AI — customising a prompt, adding your own data with RAG, calling local or remote tools with MCP, and creating agents — but also to see that AI is not limited to chatbots: it can also be used for transcription, audio creation and even translation.

And to make your life even easier, just bring your computer and an internet browser. We will take care of the rest, building a polished development environment for you thanks to CDEs.

After this talk, you will leave with a toolkit that will allow you to integrate the power of AI models into your everyday development work.”

“Détectives de la prod : résoudre l’enquête avant le crash”

🏴󠁧󠁢󠁥󠁮󠁧󠁿 “Production detectives: solve the case before the crash”

🎤 Speaker: Sébastien Ferrer

“Saviez-vous que, derrière les coulisses de vos outils de travail, se cachent des équipes prêtes à intervenir à tout moment ?

Ces équipes, souvent discrètes mais essentielles, gèrent des dizaines de projets avec des effectifs réduits. Mais quand une alerte survient, elles doivent réagir vite. Très vite. Comment réussir à diagnostiquer et résoudre un incident en pleine production, sans perdre une précieuse seconde ?

Dans ce talk je vous emmène au cœur de l’action, où je partage notre méthodologie pour transformer chaque crise en une enquête méthodique et efficace. Nous explorerons comment des outils bien pensés, une organisation affûtée, et un soupçon d’intuition transforment la gestion d’incidents en une véritable enquête… parfois aussi palpitante qu’une partie de Cluedo.

Au programme : bonnes pratiques de troubleshooting, logging et monitoring, pour que vous repartiez avec des clés concrètes pour dompter les incidents dans vos propres projets.

Vous verrez qu’en production, chaque problème cache une histoire… à résoudre en équipe !”

🏴󠁧󠁢󠁥󠁮󠁧󠁿 “Did you know that behind the scenes of your work tools, there are teams ready to intervene at any moment?

These teams, often discreet but essential, manage dozens of projects with limited staff. But when an alert occurs, they need to react quickly. Very quickly. How can they diagnose and resolve a production incident without losing precious seconds?

In this talk, I will take you into the heart of the action, where I share our methodology for turning every crisis into a structured and efficient investigation. We will explore how well-designed tools, a well-honed organisation and a touch of intuition can transform incident management into a real investigation — sometimes as thrilling as a game of Cluedo.

On the agenda: troubleshooting best practices, logging and monitoring, so you leave with concrete keys to taming incidents in your own projects.

You will see that in production, every problem hides a story… one to solve as a team!”

🎥 Replay.

“Et si écrire du SQL redevenait cool ?”

🏴󠁧󠁢󠁥󠁮󠁧󠁿 “What if writing SQL became cool again?”

🎤 Speaker: Sébastien Ferrer

“On nous l’a répété maintes fois : “écrire du SQL dans du code source, c’est dépassé”.

Les ORMs sont partout. Ils ont facilité notre quotidien en nous permettant de manipuler nos bases de données sans nous soucier du SQL. Mais parfois, on aimerait un peu plus de contrôle, un peu plus de performance… sans pour autant revenir aux longues heures de mapping manuel et de requêtes préparées à la main.

SQLC offre une autre approche. Initialement conçu pour du Go, langage dans lequel cette technologie sera présentée dans ce talk, il permet d’écrire des requêtes SQL tout en générant du code type-safe et performant, sans ajouter de lourdeur ni de dépendances. Pas question ici de rejeter les ORMs, mais plutôt d’explorer un nouvel outil qui vient enrichir notre palette de solutions.

Dans ce talk, nous verrons comment SQLC fonctionne, dans quels cas il brille, et comment il s’intègre parfaitement dans un stack moderne. Vous aimez le SQL ? Vous voulez juste un peu plus de maîtrise sur vos requêtes ? Venez, vous risquez d’être agréablement surpris.”

🏴󠁧󠁢󠁥󠁮󠁧󠁿 “We have been told many times: ‘Writing SQL in source code is outdated.’

ORMs are everywhere. They have made our daily lives easier by allowing us to manipulate databases without worrying about SQL. But sometimes, we would like a little more control, a little more performance — without going back to long hours of manual mapping and hand-written prepared queries.

SQLC offers another approach. Initially designed for Go, the language in which this technology will be presented during the talk, it allows you to write SQL queries while generating type-safe and high-performance code, without adding heaviness or dependencies. The goal here is not to reject ORMs, but rather to explore a new tool that enriches our range of solutions.

In this talk, we will see how SQLC works, where it shines, and how it integrates perfectly into a modern stack. Do you like SQL? Do you simply want more control over your queries? Come along — you may be pleasantly surprised.”

🎥 Replay.

“🤖 Apprendre à notre IA à … apprendre 🧠”

🏴󠁧󠁢󠁥󠁮󠁧󠁿 “🤖 Teaching our AI to… learn 🧠”

🎤 Speaker: Stéphane Philippart

“RAG, MCP, tooling, function calling, agents, fine tuning, training, …
Que de termes barbares mais qui ont tous le même objectif : faire en sorte que le modèle d’intelligence artificielle que vous utilisez réponde correctement à vos questions et attentes 😅.
Et pour ça il va falloir ajouter de la connaissance, des données (privée ou publiques, …).

Durant ce talk je vous propose d’y voir un peu plus clair dans cette jungle des acronymes puis, fort de connaître les différences, vous proposer comment l’implémenter en tant que développeuses et développeurs.

Chaque approche a ses spécificités, ses avantages et ses inconvénients.
A la fin de ce talk, non seulement vous saurez choisir la bonne approche, mais aussi ajouter dans vos développements quotidiens la dose d’IA utile.”

🏴󠁧󠁢󠁥󠁮󠁧󠁿 “RAG, MCP, tooling, function calling, agents, fine tuning, training…

So many intimidating terms, but they all have the same goal: ensuring that the artificial intelligence model you use responds correctly to your questions and expectations 😅.

And to do that, you need to add knowledge and data — private, public or otherwise.

During this talk, I will help you see more clearly through this jungle of acronyms, and once you understand the differences, I will show you how to implement them as developers.

Each approach has its own specificities, advantages and disadvantages.

By the end of this talk, you will not only know how to choose the right approach, but also how to add the right dose of useful AI into your daily development work.”

🎥 Replay.

“Refactorer sans tout casser: anatomie des patterns de modernisation incrémentale”

🏴󠁧󠁢󠁥󠁮󠁧󠁿 “Refactoring without breaking everything: anatomy of incremental modernisation patterns”

🎤 Speaker: Héla Ben Khalfallah

“Cette session répond à un problème extrêmement courant mais rarement traité de façon structurée : comment moderniser un système legacy sans big bang, sans freeze de la prod, et sans multiplier les régressions. Plutôt que de parler “microservices” ou “rewrite from scratch” de manière abstraite, la session propose un playbook de modernisation incrémentale, articulé autour de patterns éprouvés : Strangler Fig, Parallel Change (Expand/Contract), Branch by Abstraction, décomposition par capacités métier / sous-domaines / transactions, et les patterns de conception (Facade, Adapter, Proxy, Mediator) utilisés comme briques concrètes de migration.

Le contenu est ancré dans la pratique : il synthétise à la fois des retours d’expérience industriels (Netflix, Khan Academy, etc.) et des travaux de recherche / rédaction. L’objectif n’est pas de présenter un catalogue de patterns, mais de montrer comment les combiner pour construire une trajectoire de migration observable, réversible et livrable en continu.

Vous repartirez avec une grille de lecture concrète pour garder des migrations observables, réversibles et compatibles avec le rythme produit.”

🏴󠁧󠁢󠁥󠁮󠁧󠁿 “This session addresses an extremely common problem that is rarely handled in a structured way: how to modernise a legacy system without a big bang, without a production freeze, and without multiplying regressions. Rather than talking abstractly about microservices or rewriting from scratch, the session offers an incremental modernisation playbook built around proven patterns: Strangler Fig, Parallel Change — Expand/Contract — Branch by Abstraction, decomposition by business capabilities, subdomains and transactions, as well as design patterns such as Facade, Adapter, Proxy and Mediator used as concrete building blocks for migration.

The content is rooted in practice: it brings together both industrial feedback from companies such as Netflix and Khan Academy, and research and written work. The goal is not to present a catalogue of patterns, but to show how they can be combined to build a migration path that is observable, reversible and continuously deliverable.

You will leave with a concrete framework for keeping migrations observable, reversible and compatible with the pace of product development.”

🎥 Replay.

📺 Devoxx France published the 232 videos (keynotes, conferences, tools in action, lunch talks & deep dives) on the Devoxx France YouTube channel.

Podcast

Devoxx France was also an opportunity for OVHcloud’s Aurélie Vache, Stéphane Philippart, and Magali De Labareyre to be interviewed in the Press space for the “Tech en Pratique” podcast.

The episodes will be available on YouTube starting in September! 🙂

Key Trends

• AI moved from hype to production
  The focus shifted toward agentic systems, RAG, observability, governance, and enterprise integration, with more emphasis on shipping useful AI than experimenting.

• Java evolved for modern AI and cloud workloads
  LangChain4j, GraalVM, native image, and JDK modernization reinforced Java’s role as a serious platform for AI-enabled enterprise systems.

• Platform engineering became a core priority
  CI/CD maturity, OpenRewrite, modernization, and developer productivity all reflected one goal: faster delivery without losing control.

• Security moved deeper into developer workflows
  Shift-left security, AppSec, authorization, Software Supply Chain Security and secure-by-design approaches gained importance, especially with AI-generated code increasing governance needs.

• Cloud & architecture focused on operational resilience
  Kubernetes, containers, observability, and scalable systems remained central, with a stronger focus on practical engineering over hype.

• Front-end discussions matured
  Accessibility, performance, reactivity, and maintainability took priority over framework wars.

• Open source and European digital sovereignty gained traction
  Open models, self-hosted tooling, privacy, and vendor independence became increasingly important themes.

• Developer experience (DX) became strategic
  Tooling, automation, terminal workflows, and reducing cognitive load were seen as key drivers of productivity and competitiveness.

Conclusion

This Devoxx France edition was a raging success for the speakers, sponsors, and attendees alike ♥️.

💬 Stay in Touch

Want to chat with us, share your thoughts, or just say hi? Here’s how to get in touch with us:

• 🟣 Discord: OVHcloud Discord server
• 🐦 X / Twitter: @OVHcloud
• 💼 LinkedIn: OVHcloud LinkedIn
• 🐙 GitHub: github.com/ovh

If you find yourself in need of shared persistent storage for applications running on OVHcloud Managed Kubernetes Service (MKS), then OVHcloud Enterprise File Storage (EFS) with Trident CSI offers you a practical way to provision and manage it.

This blog post explains how to create and connect OVHcloud EFS to your MKS cluster using Trident CSI, so you can dynamically provision persistent storage for Kubernetes workloads.

OVHcloud Enterprise File System (EFS)

EFS is a high-performance, fully managed file storage solution powered by NetApp ONTAP in an active-active architecture. It is designed for enterprise workloads requiring high availability, predictable performance, and seamless integration with cloud-native environments.

The service is available in multiple regions, including Roubaix, Gravelines, Strasbourg, Limbourg, and Beauharnois, with a strong SLA of 99.99% uptime. Storage capacity ranges from 50 GB up to 29 TB.

EFS delivers guaranteed performance with 4,000 IOPS and 64 MB/s throughput per TiB, scaling linearly with volume size thanks to NVMe SSD infrastructure.

Built for modern infrastructures, EFS integrates natively with Kubernetes via Trident CSI (compatible with MKS) and supports ReadWriteMany (RWX) access. It operates within a single availability zone (1AZ) and provides low-latency NFS storage over OVHcloud’s secure vRack network, ensuring strong security and compliance.

NetApp Trident CSI

Trident is an open-source, fully supported storage orchestration project maintained by NetApp. It is designed to help Kubernetes applications consume persistent storage using standard interfaces such as the Container Storage Interface (CSI).

Trident runs directly inside Kubernetes clusters as a set of Pods and enables dynamic provisioning and management of storage for containerized workloads. It allows applications to easily access persistent storage from NetApp’s ecosystem, including ONTAP systems (like the OVHcloud EFS).

Let’s do it!

EFS creation

We already have a MKS cluster, in GRA11 region, running inside a private network and a subnet, with a gateway.
We also already have a vRack and our Public Cloud Project attached to this vRack.
So in this blog post we will only create a new EFS in eu-west-rbx region, attached to a vRackServices, inside the same subnet that our existing MKS cluster.

Here you can see the architecture of all the services:

⚠️ EFS and MKS regions may differ; be aware that latency between different regions may impact your storage workloads performance. It’s highly recommended to keep your storage and compute as close as possible.

We will deploy the EFS in eu-west-rbx instead of in eu-west-gra region to show you that it is possible.

To deploy the EFS, we will use the Terraform OVHcloud EFS module.

The module we will use can deploy all the components necessary to use EFS with a MKS cluster (like you can see in the schema).

But in this blog post we will assume that we already deployed:

• a vRack
• a Private Network
• a Private Subnet
• a Gateway
• a MKS cluster

So using the Terraform module we will fill the existing resources information and ask Terraform to create:

• an OAuth2 credential
• an IAM policy
• an EFS
• a vRack Services

Let’s deploy our components with Terraform!

Create a provider.tf file and fill it with the information:

terraform {
  required_providers {
    ovh = {
      source  = "ovh/ovh"
      version = ">= 2.12.0"
    }
    null = {
      source  = "hashicorp/null"
      version = ">= 3.0.0"
    }
  }

  required_version = ">= 1.7.0"
}

provider "ovh" {
}

If you don’t define the provider information inside this file, as was shown in this example, you can instead set the environment variables with your credentials:

# OVHcloud provider needed keys
export OVH_ENDPOINT="ovh-eu"
export OVH_APPLICATION_KEY="xxx"
export OVH_APPLICATION_SECRET="xxx"
export OVH_CONSUMER_KEY="xxx"
export OVH_CLOUD_PROJECT_SERVICE="xxx"

Create a variable.tf.template file and fill it with these information:

# Existing services
variable "service_name" {
  default = "$OVH_CLOUD_PROJECT_SERVICE"
}

variable "vrack_id" {
  default = "pn-1234567" #ID of your existing vRack
}

variable "vlan_id" {
  default = "666" #ID of your VLAN
}

variable "private_network_id" {
  default = "d111cb65-1234-5678-9012-dac2e93b8944" #ID of your private network
}

variable "private_subnet_id" {
  default = "d8dc2469-1234-5678-9012-1f86551d3466" #ID of your subnet
}

variable "vrackservices_subnet_service_range_cidr" {
  default = "192.168.168.248/29" #CIDR of your private network
}

variable "private_subnet_cidr" {
  default = "192.168.168.0/24" #CIDR of your subnet
} 

variable "mks_region" {
  default = "GRA11" #Region of your existing MKS cluster
}

variable "mks_cluster_id" {
  default = "7c3e1e6e-1234-5678-9012-4fb5a5b145e7" #ID of your existing MKS cluster
}

# Services to create

variable "oauth2_client_name" {
  default = "efs-trident-client-example"
}

variable "oauth2_client_description" {
  default = "OAuth2 client for EFS Trident integration"
}

variable "iam_policy_name" {
  default = "efs-trident-policy-example"
}

variable "iam_policy_description" {
  default = "IAM policy for EFS Trident access"
}

variable "vrackservices_attach_to_efs" {
  description = "Whether to attach the EFS service endpoint to vRack Services. Set to false before destroying."
  type        = bool
  default     = true
}

variable "efs_region" {
  default = "eu-west-rbx"
}

variable "efs_name" {
  default = "my-efs-storage"
}

variable "efs_plan" {
  default = "enterprise-file-storage-premium-1tb"
}

⚠️ In the file, replace the IDs, CIDR & MKS region with your existing resources information.

Replace the value of the OVH_CLOUD_PROJECT_SERVICE environment variable in the variables.tf file:

envsubst < variables.tf.template > variables.tf

Create a efs.tf file and fill it with the information:

module "ovh_efs_trident" {
  source = "ovh/efs/ovh//modules/efs-trident"

  # OVH region for EFS and vRack Services
  region = var.efs_region

  # Public Cloud region for MKS and private network
  public_cloud_region = var.mks_region

  # VLAN ID must be the same for vRack Services and Public Cloud private network
  vlan_id = var.vlan_id

  # Set to false before destroying to detach endpoint first
  vrackservices_attach_to_efs = var.vrackservices_attach_to_efs

  # EFS creation
  storage_efs_name      = var.efs_name
  storage_efs_plan_code = var.efs_plan

  # --- vRack ---
  create_vrack       = false
  vrack_service_name = var.vrack_id

  # --- Cloud Project ---
  create_cloud_project        = false
  cloud_project_id            = var.service_name
  bind_vrack_to_cloud_project = false # Set to false if already bound

  # --- Private Network ---
  create_private_network      = false
  private_network_id = var.private_network_id

  # --- Private Subnet ---
  create_private_subnet      = false
  private_subnet_id = var.private_subnet_id

  # --- Gateway ---
  create_gateway = false  # Set to false only if existing network has gateway

  # --- MKS Cluster ---
  create_mks_cluster = false
  mks_cluster_id     = var.mks_cluster_id # mks-priv-gra11
  create_node_pool   = false # Set to false if using existing node pool

  # OAuth2 and IAM
  oauth2_client_name        = var.oauth2_client_name
  oauth2_client_description = var.oauth2_client_description
  iam_policy_name           = var.iam_policy_name
  iam_policy_description    = var.iam_policy_description

  # Network (shared between vRack Services and Public Cloud)
  private_network_subnet_cidr             = var.private_subnet_cidr
  vrackservices_subnet_service_range_cidr = var.vrackservices_subnet_service_range_cidr # EFS gets IPs here
}

Create an output.tf file with the following content:

output "client_id" {
    value = module.ovh_efs_trident.client_id
}

output "client_secret" {
    value = module.ovh_efs_trident.client_secret
    sensitive = true
}

output "efs_id" {
  value       = module.ovh_efs_trident.efs_id
}

The Terraform configuration is ready. Let’s init it:

terraform init

The output should be like this:

$ terraform init

Initializing the backend...
Initializing modules...
Initializing provider plugins...
- Reusing previous version of hashicorp/null from the dependency lock file
- Reusing previous version of ovh/ovh from the dependency lock file
- Using previously-installed hashicorp/null v3.2.4
- Using previously-installed ovh/ovh v2.13.1

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

Apply it:

terraform apply

The output should be like this:

$ terraform apply

module.ovh_efs_trident.data.ovh_me.my_account: Reading...
module.ovh_efs_trident.data.ovh_cloud_project_kube.existing[0]: Reading...
module.ovh_efs_trident.data.ovh_cloud_project.existing[0]: Reading...
module.ovh_efs_trident.data.ovh_me.my_account: Read complete after 1s [id=xx12345-ovh]
module.ovh_efs_trident.data.ovh_cloud_project.existing[0]: Read complete after 0s
module.ovh_efs_trident.data.ovh_order_cart.cart: Reading...
module.ovh_efs_trident.data.ovh_order_cart.cart: Read complete after 0s [id=d582ab7c-1234-5678-9012-4a6e702ea4c5]
module.ovh_efs_trident.data.ovh_cloud_project_kube.existing[0]: Read complete after 5s [id=7c3e1e6e-1234-5678-9012-4fb5a5b145e7]

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # module.ovh_efs_trident.null_resource.config_validation will be created
  + resource "null_resource" "config_validation" {
      + id = (known after apply)
    }

  # module.ovh_efs_trident.ovh_iam_policy.iam_policy will be created
  + resource "ovh_iam_policy" "iam_policy" {
      + allow       = [
          + "storageNetApp:apiovh:get",
          + "storageNetApp:apiovh:serviceInfos/get",
          + "storageNetApp:apiovh:share/accessPath/get",
          + "storageNetApp:apiovh:share/acl/create",
          + "storageNetApp:apiovh:share/acl/delete",
          + "storageNetApp:apiovh:share/acl/get",
          + "storageNetApp:apiovh:share/create",
          + "storageNetApp:apiovh:share/delete",
          + "storageNetApp:apiovh:share/edit",
          + "storageNetApp:apiovh:share/extend",
          + "storageNetApp:apiovh:share/get",
          + "storageNetApp:apiovh:share/revertToSnapshot",
          + "storageNetApp:apiovh:share/snapshot/create",
          + "storageNetApp:apiovh:share/snapshot/delete",
          + "storageNetApp:apiovh:share/snapshot/edit",
          + "storageNetApp:apiovh:share/snapshot/get",
        ]
      + created_at  = (known after apply)
      + description = "IAM policy for EFS Trident access"
      + id          = (known after apply)
      + identities  = (known after apply)
      + name        = "efs-trident-policy-example"
      + owner       = (known after apply)
      + read_only   = (known after apply)
      + resources   = (known after apply)
      + updated_at  = (known after apply)
    }

  # module.ovh_efs_trident.ovh_me_api_oauth2_client.api_oauth2_client will be created
  + resource "ovh_me_api_oauth2_client" "api_oauth2_client" {
      + client_id     = (known after apply)
      + client_secret = (sensitive value)
      + description   = "OAuth2 client for EFS Trident integration"
      + flow          = "CLIENT_CREDENTIALS"
      + id            = (known after apply)
      + identity      = (known after apply)
      + name          = "efs-trident-client-example"
    }

  # module.ovh_efs_trident.ovh_storage_efs.efs[0] will be created
  + resource "ovh_storage_efs" "efs" {
      + created_at        = (known after apply)
      + iam               = (known after apply)
      + id                = (known after apply)
      + name              = "my-efs-storage"
      + order             = (known after apply)
      + ovh_subsidiary    = "FR"
      + performance_level = (known after apply)
      + plan              = [
          + {
              + configuration = [
                  + {
                      + label = "region"
                      + value = "eu-west-rbx"
                    },
                  + {
                      + label = "network"
                      + value = "vrack"
                    },
                ]
              + duration      = "P1M"
              + plan_code     = "enterprise-file-storage-premium-1tb"
              + pricing_mode  = "default"
            },
        ]
      + product           = (known after apply)
      + quota             = (known after apply)
      + region            = (known after apply)
      + service_name      = (known after apply)
      + status            = (known after apply)
    }

  # module.ovh_efs_trident.ovh_vrack_vrackservices.vrack-vrackservices-binding[0] will be created
  + resource "ovh_vrack_vrackservices" "vrack-vrackservices-binding" {
      + id             = (known after apply)
      + service_name   = "pn-1234567"
      + vrack_services = (known after apply)
    }

  # module.ovh_efs_trident.ovh_vrackservices.vrackservices[0] will be created
  + resource "ovh_vrackservices" "vrackservices" {
      + checksum        = (known after apply)
      + created_at      = (known after apply)
      + current_state   = (known after apply)
      + current_tasks   = (known after apply)
      + iam             = (known after apply)
      + id              = (known after apply)
      + order           = (known after apply)
      + ovh_subsidiary  = "FR"
      + plan            = [
          + {
              + configuration = [
                  + {
                      + label = "region_name"
                      + value = "eu-west-rbx"
                    },
                ]
              + duration      = "P1M"
              + plan_code     = "vrack-services"
              + pricing_mode  = "default"
            },
        ]
      + resource_status = (known after apply)
      + target_spec     = {
          + subnets = [
              + {
                  + cidr              = "192.168.168.0/24"
                  + service_endpoints = [
                      + {
                          + managed_service_urn = (known after apply)
                        },
                    ]
                  + service_range     = {
                      + cidr = "192.168.168.248/29"
                    }
                  + vlan              = 666
                    # (1 unchanged attribute hidden)
                },
            ]
        }
      + updated_at      = (known after apply)
    }

Plan: 6 to add, 0 to change, 0 to destroy.

Changes to Outputs:
  + client_id     = (known after apply)
  + client_secret = (sensitive value)
  + efs_id        = (known after apply)

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

module.ovh_efs_trident.null_resource.config_validation: Creating...
module.ovh_efs_trident.null_resource.config_validation: Creation complete after 0s [id=8553589333890826101]
module.ovh_efs_trident.ovh_me_api_oauth2_client.api_oauth2_client: Creating...
module.ovh_efs_trident.ovh_storage_efs.efs[0]: Creating...
module.ovh_efs_trident.ovh_me_api_oauth2_client.api_oauth2_client: Creation complete after 0s [id=EU.xxxxxxxxxxxxx]
module.ovh_efs_trident.ovh_storage_efs.efs[0]: Still creating... [00m10s elapsed]
module.ovh_efs_trident.ovh_storage_efs.efs[0]: Still creating... [00m20s elapsed]
module.ovh_efs_trident.ovh_storage_efs.efs[0]: Still creating... [00m30s elapsed]
...
module.ovh_efs_trident.ovh_storage_efs.efs[0]: Still creating... [03m40s elapsed]
module.ovh_efs_trident.ovh_storage_efs.efs[0]: Still creating... [03m50s elapsed]
module.ovh_efs_trident.ovh_storage_efs.efs[0]: Creation complete after 3m52s [id=c2d759de-cd63-4e28-aaab-a7599aad2ca8]
module.ovh_efs_trident.ovh_vrackservices.vrackservices[0]: Creating...
module.ovh_efs_trident.ovh_iam_policy.iam_policy: Creating...
module.ovh_efs_trident.ovh_iam_policy.iam_policy: Creation complete after 0s [id=a434d1a4-1234-5678-9012-cf54251eee52]
module.ovh_efs_trident.ovh_vrackservices.vrackservices[0]: Still creating... [00m10s elapsed]
module.ovh_efs_trident.ovh_vrackservices.vrackservices[0]: Still creating... [00m20s elapsed]
...
module.ovh_efs_trident.ovh_vrackservices.vrackservices[0]: Still creating... [01m20s elapsed]
module.ovh_efs_trident.ovh_vrackservices.vrackservices[0]: Creation complete after 1m30s [id=vrs-a00-b11-c22-d33]
module.ovh_efs_trident.ovh_vrack_vrackservices.vrack-vrackservices-binding[0]: Creating...
module.ovh_efs_trident.ovh_vrack_vrackservices.vrack-vrackservices-binding[0]: Still creating... [00m10s elapsed]
module.ovh_efs_trident.ovh_vrack_vrackservices.vrack-vrackservices-binding[0]: Still creating... [00m20s elapsed]
...
module.ovh_efs_trident.ovh_vrack_vrackservices.vrack-vrackservices-binding[0]: Still creating... [01m40s elapsed]
module.ovh_efs_trident.ovh_vrack_vrackservices.vrack-vrackservices-binding[0]: Creation complete after 1m43s [id=vrack_pn-1234567-vrackServices_vrs-a00-b11-c22-d33]

Apply complete! Resources: 6 added, 0 changed, 0 destroyed.

Outputs:

client_id = "EU.xxxxxxxxxxxxx"
client_secret = <sensitive>
efs_id = "c2d759de-cd63-4e28-aaab-a7599aad2ca8"

Save the OAuth2 credentials in environment variables:

export EFS_CLIENT_ID=$(terraform output -raw client_id)
export EFS_CLIENT_SECRET=$(terraform output -raw client_secret)

Trident CSI Installation

Install the Trident operator in your MKS cluster:

helm repo add netapp-trident https://netapp.github.io/trident-helm-chart

helm install trident-operator netapp-trident/trident-operator \
  --version 100.2502.1 \
  --create-namespace \
  --namespace trident \
  --set tridentSilenceAutosupport=true \
  --set operatorImage="ovhcom/trident-operator:25.02.1-linux-amd64" \
  --set tridentImage="ovhcom/trident:25.02.1-linux-amd64"

You should have a result like this:

$ helm install trident-operator netapp-trident/trident-operator \
  --version 100.2502.1 \
  --create-namespace \
  --namespace trident \
  --set tridentSilenceAutosupport=true \
  --set operatorImage="ovhcom/trident-operator:25.02.1-linux-amd64" \
  --set tridentImage="ovhcom/trident:25.02.1-linux-amd64"

NAME: trident-operator
LAST DEPLOYED: Tue Apr 28 14:01:19 2026
NAMESPACE: trident
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
Thank you for installing trident-operator, which will deploy and manage NetApp's Trident CSI
storage provisioner for Kubernetes.

Your release is named 'trident-operator' and is installed into the 'trident' namespace.
Please note that there must be only one instance of Trident (and trident-operator) in a Kubernetes cluster.

To configure Trident to manage storage resources, you will need a copy of tridentctl, which is
available in pre-packaged Trident releases.  You may find all Trident releases and source code
online at https://github.com/NetApp/trident.

To learn more about the release, try:

  $ helm status trident-operator
  $ helm get all trident-operator

Once the installation is complete, verify that all Trident pods are in Running state in the trident namespace before proceeding:

$ kubectl get pods -n trident

NAME                                  READY   STATUS    RESTARTS      AGE
trident-controller-5bf6c8d6f6-g95jq   6/6     Running   0             119s
trident-node-linux-4xtjr              2/2     Running   1 (82s ago)   119s
trident-node-linux-6w5ff              2/2     Running   1 (82s ago)   119s
trident-node-linux-r7hxp              2/2     Running   0             119s
trident-operator-859f59c58b-2z2ts     1/1     Running   0             2m31s

Trident Backend Creation

The Trident backend connects NetApp Trident to the OVHcloud EFS service using the IAM credentials previously created.

1. Secret Creation

Create a Kubernetes Secret containing the connection information that allows Trident to access the OVHcloud API. Create a trident-secret.yaml.template file with the following content:

apiVersion: v1
kind: Secret
metadata:
  name: ovh-efs-secret
type: Opaque
stringData:
  clientID: "$EFS_CLIENT_ID"         # your clientId
  clientSecret: "$EFS_CLIENT_SECRET" # your clientSecret

Replace the clientID and clientSecret values by the OAuth2 client we created with Terraform:

envsubst < trident-secret.yaml.template > trident-secret.yaml

Apply the secret in your cluster:

kubectl apply -f trident-secret.yaml -n trident

Check that the secret has been correctly created:

$ kubectl get secret ovh-efs-secret -n trident

NAME             TYPE     DATA   AGE
ovh-efs-secret   Opaque   2      3s

2. Trident Backend Creation

Create your backend with the command below:

cat <<EOF | kubectl create -n trident -f -
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: ovh-efs-rbx
spec:
  version: 1
  backendName: backend-ovh-efs
  defaults:
    exportRule: "192.168.168.0/24"    # CIDR of your network for NFS ACLs
  storageDriverName: ovh-efs
  clientLocation: ovh-eu
  location: eu-west-rbx         # Location of your EFS service
  serviceLevel: premium
  nfsMountOptions: rw,hard,rsize=65536,wsize=65536,nfsvers=3,tcp
  credentials:
    name: ovh-efs-secret
  volumeCreateTimeout: "60" 
EOF

⚠️ The ovh-efs storage driver must be used. Replace exportRule, location, and other parameters with values matching your environment.

Verify that the backend has been created correctly with the command below:

$ kubectl get TridentBackendConfig -n trident

NAME          BACKEND NAME      BACKEND UUID                           PHASE   STATUS
ovh-efs-rbx   backend-ovh-efs   ace12d67-70ea-44e1-abd8-20d016f7f030   Bound   Success

Use EFS in your MKS cluster

This section describes how to expose Enterprise File Storage to Kubernetes workloads using Trident.

1. StorageClass

In a sc_efs.yaml file, define a StorageClass to enable dynamic provisioning via the Trident CSI driver:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ovh-efs-premium
provisioner: csi.trident.netapp.io
parameters:
  backendType: "ovh-efs"
  fsType: "nfs"
allowVolumeExpansion: true

Apply the StorageClass:

kubectl apply -f sc_efs.yaml

Check that the StorageClass has been created:

$ kubectl get sc ovh-efs-premium

NAME              PROVISIONER             RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
ovh-efs-premium   csi.trident.netapp.io   Delete          Immediate           true                   3h13m

This StorageClass allows volumes to be provisioned on demand and expanded dynamically.

2. Volume Creation (PVC)

Create a PersistentVolumeClaim with ReadWriteMany (RWX) access mode. Create a pvc_efs.yaml file with this content:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: premium-pvc-efs
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 100Gi
  storageClassName: ovh-efs-premium

Apply it:

kubectl apply -f pvc_efs.yaml

Verify that the PVC has been created with the command below:

kubectl get pvc premium-pvc-efs

At this point, the EFS is creating a volume, attach the correct ACL to it and mount it in the PVC

After a little time, the output should show the PVC in Bound state:

$ kubectl get pvc

NAME              STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS      VOLUMEATTRIBUTESCLASS   AGE
premium-pvc-efs   Bound    pvc-faca364d-ad76-44ec-9bc9-959c0d33c515   100Gi      RWX            ovh-efs-premium   <unset>                 3m43s

The volume has been created through the PVC and you can now mount it in a Pod 🎉.

Conclusion

In this blog, we’ve explained how to create an EFS and use it in a MKS cluster through Trident CSI. This will give you a flexible, production-ready approach to persistent shared storage in Kubernetes.

We recommend you also take a look at our Cloud Roadmap & Changelog for an overview of all the coming features for OVHcloud Public Cloud products.

A newly disclosed Linux kernel zero-day, CVE-2026-31431, “Copy.Fail”, is one of the most serious privilege-escalation vulnerabilities in recent years.

Discovered by Theori and publicly disclosed on April 29, 2026, Copy.Fail is a Linux kernel zero-day that roots every distribution since 2017. Unlike many local privilege-escalation flaws that depend on race conditions, kernel address leaks, or distribution-specific behavior, Copy.Fail is alarmingly reliable: it works consistently across mainstream Linux distributions with only a standard user account.

Why the CVE-2026-31431 is dangerous?

Copy.Fail abuses a logic flaw in the Linux kernel’s algif_aead crypto module, introduced through a 2017 optimization. By manipulating the kernel’s AF_ALG crypto interface, an attacker can write controlled data into the Linux page cache (the in-memory representation of trusted system binaries).

This allows attackers to temporarily hijack binaries like /usr/bin/su without modifying the file on disk.

In practical terms:

• A normal user can become root
• A compromised container can escape to the host
• A malicious CI job can root its runner
• Shared infrastructure becomes vulnerable across tenants
• Disk forensics may show no file tampering because only RAM is altered

This makes Copy.Fail especially dangerous for:

• Kubernetes clusters
• CI/CD systems
• Shared development environments
• Cloud notebook platforms
• Multi-tenant container infrastructure

How to patch it easily in your MKS clusters?

OVHcloud is preparing patched MKS versions including the upstream kernel fix. Patched versions are expected to be available 30 April 2026, at 16:00 UTC+2.

While waiting for the next MKS release, here is a DaemonSet manifest that you can apply in your MKS clusters in order to mitigate the vulnerability.

Create a patch-copy-fail-cve file with the following content:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: patch-copy-fail-cve
  labels:
    app: patch-copy-fail-cve
  namespace: default
spec:
  selector:
    matchLabels:
      app: patch-copy-fail-cve
  updateStrategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 0
      maxUnavailable: 100%
  template:
    metadata:
      labels:
        app: patch-copy-fail-cve
    spec:
      hostPID: true
      priorityClassName: system-node-critical
      volumes:
        - name: root-mount
          hostPath:
            path: /
            type: Directory
      initContainers:
        - image: mks.kubernatine.ovh/docker.io/library/busybox:1.36.1
          name: patch-copy-fail-cve
          command: ["/bin/bash", "-c"]
          args:
            - |
              tee /etc/modprobe.d/disable-algif-aead.conf <<<'install algif_aead /bin/false'
              rmmod algif_aead 2>/dev/null
              update-initramfs -u
          securityContext:
            privileged: true
            runAsUser: 0
          volumeMounts:
            - name: root-mount
              mountPath: /
      containers:
        - image: "mks.kubernatine.ovh/registry.k8s.io/pause:3.10.1"
          name: pause     

Apply it:

kubectl apply -f patch-copy-fail-cve.yaml

⚠️ This mitigation has been tested on OVHcloud internal test clusters. Applying it to your own service remains under your responsibility.

If the vulnerability has already been exploited on your cluster, this mitigation will not remediate any pre-existing compromise.
The recommended remediation remains the official security release, which will be made available as soon as possible.

Read more about the mitigation: https://github.com/rootsecdev/cve_2026_31431#mitigation

Aurélie Vache and Rémy Vandepoel attended alongside 26 other OVHcloud employees. In this blog, they share their thoughts about this second KubeCon set in the land of tulips.

KubeCon Europe 2026: the maturity milestone

Back from Amsterdam, the buzz of the RAI halls still echoes in our ears. This 2026 edition of KubeCon + CloudNativeCon Europe wasn’t just another Kubernetes conference. It marked a turning point for this event: the point of maturity. And this is evident just by looking at the numbers: 13,500 attendees for this edition! The largest attendance ever recorded!

While previous years were about exploration and expansion, 2026 was the year of massive industrialization, with one non-negotiable pre-requirement: digital sovereignty.

Key figures from the 2026 edition:

• 13,500+ attendees (46% first-time attendees)
• 100 countries represented
• 3,474 unique organizations/companies
• 891 sessions
• 230 projects in the CNCF landscape with 19.9 million contributors

CNCF Contributors by Geography (Last 12 Months)

• Europe: 38.8% of contributions (ahead of the United States)
• United States: 36.29%
• Germany: 9.82% (leading in Europe)
• France: 4.68%
• Switzerland: 2.49%
• Strong signals for digital sovereignty, a key theme of this year’s keynotes 💪

Colocated events

KubeCon + CloudNativeCon Europe 2026 traditionally kicks off with a full day dedicated to co-located events. This year was no exception, with an impressive lineup of 16 events, including well-known favorites such as ArgoCon, BackstageCon, CiliumCon, Platform Engineering Day, Kubernetes on Edge Day, and Observability Day.

Among the newcomer events, Open Sovereign Cloud Day was a stand out, as it highlighted the growing importance of cloud sovereignty in Europe.

During CiliumCon, we were proud to see the spotlight on our MKS Standard offer 🚀.

OVHcloud Presence

OVHcloud had a strong presence at the event, with two different booths serving two different purposes.

One was located in the Activation Zone, designed as an interactive space to engage with attendees through a video game “Gaming Camp: Beat Cloud Villains!”, described as “Join the fight against the villains of the cloud. Take on Hidden Cost, Jailor Stack, and Autonomous Zero, and prove yourself as a true Guardian of the Cloud.”

Players were welcomed to step into a two-player fighting game inspired by the style of Street Fighter, where strategy and skill are your best weapons. Winners won exclusive t-shirts.

The second booth had a more corporate focus, highlighting OVHcloud’s broader portfolio, strategic positioning, and enterprise offerings. It provided a space for deeper conversations around demos, use cases, and cloud strategies.

The opportunity was too good to pass up, so we took the chance to interview key players in the ecosystem, as well as customers of our solutions.

We conducted five interviews and had many discussions, and we can’t wait to share them with you soon!

Here’s a sneak peek featuring Sudeep Goswami, CEO of Traefik Labs:

These interviews will soon be available on YouTube, so stay tuned!

Aurélie Vache’s talk

Getting accepted to KubeCon is not easy, and Aurélie, our Developer Advocate and CNCF Ambassador, rose to the challenge by once again presenting a new talk.

“The Ultimate Kubernetes Challenge: An Interactive Trivia Game”:

“Kubernetes has become the de facto standard for deploying and operating containerized applications. We use it, as well as its ecosystem, on a daily basis, but do we know them as well as we think we do?

With a mix of quiz and live demos, come learn and/or improve your knowledge. You will discover (or rediscover) the key concepts of Kubernetes (pods, secrets, services…), internal components but also best practices.

In this fun and dynamic talk, come compete throughout the quiz and explore the wonderful world of Kubernetes.

Icing on the cake: the first will win some swags.“

During this talk, attendees tested their Kubernetes knowledge through an interactive quiz, with results presented via illustrated slides and live, hands-on demos.

Giving a talk at 5 p.m., during the final session of the second day, was an ambitious way to finish up. But thanks to the interactive format of her talk, attendees were able to enjoy testing their knowledge while discovering tips about Kubernetes and its concepts and features.

Three OVHcloud MKS clusters were created especially for the occasion, one with 3 nodes, one with zero nodes, and one with 3 nodes across 3 Availability Zones:

Watch the talk here:

Keynotes: Toward “Agent-Based” and Autonomous AI

Plenary sessions at the event were dominated by a convergence of Kubernetes and Artificial Intelligence. This term, already ubiquitous in tech news, was bound to be a major focus here. Jonathan Bryce, the Executive Director of Cloud & Infrastructure at the Linux Foundation and an iconic figure in the ecosystem, made a strong point by reminding the audience that while Kubernetes is everywhere (82% adoption rate), AI in production remains a major challenge.

In November, during the latest KubeCon + CoudNativeCon NA at Atlanta, the CNCF launched the “Certified Kubernetes AI Conformance Program to Standardize AI Workloads on Kubernetes“.  5 months later, several companies including the OVHcloud Managed Kubernetes Services (MKS) platform, succeeded this new program with their own certified Kubernetes AI platform.

During the keynotes we even saw a real plane!

And to top it off, seeing Michelin present the Top End User Award to SNCF was a real highlight for us. Cocoricoooo! 🇫🇷

Key Trends

Find below the most frequently discussed technical pillars that will remain prominent in the coming months and years:

* Agent-based AI: The focus is shifting from training to inference. The announcement of Dapr Agents 1.0 shows that Kubernetes will now orchestrate agents capable of making real-time decisions on the infrastructure.

* GPU Standardization (DRA): Thanks to NVIDIA’s widespread adoption of Dynamic Resource Allocation (DRA) drivers, GPU scheduling is becoming as simple and granular as CPU scheduling. A boon for cost optimization.

* Sovereignty: Sovereignty is no longer a legal concept; it is an architecture. We have seen a rise in encryption tools for data in transit and at rest (Confidential Computing) natively integrated into CNIs such as Cilium.

* FinOps 2.0: With 67% of AI compute dedicated to inference by the end of 2026, precise monitoring of GPU consumption via projects like Kepler has become essential for the economic viability of projects.

The Gateway API is becoming the standard

As we announced in our blog post “Moving Beyond Ingress: Why should OVHcloud Managed Kubernetes Service (MKS) users start looking at the Gateway API?”, the ingress-nginx controller, the most widely used ingress controller, has now been archived.

Now, after 8 years of development, 275 released versions, and nearly 20k GitHub stars, the maintainers of the Kubernetes Gateway API introduced ingress2gateway v1.0, a tool designed to simplify migration. It automatically converts Ingress resources including annotations into Gateway API resources. The recommended approach remains pragmatic: first migrate the controller while keeping existing Ingress objects, then gradually transition to the Gateway API. Attempting a full migration in a single step is considered risky and unnecessary.

Additionally, Gateway API version 1.5 represents a major milestone: five features have moved from experimental status to the Standard channel in a single release.

Amongst them:

• ListenerSet: delegates TLS listener management outside of the Gateway 
• TLSRoute: SNI-based routing in either termination or passthrough mode
• Client certificate validation for mTLS at the ingress layer
• Native CORS filter for HTTPRoute

The Kubernetes Gateway API is now establishing itself as much more than just a successor to Ingress: it is evolving into Kubernetes’ unified network control plane.

Favorite talk

As usual, Aurélie wasn’t able to attend many talks, but among the 2-3 she did see, there was one that really had a “wow” effect on her:

« An immersive and visual journey into kubernetes networking ».

Benoit, a DevSecOps engineer at Feesh in Switzerland with extensive expertise in Kubernetes networking, created a video game using Godot with four levels: “pod-to-pod basics”, “pod-to-pod advanced”, “service mesh sidecar”, and “service mesh with ambient mode”.

Across these four levels, he explains Kubernetes networking in a vanilla setup, then with Cilium and Istio, all from the perspective of a TCP packet, represented as a fish.

Networking and I don’t exactly get along, and I’ll admit I’ve always struggled with it. Even now, although I’ve had no choice but to work with Kubernetes and service mesh, I still find it challenging. But seeing the fish swim from frontend to backend, enter a building underwater (the node), interact with an eBPF program… it really makes things more visual and intuitive.

On Thursday morning, after the keynote, the room with 2000 seats was packed!

Explaining networking by building a 3D game from scratch specifically for the occasion: hats off to you!

Benoit had an issue on stage, because he had built the game in 4K and it didn’t display properly on the projection screen. Luckily, about 30 seconds before showtime, the production team and he managed to fix it. He went on stage without showing any of that stress 💪.

Replay:

KubeCon in 45 seconds

To keep memories of these 3-4 amazing days, we created a “KubeCon Europe 2026 in 45 seconds movie:

Conclusion

KubeCon Amsterdam proved once again that the strength of open source lies in its community.

From the halls of the RAI to the technical sessions, the excitement was palpable. We’re leaving with our heads full of ideas, but above all with the certainty that collaboration remains the key to solving the complex challenges of modern IT. This was particularly evident in the packed conference rooms and the crowded aisles of the exhibition hall.

One thing is certain: the future of Cloud Native is being written together, and we at OVHcloud look forward to contributing to it with you by helping you get the most out of Kubernetes through our managed platform. Because we’re convinced that for businesses in 2026, the challenge will no longer be how to run Kubernetes, but how to use it to innovate faster and better than the competition.

Several months ago, we released the Beta version of the OVHcloud Secret Manager and we guided you how to manage your secrets thanks to the existing External Secret Operator (ESO) Hashicorp Vault provider.

As our Secret Manager is now in General Availability, our teams worked on the development of an OVHcloud ESO Provider now available in the ESO v2.3.0 new release 🎉.

In this blog post, you will learn how to create a new secret in the OVHcloud Secret Manager and how to manage it within your Kubernetes clusters through the OVHcloud ESO provider.

External Secrets Operator (ESO)

The External Secrets Operator (ESO), a CNCF sanbox project since 2022, is a Kubernetes operator that integrates external secret management systems.

The operator reads the information from an external APIs and automatically injects the values into a Kubernetes Secret. If the secret changes in the external API, the operator updates the secret in the Kubernetes cluster.

The ESO connects to an external Secret Manager, such as OVHcloud, Vault, AWS, or GCP, via a provider configured in a (Cluster)SecretStore. An ExternalSecret resource then specifies which secrets to retrieve. ESO fetches those values and creates a corresponding Kubernetes Secret within the cluster.

For more details, read the ESO official documentation.

Prerequisites

To be able to use the ESO OVHcloud provider, you need to follow some prerequisites:

• Have an OVHcloud account
• Created an OKMS domain (“305db938-331f-454d-83a7-3a0a29291661” for example in this blog post)
• Created an IAM local user (“secretmanager-305db938-331f-454d-83a7-3a0a29291661” for example in this blog post)
• Installed the OVHcloud CLI
• Have a Kubernetes cluster

The ESO OVH provider supports both token and mTLS authentication. In this blog post, we will use the token authentication mode. Please follow the OVHcloud ESO provider guide if you wish to use mTLS authentication mode.

Generate a PAT token (For token authentication only)

The ESO (Cluster)SecretStore needs the permission to fetch secrets from Secret Manager.

If you want to use token autentication, you’ll need a token (PAT). You can use the ovhcloud CLI to do that:

PAT_TOKEN=$(ovhcloud iam user token create <iam-local-user-name> --name pat-<iam-local-user-name> --description "PAT secret manager for domain <okms-id>" -o json  | jq .details.token |  tr -d '"')

echo $PAT_TOKEN
<your-token>

You should have a result like this:

$ PAT_TOKEN=$(ovhcloud iam user token create secretmanager-305db938-331f-454d-83a7-3a0a29291661 --name pat-secretmanager-305db938-331f-454d-83a7-3a0a29291661 --description "PAT secret manager for domain 305db938-331f-454d-83a7-3a0a29291661" -o json  | jq .details.token |  tr -d '"')
2026/04/07 14:07:45 Final parameters:
{
 "description": "PAT secret manager for domain 305db938-331f-454d-83a7-3a0a29291661",
 "name": "pat-secretmanager-305db938-331f-454d-83a7-3a0a29291661"
}

$ echo $PAT_TOKEN
eyJhbGciOiJFZERTQSIsImtpZCI6IjgzMkFGNUE5ODg3MzFCMDNGM0EzMTRFMDJFRUJFRjBGNDE5MUY0Q0YiLCJraW5kIjoicGF0IiwidHlwIjoiSldUIn0.eyJ0b2tlbiI6InBBSFh1WE5JdVNHYVpmV3F2OUFzVmJrU3UwR2UySTJrdFU0OGdTZkwyZ1k9In0.-VDbiUf4vNm1KB9qSv7i4sGMCvxs_EuZFAETB-eaOFf3IX8-9m7akN800--ASgXy55_DDFHdy4Z5uSq8lww-Bw

Encode the PAT token in base 64 and save it in an environment variable:

export PAT_TOKEN_B64=$(echo -n $PAT_TOKEN | base64)
echo $PAT_TOKEN_B64

Retrieve and save the KMS information

List the OKMS domains:

$ ovhcloud okms list
┌──────────────────────────────────────┬─────────────┐
│                  id                  │   region    │
├──────────────────────────────────────┼─────────────┤
│ 305db938-331f-454d-83a7-3a0a29291661 │ eu-west-par │
│ xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx │ eu-west-par │
└──────────────────────────────────────┴─────────────┘

Save the KMS endpoint and the OKMS ID in two environment variables. For example:

export OKMS_ID="305db938-331f-454d-83a7-3a0a29291661"
export KMS_ENDPOINT=$(ovhcloud okms get 305db938-331f-454d-83a7-3a0a29291661 -o json | jq .restEndpoint | xargs)

Create a secret in the Secret Manager

In the OVHcloud Control Panel (UI), go to ‘Secret Manager’ section and click on the Create a secret button.

Then in order to create a secret ‘prod/eu-west-par/dockerconfigjson’, in the Europe region (France – Paris) eu-west-par, choose this region:

Then, choose the OKMS domain and create”prod/eu-west-par/dockerconfigjson” in the path and fill the content:

Finally, click on the Create button to finalise the creation of the new secret.

Install or update the ESO

If you’d never installed ESO in your Kubernetes cluster, you can install it via Helm:

helm repo add external-secrets https://charts.external-secrets.io
helm repo update

helm install external-secrets \
   external-secrets/external-secrets \
    -n external-secrets \
    --create-namespace \
    --set installCRDs=true

If you already installed it, now you should update it in order to use this new provider:

helm upgrade external-secrets external-secrets/external-secrets -n external-secrets

⚠️ In order to use the OVHcloud provider, you need to have a running instance of ESO equals to version 2.3.0 or more.

$ helm list -n external-secrets

NAME            	NAMESPACE       	REVISION	UPDATED                              	STATUS  	CHART                 	APP VERSION
external-secrets	external-secrets	1       	2026-04-13 13:56:29.071329 +0200 CEST	deployed	external-secrets-2.3.0	v2.3.0

Let’s deploy a Secret in Kubernetes using the ESO provider!

Deploy a ClusterSecretStore to connect ESO to Secret Manager

Set up a ClusterSecretStore to manage synchronization with Secret Manager.
It will use the OVHcloud provider with token authorization mode, and the OKMS endpoint as the backend.

Create a clustersecretstore.yaml.template file with the content below:

apiVersion: external-secrets.io/v1
kind: ClusterSecretStore
metadata:
  name: secret-store-ovh
spec:
  provider:
    ovh:
      server: "$KMS_ENDPOINT" # for example: "https://eu-west-rbx.okms.ovh.net"
      okmsid: "$OKMS_ID" # for example: "734b9b45-8b1a-469c-b140-b10bd6540017"
      auth:
        token:
          tokenSecretRef:
            name: ovh-token
            namespace: external-secrets
            key: token
---
apiVersion: v1
kind: Secret
metadata:
  name: ovh-token
  namespace: external-secrets
data:
  token: $PAT_TOKEN_B64

Generate the clustersecretstore.yaml file from the environment variables you defined:

envsubst < clustersecretstore.yaml.template > clustersecretstore.yaml

You should obtain a file filled with the OVHcloud KMS information:

apiVersion: external-secrets.io/v1
kind: ClusterSecretStore
metadata:
  name: secret-store-ovh
spec:
  provider:
    ovh:
      server: "https://eu-west-par.okms.ovh.net" # for example: "https://eu-west-rbx.okms.ovh.net"
      okmsid: "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" # for example: "734b9b45-8b1a-469c-b140-b10bd6540017"
      auth:
        token:
          tokenSecretRef:
            name: ovh-token
            namespace: external-secrets
            key: token
---
apiVersion: v1
kind: Secret
metadata:
  name: ovh-token
  namespace: external-secrets
data:
  token: ZXlK...UJ3

Apply it in your Kubernetes cluster:

kubectl apply -f clustersecretstore.yaml

Check:

$ kubectl get clustersecretstore.external-secrets.io/secret-store-ovh

NAME               AGE   STATUS   CAPABILITIES   READY
secret-store-ovh   7s    Valid    ReadWrite      True

Create an ExternalSecret

Create an externalsecret.yaml file with the content below:

apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata:
  name: docker-config-secret
  namespace: external-secrets
spec:
  refreshInterval: 30m
  secretStoreRef:
    name: secret-store-ovh
    kind: ClusterSecretStore
  target:
    template:
      type: kubernetes.io/dockerconfigjson
      data:
        .dockerconfigjson: "{{ .mysecret | toString }}"
    name: ovhregistrycred
    creationPolicy: Owner
  data:
  - secretKey: ovhregistrycred
    remoteRef:
      key: prod/eu-west-par/dockerconfigjson

Apply it:

$ kubectl apply -f externalsecret.yaml

externalsecret.external-secrets.io/docker-config-secret created

Check:

$ kubectl get externalsecret.external-secrets.io/docker-config-secret -n external-secrets 

NAME                   STORETYPE            STORE              REFRESH INTERVAL   STATUS         READY   LAST SYNC
docker-config-secret   ClusterSecretStore   secret-store-ovh   30m                SecretSynced   True    4s

After applying this command, it will create a Kubernetes Secret object.

$ kubectl get secret ovhregistrycred -n external-secrets

NAME              TYPE                             DATA   AGE
ovhregistrycred   kubernetes.io/dockerconfigjson   1      49s

The Kubernetes Secret have been created 🎉

We created a Secret directly from the key, but the OVHcloud ESO provider allows you to fetch the original secret from different parameters (fetch the whole secret, fetch nested values, fetch multiple secrets…), according to your needs.

Conclusion

In this blog, we’ve explained how to create secrets in the OVHcloud Secret Manager and then integrate them directly in your Kubernetes clusters using the new ESO OVHcloud provider.

With this brand new OVHcloud provider, you will have a smoother integration between the Secret Manager and your Kubernetes clusters with ESO.

Our team are working on several other integrations, so stay tuned, and please share your thoughts with us!

Before an application go to production, it passes through several stages: source code, build, packaging and distribution. But Malicious code – such as a compromised dependency, breached CI pipeline, or modified package in a registry – can be introduced at any point in the development cycle, potentially impacting thousands of projects

This is precisely where Software Supply Chain Security (SSCS) comes in: to protect not just the code itself, but also how it’s built, delivered, and utilised.

Attacks like SolarWinds and Log4Shell aren’t isolated incidents, but rather subtle indicators that have escalated in severity.

This blog post explores recommended solutions and best practices for OVHcloud Managed Private Registry (MPR), an OCI-compliant artifact registry, to help you enhance your Software Supply Chain Security.

Generate a Software Bill Of Materials (SBOM)

SBOMs provides a list of all the ingredients (OS, libraries, code) and anything that composes the images that will run on your Kubernetes cluster. 

From that list, you can find out more about the image, its vulnerabilities, and licenses.

Generate an SBOM manually

To manually generate an SBOM from your image, click the ‘GENERATE SBOM’ button:

Within seconds, the SBOM column for your image will display “Queued”, then change to “Generating”, and a “SBOM details” link will appear.

Click the ‘SBOM details’ link to view the SBOM:

Your application’s SBOM is generated by Trivy in SPDX format. This item is then listed as an accessory for your image in the registry.

Click the ‘sbom.harbor’ accessory type for more details:

Generate an SBOM automatically

Manually generating an SBOM is a good practice, but automating the process is even better. The private registry can automatically generates the SBOM for you once an image is pushed to the desired project.

Click the project your image is part of, navigate to the ‘Configuration’ tab, then tick the SBOM generation checkbox:

Vulnerabilities scanning

We recommend running vulnerability scans on the images to confirm that:

• the images provided are free of any known vulnerabilities (CVEs);
• security patches are well integrated before deployment;
• the images used in production comply with security and compliance policies.

There are several vulnerability scanners available, like Trivy, Docker Scout, and Grype.

The OVHcloud Managed Private Registry uses Trivy as its default vulnerability scanner, but you can add more scanners if needed. Go to the Administration panel, click ‘Interrogation Services’, then navigate to the ‘Scanners’ tab:

Scan your image manually

To manually run a vulnerability scan on your image, go to your project and click the SCAN VULNERABILITIES button:

Within a few seconds, a scan will run and reveal any vulnerabilities detected in your image.

Click your image to take a look at the CVEs list:

Scan your image automatically

To automatically scan images on push, click the project your image is part of, then the ‘Configuration’ tab, and tick the ‘Vulnerabilities scanning’ checkbox:

Schedule vulnerability scans

Another way to stay informed is by configuring your vulnerability scanner to run scans every day. Go in the Administration panel, click ‘Interrogation Services’, then the ‘Vulnerability’ tab:

You can choose to schedule the scan Hourly, Daily, Weekly or you can customize when the scan will be triggered.

Scheduled scans ensure that existing images are regularly/periodically analyzed for newly discovered vulnerabilities (CVEs).

Prevent vulnerable images from running

You can also configure a project to prevent vulnerable images from being pulled. In order to do that, check the Prevent vulnerable images from running checkbox.

Select the severity level of vulnerabilities to prevent images from running, from None to Critical.

With this configuration, images cannot be pulled if their level is equal to or higher than the selected level of severity.

Exploitable vulnerabilities

When a scanner found vulnerabilities for your images, it is not necessary that they are exploitable in your application/in your image.

In this example, my application is build with golang 1.25-alpine, but Trivy found several CVEs that are only exploitable in golang 1.19.1 or less.

In order to remove/skip the “false positive”, a solution exists.

VEX (Vulnerability Exploitability eXchange) is a standard “format” to state whether a vulnerability is exploitable or not in a specific context.

You can generate a VEX file with vexctl or govulncheck tools.

Example:

# With vexctl
$ VULN_ID="CVE-2022-27664"
$ PRODUCT="pkg:golang/golang.org/x/net@v0.0.0-20220127200216-cd36cc0744dd"
$ vexctl create --file vex.json --author 'Aurélie Vache' --product "pkg:oci/demo@sha256:$HASH?repository_url=$REGISTRY/$HARBOR_PROJECT/demo" --vuln "$VULN_ID" --status 'not_affected' --justification 'vulnerable_code_not_present' --impact-statement "HTTP/2 vulnerability $VULN_ID is not exploitable because the image is compiled with Go 1.20, which contains the patched library."

# With govulncheck (for Go apps)
$ govulncheck -format openvex ./... > ../demo.vex.json

For the moment, OVHcloud MPR (managed Harbor) does not support VEX files (and the OpenVEX format) but it is planned in the future.

💡But the good news is that you can configure a CVEs whitelist with the list of not exploitable CVEs to ignore them during vulnerability scanning:

You can optionally uncheck the Never expires checkbox and use the calendar selector to set an expiry date for the allowlist.

Sign your images

It’s recommended to sign your images to ensure they haven’t been modified and originate from your pipeline (CI/CD).

Signing your images is crucial for protecting them against compromised registries and unauthorised image replacements.

Without a signature, there’s no guarantee the deployed image is the one you originally built!

You can sign your images with Sigstore Cosign or Notation tools:

$ export HARBOR_PROJECT=supply-chain
$ export IMAGE=xxxxxx.c1.de1.container-registry.ovh.net/$HARBOR_PROJECT/demo
$ export HASH=$(skopeo inspect docker://${IMAGE}:latest | jq -r .Digest | sed "s/^sha256://")

# Sign with Cosign
## Generate a private and a public key
$ cosign generate-key-pair
## Sign the image with the OCI 1.1 Referrers API
$ cosign sign -y --key cosign.key $IMAGE@sha256:$HASH 

# Sign with Notation
## Generate a RSA key & a self-signed X.509 test certificate
$ notation cert generate-test --default "test"

## Sign the image with the OCI 1.1 Refferrers API
$ export NOTATION_EXPERIMENTAL=1 ; notation sign -d --allow-referrers-api ${IMAGE}@sha256:${HASH}

You can use Cosign or Notation to sign your images, OVHcloud MPR supports both.

Your signature will appear beside your image as an accessory, plus a green checkmark ✅ in your column:

⚠️ Keep in mind, MPR (Harbor) doesn’t support signatures generated by Cosign v3 (the signature will upload and appear as an accessory, but the mark will stay red instead of turning green). This bug should be fixed in Harbor 2.15 💪.

Signing your OCI artifacts and linking them to your images is recommended, and you can do this using Cosign:

$ cosign attest -y --predicate sbom.spdx.json --key cosign.key $IMAGE@sha256:$HASH

They will be uploaded to the OVHcloud private registry and listed as accessories.

Ensure only verified images are pushed to your registry’s projects

To allow only verified/signed images to be deployed on a project, click the project your image is part of, navigate to the ‘Configuration’ tab, and tick the Cosign and/or Notation checkbox:

When checked, the registry will only allow verified images to be pulled from the project. Verified images are determined by Cosign or Notation, depending on the policy you have checked. Note that if you have both Cosign and Notation policies enforced, then images will need to be signed by both Cosign and Notation to be pulled.

Tag immutability

By default, tags are mutables, it means that you can push an image demo with the tag 1.0.0, do a modification in the code and push again to this same tag.

It could be useful to fix a bug but in term of security a mutable tag does not guarantee that the image you’ve built and pushed for the 1.0.0 version is the same image that exists now in the registry.

Moreover, on Harbor (so on OVHcloud MPR), due to limitations in the upstream OCI Distribution specification, the registry does not enforce a strict link between a tag and an image digest.

As a result, a tag can be reassigned to a different artifact. And it causes a side effect on the registry, this causes the tag to migrate across the artifacts and every artifact that has its tag taken away becomes tagless.

To prevent this situation, you can configure tag immutability rules. Tag immutability guarantees that an immutable tagged artifact cannot be deleted, and also cannot be altered in any way such as through re-pushing, re-tagging, or replication from another target registry.

To do that, click on your project and on the Policy tab and select TAG IMMUTABILITY:

And then click the ADD RULE button.

Fill the repositories and tags list according to your needs.

Example:

⚠️ You can add a maximum of 15 immutability rules per project.

To wrap thing up

Software supply chain security is super important these days. Everything is changing quickly – the concept, standards, and tools. So, leveraging useful tools like OVHcloud MPR and knowing how to set them up can boost your Software Supply Chain Security efforts.

To learn more about how to use and configure OVHcloud private registries, don’t hesitate to follow our guides.