As both the cyberattack cause and cure, ever-expanding AI has been transforming cybersecurity from both sides of the battlefield. Organizations increasingly use AI to detect threats and automate security operations, but just as rapidly, attackers are also adopting AI to generate malware, accelerate phishing campaigns, and probe systems at scale.

As cyber threats evolve, cybersecurity education must evolve with them. Accordingly, future security engineers need more than theoretical knowledge — they need hands-on experience building and defending modern cloud environments against increasingly intelligent attacks.

This was the exact goal of the recent OVHcloud x EPITA Rennes SecDevOps Hackathon. Students spent three days developing cloud-native security solutions designed for an AI-driven threat landscape, helping train the next generation of tech talent.

Why AI is changing cybersecurity education

Traditional cybersecurity education often focuses on known attack patterns or defensive tools in isolation. But today’s security teams are operating in a very different reality.

Analysts now work across AI-assisted detection systems, cloud-native infrastructure, threat intelligence platforms, and automated incident response workflows. At the same time, attackers are using AI to automate reconnaissance, generate convincing phishing content, and adapt their techniques faster.

Preparing students for this environment means moving beyond classroom theory. They need realistic infrastructure, collaborative development, and hands-on security engineering under real technical constraints.

That is where hackathons can make the difference: they push students to solve practical cybersecurity problems in conditions much closer to the ones they will face in the field.

Building cloud-native security solutions

As part of the OVHcloud Education program, students from EPITA Rennes’ SecDevOps major were given access to OVHcloud Public Cloud infrastructure alongside AI credits and development resources. Working in teams, they designed, tested, and deployed solutions capable of addressing emerging cybersecurity challenges while operating in production-like cloud environments. Rather than focusing on theoretical concepts, every project tackled practical problems security teams increasingly encounter today.

Rethinking cyberdefense in the age of AI

Several projects reflected how defensive security is evolving alongside AI:

MIR[AI]GE: turning AI attackers against themselves

Awarded Best Technical Project, MIR[AI]GE explored a proactive approach to defending against autonomous AI attacks.

Instead of simply blocking malicious activity, the platform detects offensive AI agents and redirects them into isolated honeypot containers filled with realistic — but entirely fake — data.

The objective is not only to stop the attack but also to waste the attacker’s computing resources while gathering valuable behavioral information.

As AI-generated attacks become more sophisticated, deception technologies like honeypots are becoming increasingly valuable components of modern cyberdefense strategies.

Find out more: miraige.vercel.app

Honeymind: threat intelligence from attacker behavior

Winner of the Best Presentation Award, Honeymind focused on generating actionable threat intelligence.

The team developed an internet-facing honeypot capable of analyzing attacker requests before enriching the collected data with AI, improving deception techniques and producing insights that security operations teams could use during incident response.

Projects like this demonstrate how AI can support defenders — not only by automating analysis but by making security systems themselves more adaptive.

Discover the repository: github.com/al2al85/HoneyMind

Other innovative approaches

Other teams explored complementary security challenges:

Winnie developed a bounce honeypot that guides attackers through AI-generated environments inspired by the MITRE ATT&CK framework.

Meanwhile, SRE-squad created an assistant designed for SOC analysts, helping correlate logs with operational runbooks and prioritize alerts in environments increasingly flooded with AI-generated attack traffic.

Together, these projects illustrate how future security professionals are beginning to combine cloud infrastructure, automation, and AI into practical defensive workflows.

What organizations can learn

While the hackathon centered on students, the technologies they explored mirror challenges many organizations already face.

Modern cybersecurity increasingly relies on:

• Cloud-native security architectures
• Threat intelligence pipelines
• AI-assisted analysis
• Deception technologies such as honeypots
• Automated security operations

As these capabilities become mainstream, organizations will need engineers who understand both software development and security engineering — the core principles behind SecDevOps.

Providing students with opportunities to build these systems today helps the next generation of cybersecurity professionals prepare for tomorrow’s threats.

Supporting the next generation of security engineers

The OVHcloud Education program aims to bridge academic learning with real-world cloud engineering by giving students access to production-grade infrastructure and practical technical challenges.

The hackathon also offered members of the winning teams a fast-track interview with OVHcloud’s technical recruitment teams for their end-of-studies internships.

A special thank you goes to Gabin, Lucas, and Magali, whose mentorship and expertise helped make this year’s event a success.

If you’re ready to turn AI cybersecurity training into a career, explore opportunities on the OVHcloud Careers site. And if your institution would like to organize a hackathon with the OVHcloud Education program, we’d love to hear from you.

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.

Après avoir configuré votre serveur manuellement, pas à pas, il est temps d’automatiser tout le processus.

L’idée est simple : décrire votre infrastructure dans des fichiers de configuration et laisser Terraform s’occuper de commander les ressources chez OVHcloud.

Voici un guide d’introduction à Terraform, avec de nombreuses informations utiles : https://support.us.ovhcloud.com/hc/en-us/articles/22648864003219-Using-Terraform-with-OVHcloud.
Ainsi que le lien vers le fournisseur officiel Terraform d’OVHcloud : https://registry.terraform.io/providers/ovh/ovh/latest

Il existe deux étapes à l’automatisation du déploiement :

• déploiement de l’instance Public Cloud ;
• déploiement de la partie applicative (vscode-server) et sa configuration.

1. Le cœur de l’automatisation : le script Cloud-init

Avant de parler de Terraform, il est nécessaire de comprendre comment le serveur s’auto-configure lors de son initialisation.
Pour cela, utilisez cloud-init, un standard qui permet d’exécuter des scripts dès le premier démarrage de l’instance.

Ce que vous allez automatiser dans ce script :

• la mise à jour du système (apt update/upgrade) ;
• l’installation de code-server via le script officiel ;
• l’installation et la configuration de Caddy (pour le SSL automatique) ;
• la configuration du pare-feu UFW.

Ce type de fichier possède une syntaxe bien particulière, le cloud-config.yaml sera à disposition plus bas.

Toutefois, l’important à retenir est : pourquoi utiliser ce format ?

• Idempotence : le cloud-init s’assure que tout est prêt dès le premier boot.
• Sécurité dès la naissance : le pare-feu ufw est activé immédiatement, réduisant la fenêtre d’exposition.
• Intégration Terraform : une seule ligne est nécessaire pour l’inclure : user_data = file("cloud-config.yaml")

2. Utilisation de Terraform pour le déploiement

Terraform permet d’obtenir un démarrage de l’instance bien plus aisé et rapide.
Sa configuration, quant à elle, comporte plusieurs avantages :

• persistance des données. Un terraform destroy de l’instance pourra conserver le volume de données (but fixé dans le chapitre 2) ;
• évolutivité. Si le projet grossit, la taille du volume et/ou la flavor peuvent être modulées ;
• portabilité. Le volume de données peut être démonté et remonté sur une autre machine.

Pour garder ce billet court, pas de copier-coller de code, mais un lien vers un repository GitHub avec tout le nécessaire pour déployer ceci en quelques minutes :
https://github.com/RemyAtOVH/blogpost-dev-server

Son utilisation :

Avant l’application du cloud-init (ou sans), on constate bien un volume secondaire /dev/sdb, de taille correspondant aux spécifications de Terraform :

C’est lui qui assurera la persistance des données.

Vous pourriez tout à fait effectuer manuellement la suppression de l’instance et des autres composants, sans toutefois le supprimer lui.
Pour éviter toute suppression en cas de « terraform destroy », un paramètre a été ajouté :

Lors du premier démarrage, les différents scripts d’installation pouvant prendre du temps, vous pouvez en vérifier les étapes d’un simple tail :

Une fois le cloud-init exécuté automatiquement, tout ce qui a pu être mis en place manuellement dans les chapitres précédents a été fait. Et ce, de façon automatique et reproductible !

Il sera donc possible, sous réserve de quelques minutes d’exécution, de déployer cet environnement de développement distant personnalisé si besoin et potentiellement le supprimer après quelques heures ou jours d’utilisation.

Dans cette série de chapitres, nous avons transformé une simple idée, disposer de son VS Code partout, en une infrastructure de niveau professionnel, automatisée et résiliente.
Retrouvez ci-dessous les étapes et le chemin parcouru.

• Chapitre 1 : premiers pas en installation manuelle pour comprendre la mécanique de code-server.
• Chapitre 2 : sécurisation, avec utilisation d’un Reverse Proxy (Caddy) et d’un pare-feu (UFW) pour naviguer sereinement en HTTPS.
• Chapitre 3 : cet article, utilisant Terraform et OpenStack, pour une meilleure reproductibilité.

L’automatisation que nous avons mise en place avec un déploiement chez OVHcloud en utilisant Public Cloud reposant sur OpenStack, constitue une base solide.

À partir d’ici, il est possible d’aller encore plus loin : ajouter une sauvegarde automatique de vos volumes (snapshotting), coupler cela à un pipeline CI/CD ou même explorer le déploiement de cet environnement via docker-compose, ou même Kubernetes.

Retrouvez prochainement une version vidéo de ces billets de blog, étape par étape, sur notre chaîne YouTube. Restez à l’écoute !

After manually configuring your server step by step, it’s time to automate the entire process.

The idea is simple: describe your infrastructure in configuration files and let Terraform take care of managing the resources at OVHcloud.

Here is an introductory guide to Terraform, with plenty of useful information: https://support.us.ovhcloud.com/hc/en-us/articles/22648864003219-Using-Terraform-with-OVHcloud.
As well as the link to OVHcloud’s official Terraform provider: https://registry.terraform.io/providers/ovh/ovh/latest

There are two steps to automating the deployment:

• Deployment of the Public Cloud instance
• Deployment of the application part (vscode-server) and its configuration

1. The heart of the automation: the Cloud-init script

Before we move onto Terraform, we need to understand how the server self-configures during its initialisation.
To do this, use cloud-init, a standard that allows scripts to be executed from the first boot of the instance.

What you will automate in this script:

• The system update (apt update/upgrade)
• The installation of code-server via the official script
• The installation and configuration of Caddy (for automatic SSL)
• The configuration of the Uncomplicated Firewall (UFW)

This type of file has a very particular syntax; the cloud-config.yaml will be available further down.

However, the important point to remember is: why use this format?

• Idempotence: cloud-init ensures that everything is ready from the first boot.
• Security from the outset: the UFW is activated immediately, reducing the exposure window.
• Terraform Integration: a single line is required to include this: user_data = file("cloud-config.yaml")

2. Using Terraform for deployment

Terraform allows for a much easier and quicker instance startup.
Its configuration also has several advantages:

• Persistent data: a terraform destroy of the instance can retain the data volume (goal set in chapter 2)
• Scalability: if the project grows, the size of the volume and/or the flavour can be adjusted
• Portability: the data volume can be unmounted and remounted on another machine.

To keep this post brief we won’t copy-paste the code here, but this link to a GitHub repository contains everything needed to deploy this in a few minutes:
https://github.com/RemyAtOVH/blogpost-dev-server

Its usage:

Before applying cloud-init (or without it), there is a secondary volume /dev/sdb, sized according to Terraform specifications:

This is what will ensure data persistence.

You could manually delete the instance and other components, without deleting it.
To prevent any deletion in the event of “terraform destroy”, a parameter has been added:

During the first startup, the various installation scripts may take time. You can check their steps with a simple tail:

Once cloud-init has been executed automatically, everything that could have been set up manually in the previous chapters has been done automatically, in a way that can be reproduced!

It will therefore be possible to deploy this customised remote development environment if needed (with a few minutes of execution) and potentially delete it after a few hours or days of use.

In this series of chapters, we have transformed a simple idea – having access to VS Code wherever you are – into a professional-grade, automated and resilient infrastructure.
Below are the steps involved and the progress so far.

• Chapter 1: first steps in manual installation to understand the mechanics of code-server.
• Chapter 2: making it secure, using a Reverse Proxy (Caddy) and a firewall (UFW) to navigate smoothly in HTTPS.
• Chapter 3: this article, in which we’ll use Terraform and OpenStack for better reproducibility.

The automation we have implemented with an OVHcloud deployment using an OpenStack-based Public Cloud provides a solid foundation.

From here, you can go even further: add automatic backups of your volumes (snapshotting), couple this with a CI/CD pipeline, or even explore deploying this environment via docker-compose or even Kubernetes.

A step-by-step video version of these blog posts will soon be available on our YouTube channel. Stay tuned!

In the previous chapter, we started the VSCode Server on a remote instance.

That’s a win. However, as it stands, your installation is vulnerable, or at least not optimally secured. Traffic is being sent in clear (HTTP) and port 8080 is exposed to anyone scanning our IP address.

To transform this prototype into a daily working tool, we need to set up a Reverse Proxy.
Its role is simple: to intercept secure connections (HTTPS) on the standard port 443 and redirect them locally to our service.

1. Prerequisites: securing the network part

First and foremost, we need to instruct code-server to no longer listen for connections from outside, but only to those coming from the machine itself (the proxy).

Modify your configuration file: nano ~/.config/code-server/config.yaml

Change the line “bind-addr” as follows: 

bind-addr: 127.0.0.1:8080

Then restart the service.

This will ensure that vscode-server will indeed only “listen” locally and cannot be contacted directly from outside.

2. Implement the reverse proxy

Here, you have two choices:

• NGINX, which has been the standard choice for many years
• Caddy, which has a more simplistic (but comprehensive) and newer approach.

For this blog post, we have selected Caddy for the example and to familiarise ourselves if we have not already!

Caddy natively manages SSL certificate renewal – which can be done through OVHcloud!

Installation (Debian/Ubuntu)

You will find more comprehensive documentation for other systems or installation methods in the official documentation: https://caddyserver.com/docs/install.

Configuration: modify the file /etc/caddy/Caddyfile (clear it and replace it with this):

Replace “dev.your-domain.uk” with your own domain name, with the subdomain of your choice pointing to the IP of the instance.

• Simple configuration only on HTTP port (80)

• Recommended configuration on HTTPS port (443), using a domain hosted with OVHcloud.

For creating OVHcloud API tokens, you can refer to this page: https://eu.api.ovh.com/createToken/.

For further details regarding SSL certificate management, consult the official Caddy documentation.
Application:

If you have opted for the recommended configuration in HTTPS, your environment is now protected by robust SSL encryption.

You are no longer at risk of having your password intercepted on public Wi-Fi, which is a considerable step towards our goal.

3. Network and firewall

Now that the access point is unique via the HTTPS URL configured just above, the rest of the ports, except for SSH, can be closed.

Now, implement the basic rules in the firewall. On Ubuntu, the standard tool is UFW (Uncomplicated Firewall).

Start by opening the ports related to the functional services.

Activate the firewall:

Check the implementation of the rules.

You can also add stricter rules to explicitly reject anything unauthorised in incoming traffic while generally authorising outgoing traffic.

From now on, if someone attempts to access the IP on port 8080, the connection will be outright rejected.

Only the domain name in HTTPS is the legitimate entry point.
This handy little development server now feels more like a fortress. 

But what happens if you decide to delete this instance to move to a more powerful one and/or stop it for an indefinite period, as your project is on hold?

This is what you will find out in the next part: how to isolate your data and configurations on a persistent storage volume to make your environment completely interchangeable, but also how to automate the deploymen of this development environment!

The ultimate goal is for a simple terraform apply command to to be enough to generate a development environment that’s ready to use in under two minutes.

Dans le chapitre précédent, nous avons démarré VSCode Server sur une instance distante.

C’est une victoire. Mais en l’état, votre installation est vulnérable, ou du moins non sécurisée de façon optimale. Le trafic circule donc en clair (HTTP) et le port 8080 est exposé à quiconque scanne notre adresse IP.

Pour transformer ce prototype en un outil de travail quotidien, il est indispensable de mettre en place un Reverse Proxy.

Son rôle est simple : intercepter les connexions sécurisées (HTTPS) sur le port standard 443 et les rediriger localement vers notre service.

1. Prérequis : verrouiller la partie réseau

Avant toute chose, il est nécessaire de demander à code-server de ne plus écouter les connexions venant de l’extérieur, mais uniquement celles venant de la machine elle-même (le proxy).

Modifiez votre fichier de configuration : nano ~/.config/code-server/config.yaml

Modifiez la ligne « bind-addr » comme suit :

bind-addr: 127.0.0.1:8080

Puis redémarrez le service.

Ceci aura pour effet d’avoir la certitude que vscode-server « écoutera » bien uniquement en local et ne pourra pas être contacté directement de l’extérieur

2. Implémenter le reverse proxy

Ici, vous avez deux choix :

• nginx constitue le choix standard depuis de nombreuses années ;
• Caddy, avec une approche plus simpliste (mais complète) et récente.

Pour ce billet de blog, nous avons sélectionné Caddy pour l’exemple et se familiariser si ce n’est pas déjà le cas !

Caddy sait nativement gérer l’implémentation du renouvellement de certificats SSL. Le tout, avec OVHcloud !

Installation (Debian/Ubuntu

Vous pourrez trouver une documentation plus complète pour d’autres systèmes, ou méthodes d’installation dans la documentation officielle : https://caddyserver.com/docs/install.

Configuration : modifiez le fichier /etc/caddy/Caddyfile (videz-le et remplacez par ceci) :

Remplacez « dev.votre-domaine.fr » par votre propre nom de domaine avec le sous-domaine de votre choix pointant vers l’IP de l’instance.

• Configuration simple uniquement sur le port HTTP (80)

• Configuration recommandée sur le port HTTPS (443), en utilisant un domaine hébergé chez OVHcloud.

Pour la création des tokens API OVHcloud, vous pouvez vous référer à cette page : https://eu.api.ovh.com/createToken/.

Pour davantage de détails concernant la gestion des certificats SSL, vous pouvez consulter la documentation officielle de Caddy.
Application:

Désormais, si vous avez opté pour la configuration recommandée en HTTPS, votre environnement est protégé par un chiffrement SSL robuste.

Vous ne risquez plus de voir votre mot de passe intercepté sur un Wi-Fi public, ce qui est un pas en avant non négligeable vers notre but.

3. Réseau et pare-feu

Maintenant que le point d’accès est unique via l’URL en HTTPS configuré juste au-dessus, le reste des ports, sauf le SSH, évidemment, peut être coupé.

Implémentez maintenant les règles basiques, dans le pare-feu. Sur Ubuntu, l’outil standard est UFW (Uncomplicated Firewall).

Commencez par ouvrir les ports relatifs aux services fonctionnels.

Activez le firewall :

Vérification de la prise en compte des règles.

Vous pouvez également ajouter des règles plus strictes pour rejeter explicitement tout ce qui n’est pas autorisé en entrée et laisser la sortie globalement autorisée.

Désormais, si quelqu’un tente d’accéder à l’IP sur le port 8080, la connexion sera purement et simplement rejetée.

Seul le nom de domaine en HTTPS constitue la porte d’entrée légitime.
Ce petit serveur de développement, bien pratique, ressemble désormais davantage à une forteresse. 

Mais que se passe-t-il si vous décidez de supprimer cette instance pour en prendre une plus puissante et/ou la stopper pour une durée indéterminée, car votre projet est en pause ?

C’est ce que vous découvrirez dans la prochaine partie : comment isoler vos données et vos configurations sur un volume de stockage persistant pour rendre votre environnement totalement interchangeable, mais également comment automatiser le déploiement de cet environnement de développement !

L’objectif final : qu’une simple commande terraform apply suffise à faire surgir un environnement de développement, prêt à l’emploi en moins de deux minutes.

Un environnement de développement est indispensable au quotidien, mais il peut vite devenir complexe à gérer. Nous allons voir ensemble, dans un billet de blog en 3 parties, comment améliorer son confort et sa productivité !

Réunions incessantes, environnements Docker différant légèrement sur chaque machine, mises à jour système intempestives : garder un poste de développement fiable et cohérent devient vite un combat quotidien.

À chaque nouveau projet, il faut ré-installer les mêmes outils, les mêmes CLI, reconfigurer les mêmes SDK ou frameworks. Et surtout, espérer que la machine locale tienne la charge quand les tests, le linter et la base de données fonctionnent en même temps. Le tout, avec des situations de télétravail ou de mobilité dans lesquelles les personnes se retrouvent à développer depuis un ordinateur portable parfois proche de l’obsolescence, derrière un VPN capricieux.

Dans cette série d’articles, l’objectif est de transformer cette réalité en s’appuyant sur un environnement de développement complet hébergé dans le cloud et accessible depuis n’importe quel navigateur grâce à VS Code Server.

L’idée est de disposer d’une « station de travail » distante, puissante et, si besoin, reproductible et indépendante.

Ce premier chapitre montre comment déployer simplement et manuellement une instance Public Cloud et y installer VS Code Server. Les chapitres suivants traiteront de sa sécurisation et de son automatisation.  

1. Déploiement de l’instance

Pour les premiers tests, afin de prendre en main l’environnement et de le tester, il peut s’avérer judicieux d’opter pour une instance assez modeste, de type Discovery. Une instance d2-2 sera ici utilisée. 1vCPU et 2 Go de RAM peuvent être suffisants.

2. Installation de la partie applicative

La source de vérité pour les étapes suivantes est le GitHub du projet vscode-server : https://github.com/coder/code-server

Plusieurs possibilités existent pour l’installation. Dans ce chapitre, pour simplifier le déploiement et pour les personnes peu habituées à Docker, l’installation se fera via le script d’installation « natif », sans utiliser de conteneurs.

Cette étape suffit à installer le nécessaire. Activez maintenant le service et vérifiez son bon fonctionnement.

3. Validation de la configuration

À ce stade, le service est opérationnel, il reste à en finaliser la configuration, notamment la création du dossier qui contiendra le code ainsi que l’authentification.

Il est ici nécessaire de placer un mot de passe sécurisé et de vérifier que la bind-addr correspond à la configuration souhaitée.

Si vous souhaitez tester directement le service en l’état, utilisez 0.0.0.0:8080. Relancez ensuite le service et accédez à l’interface via http://<IP_PUBLIQUE>:8080.

Après avoir fourni dans la fenêtre d’authentification le mot de passe présent dans le config.yaml, vous accédez directement à VS Code dans le navigateur.

Partant de ce déploiement, vous pouvez donc ici répondre, partiellement en l’état, à la problématique d’un environnement de développement stable.

À ce stade, il est possible de cloner directement vos repositories GitHub ou d’utiliser le dossier workspace pour les cloner.

C’est d’ailleurs ce qui est recommandé pour davantage de pérennité, comme vous pourrez le voir dans le second chapitre.

Pour réaliser un commit de test via l’interface vscode-server, vous devez configurer git en local (juste une fois) pour que l’authentification du remote repository s’effectue correctement.

Dès cette étape, vous pouvez utiliser l’environnement de développement distant avec vscode-server. Et ce, en profitant de quasiment toutes les fonctionnalités dont vous pourriez disposer en local, mais avec les avantages d’un environnement dédié à cet usage.

⚠️ Rappel : en l’état, le déploiement fait ici n’est pas en statut « production ready » !

Le but de ce premier chapitre est de découvrir le service, les manipulations vous étant proposées pour vous permettre de vous familiariser avec l’environnement. Ainsi, veillez à ne pas opérer le service tel que déployé ici plus que quelques heures !

Il sera nécessaire de sécuriser l’environnement, puisqu’il est exposé directement sur Internet. C’est l’objet des chapitres suivants.

Ce premier chapitre se termine avec un environnement de développement opérationnel, déjà capable de supporter un vrai projet applicatif !

L’instance est en ligne, VS Code Server répond dans le navigateur, l’espace de travail est prêt et le premier dépôt a été cloné et ouvert comme sur un poste local. Cette base montre qu’il est possible de s’abstraire du matériel pour gagner en portabilité et partager plus facilement une configuration commune au sein d’une équipe ou d’un poste de développement nomade.

Dans les prochains chapitres, cet environnement au minimum viable sera progressivement renforcé avec du stockage persistant, des mécanismes de sauvegarde ainsi qu’un accès sécurisé en HTTPS. Il sera ensuite entièrement automatisé via de l’Infrastructure as Code, afin de passer d’un simple test technique à une véritable plateforme de développement prête pour la production interne.

A development environment is an essential day-to-day system, but it can quickly become complex to manage. In this three-part blog post, we will explore how to become more comfortable and productive with it!

Endless meetings, slightly differing Docker environments on each machine, and untimely system updates: maintaining a reliable and consistent development workstation can quickly become a daily struggle.

With each new project, you have to reinstall the same tools, the same CLIs, and reconfigure the same SDKs or frameworks. And above all, hope that the local machine can handle the load when tests, the linter, and the database are all running simultaneously. Meanwhile, with remote work or working while travelling, individuals find themselves developing with a temperamental VPN, from a laptop that is sometimes close to obsolescence.

In this series of articles, we aim to transform this reality by building on a complete development environment hosted in the cloud and accessible from any browser via VS Code Server.

The idea is to have a remote, powerful, and, if necessary, reproducible and independent “workstation”.

This first chapter demonstrates how to easily deploy a Public Cloud instance manually and install VS Code Server on it. The following chapters will improve its security and automation.  

1. Deploying the instance

For the initial tests it may be wise to opt for a smaller, Discovery-type instance so that you can familiarise yourself with the environment and test it. A d2-2 instance will be used here. 1 vCPU and 2 GB of RAM should be enough.

2. Installing the application element

The fountain of knowledge for the following steps is the GitHub for the vscode-server project: https://github.com/coder/code-server

There are several options for the installation. In this chapter, to simplify the deployment and for those who are not very familiar with Docker, the installation will be done via the “native” installation script, without using containers.

This step is enough to install the essentials. Activate the service now and check that it is running correctly.

3. Validate the configuration

At this stage, the service is operational; the configuration still needs to be finalised, particularly creating the folder that will contain the code as well as the authentication.

You need to set a secure password here and verify that the bind-addr corresponds to your desired configuration.

If you wish to directly test the service in its current state, use 0.0.0.0:8080. Then restart the service and access the interface via http://<IP_PUBLIQUE>:8080.

After providing the password found in the config.yaml in the authentication window, you will gain direct access to VS Code in the browser.

From this deployment, you can then partially address the issue of getting a stable development environment.

At this stage, it is possible to directly clone your GitHub repositories or to use the workspace folder to clone them.
This is recommended for greater longevity, as you will see in the second chapter.

To perform a test commit via the vscode-server interface, you must configure git locally (just once) so that the authentication of the remote repository runs correctly.

From this step onwards, you can use the remote development environment with vscode-server, while enjoying nearly all the features you might have locally, but with the advantages of having an environment dedicated to this use.

⚠️ Reminder: in its current state, the deployment made here is not “production ready”!

The aim of this first chapter is to introduce the service, with the instructions here to help you familiarize yourself with the environment. Therefore, please ensure that you do not operate the service as deployed here for more than a few hours!

The environment will need to be secured, as it is directly exposed on the Internet. We’ll talk about this in the following chapters.

By now, you have an operational development environment that is already capable of supporting a real application project!

The instance is online, VS Code Server is responding in the browser, the workspace is ready, and the first repository has been cloned and opened as if on a local machine. This foundation demonstrates that it is possible to abstract from the hardware to gain portability and more easily share a common configuration within a team or a remote development workstation.

In the upcoming chapters, this minimum viable environment will be gradually enhanced with persistent storage, backup mechanisms, and secure access via HTTPS. It will then be fully automated through Infrastructure as Code, in order to transition from a simple technical test to a genuine development platform ready for internal production.

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