Can you introduce Azursafe, its industry, mission and values?

The blockchain sector has been growing steadily for several years, bringing both new opportunities and complex challenges, including stricter regulations in Europe and beyond. In this evolving landscape, AzurSafe was founded with a clear mission to support blockchain companies, financial institutions, fraud victims, analytics partners, security researchers, and law enforcement agencies in one shared goal: Making Blockchain Safer.

We develop and offer transaction analysis and monitoring solutions, to identify malicious activity using intelligent and innovative technologies.

Quickly gaining the support of the French government and several key partners, AzurSafe has established itself as a trusted player in the sector, earning recognition from private and public financial institutions for its innovative solutions which bring a real added value both in operational and regulatory terms.

What were specific challenges you faced before joining OVHcloud’s Blockchain Accelerator?

Deploying such complex and advanced solutions requires significant logistics in all areas, whether technical or business. Like any ambitious start-up, AzurSafe needs to respond to these challenges as part of its development.

On the technical side, we have to manage and orchestrate dozens of services, from massive data flows to the various characteristics that define each blockchain, then process and analyze all of this while offering a near-instantaneous service, because on the blockchain, every second counts when it comes to preventing fraud.

Why did you decide to explore cloud solutions to overcome these obstacles?

As our solution progressed, we realized that we needed to manage more and more features, then orient the infrastructure so it’s modular as we went along, while maintaining high availability, security standards, and data management without blowing our budget, inevitably linked to our business challenges.

After using other cloud services, we immediately understood the relevance of OVHcloud’s offering. What’s more, we offer a sovereign solution to those who want it (SecNumCloud), so the choice was easy.

How did OVHcloud and the Startup Program help you overcome these challenges?

After two years of intense R&D, we were reassured after benchmarking against the current state of the art and quickly realized that our technology had the same technical capabilities, and even better ones. But that wasn’t all it took to deploy a solution of this kind on the market.

We needed to dig deeper and better understand our environment and the distribution of our solutions and technologies in an ecosystem that was already formed with established players requiring equally established solutions. Participating in inspiring industry exchanges and receiving support throughout our deployment greatly contributed to our success.

Which OVHcloud services or features do you use, and how do they stand out from other solutions?

For our part, we use almost all (or nearly all) Public Cloud services, which stand out from other solutions thanks to their simplicity, performance, and competitive pricing.

How has OVHcloud’s support helped you evolve your infrastructure to meet the demands of your business?

Their support has been very useful in various cases, thanks to the organization of workshops, mentoring, and infrastructure support.

What tangible results have you achieved since collaborating with OVHcloud? How have these results helped to accelerate your growth or improve your product/service offering?

Not to mention the ease of use, which saves time, the costs are at least half those of well-known American providers.

How have these results helped to accelerate your growth or improve your product/service offering?

The program has enabled us to better understand our environment and the industry in which we operate, by combining technical and business support.

Future Vision: What are your ambitions for the future of your startup, and how do you see it evolving within the cloud ecosystem?

Current technologies, as well as the various legal and illegal activities involving blockchain, are still in their infancy. It is easy to predict that they will evolve in the coming years, creating new opportunities but also complex challenges. We do not operate directly on the blockchain, but we must monitor it and evolve with it. Our infrastructure and services must be resilient, and the cloud remains the best alternative for our customers who do not want on-premise software.

What future challenges do you foresee, and how do you see the cloud playing a role in solving them?

The volume of data and the number of protocols and services built on decentralized technologies continue to grow rapidly. Yet, they still rely on essential solutions such as RPC nodes, interface hosting, and advanced platforms like ours to operate safely.

The risks are real and can affect everyone. Security is no longer an option in today’s digital age, and increasingly secure solutions will be necessary. The cloud is an excellent candidate for the coming years, provided it is used correctly.

What advice would you give to other growth-stage startups considering the cloud or joining a support program?

Go for it, you have so much to gain!

Conclusions

AzurSafe has recently reached a new milestone, surpassing $90 billion in transaction value monitored across more than 30 blockchains, highlighting emerging fraud trends and providing real-time insights using advanced AI and ML technologies that demonstrate unrivalled accuracy.

The precision of our fraud detection tools has been approved, audited, battle-tested and endorsed by experts in the financial and investigative industries. But this is only the beginning, and we are preparing huge projects that will completely redefine the landscape on an international scale.

We are surpassing ourselves at every stage to create a more secure blockchain and we would like to thank OVHcloud, our webhost for several years, for this great opportunity and for joining us in revolutionising this industry. We invite anyone who wants to contribute to join us as well.

If you’re a startup looking to transform your business, we encourage you to join the OVHcloud Startup Program or contact OVHcloud to discover how our solutions can support your journey!

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.

Issues related to intellectual property laws and the source of data used to train LLMs, which is sometimes confidential or personal, as well as potential biases in the data, intentional or otherwise, are regularly debated in the press and within technology communities. However, the current focus is on the race between LLM providers, who are competing to develop faster, more efficient models, in search of the ‘wow’ factor that will temporarily propel them to the rank of global AI leader.

Meanwhile, organisations are integrating these technologies into their daily activities at their own pace. Implementation is driven both by employees keen to improve their individual productivity, often based on their experience using AI tools in their personal life, and by business leaders and managers, who see an opportunity to optimise efficiency of low-value-added tasks.

At OVHcloud, we have launched an ‘AI Labs’ initiative, which is responsible for centralising projects and experiments using LLM tools. This team now supervises over a hundred projects, and new ones are added every week. The approach aims to catalyse ideas and provide a framework for efficiently implementing effective production tools.

From a data security perspective, the proliferation of experimentation and proof-of-concept (POC) projects creates numerous additional risks that need consideration. Modelling interactions between each component is necessary to understand these risks, as many configurations are possible.

In this article we will take a look at some example use cases, identify the main risks and provide suggestions for how to address them using a risk reduction logic model. We will focus on simple use cases where a user accesses an application for their work. These applications are accessible from their work context, and each have access management mechanisms that verify the user and grant them access to the relevant data and functions associated with their business profile.

The introduction of LLM technologies fits into the usual operating mode of an information system to enrich the user experience and offer additional features. Let’s take a look at the examples.

Conversational agents (without third-party integration)

Most professionals working on a computer regularly use conversational agents to ‘enhance’ their work, often without acknowledging it, for example when writing an email, summarising a document, finding a complex Excel formula, answering a legal or technical question, etc.). As these agents are not connected to the company’s information system,  the risks are limited and depend on the attitude and practices of the user, for example with regards to uploading data, copying and pasting confidential data into the agent, etc.

In this context, the user is the go-between managing the information transfer between the company application and the third-party agent. The agent only has access to information voluntarily sent by the user, typically via the service interface that allows prompts to be entered. These services are rapidly extending their capabilities, allowing file upload, and microphone or camera access, but we remain in a classic responsibility framework in terms of security, with the human in the loop by design.

Examples

• Public AI services (Mistral, Openai, Grok, Omissimo, etc.)
• AI services contracted by the company from public service publishers or specialised players
• Internal chatbot

Associated security risks

• Sending sensitive data (documents, confidential data, personal data, etc.) to the AI service and losing control over this data.
• Training models on confidential data sent by users, which can lead to leaking this data to a user who should not have access to it.

Measures to implement

• User awareness
• AI charter
• Blocking services accessible from the company’s information system
• Contract with suppliers including security and confidentiality clauses for user-transmitted information
• Traffic inspection and identification of confidential data using regular expressions
• Dedicated instance for the company, fine-tuned or enriched by a RAG with company data (not very sensitive), allowing the LLM to be contextualised to the user’s context.

“AI Augmented” Application

The various editor solutions, in SaaS or deployed internally, are gradually enriched with functions based on LLMs, i.e. an agent on the application side that consumes an LLM with prompts designed by the editor on the data processed by the application. The editor enriches its solution within its own security model. On the user side, there is no change in usage, the application is simply enriched with new functions, for example synthesis, intelligent suggestions, translation, etc.). LLM processing can be done locally or consumed on external services.

In this use case, the publisher or application manager is responsible for data security and processing via the LLM; the user has no control and the use of these features is integrated into their usual usage. We remain in a classic security management framework, the application manager (internal or external) is the guarantor of the security of the data they process in the application. The application is enriched with new features and complexity increases, but the security model is preserved.

Examples

• Messaging and video conferencing service with AI features, for example real-time translation, discussion synthesis, automatic meeting minutes etc.
• Any ‘AI wizards’  in SaaS application

Associated security risks

• Insufficient segmentation of access rights to data in the application, allowing bypassing of usual application access controls. This is the case when the agent has a high-privilege account (to simplify and accelerate the development of features) or when access restriction is not implemented at data level.
• Prompt injection into the application
• Dependence on an uncontrolled supply chain
• Data leakage to a subcontractor

Measures to implement

• Security clauses in contracts
• Security insurance plan for application provider
• Review of subcontractor dependency chains
• Disabling unnecessary AI functions
• Deep isolation of sensitive applications

Agentic IA

We will now look at actual ‘Agentic AI’. In these cases, the agent is at the centre of the workflow. The agent becomes an orchestrator of resources. It has several roles, in particular:

• Capturing user expectations and triggering the sequence of actions
• Retrieving the necessary data to contextualise and process the request
• Sending data and instructions to a LLM to find the sequence of actions to be performed
• Managing iterations with available services and LLMs to best handle the request
• Triggering actions on accessible services
• Obtaining (eventually) user validation to validate actions
• Providing visibility to the user on actions performed and results obtained

To properly understand the risks, it is necessary to look at different types of agent implementations.

Agents integrated into local applications

Applications are gradually being enriched with the ability to connect to an LLM service. Generally, this is done via APIs to LLM services or locally on the machine. In this case, the application will integrate an agent and incorporate its use into the usual application experience. The framework is equivalent to that of an enriched SaaS application, but the configuration and calls to the LLM are made from the user’s workstation. The functionality can be native or installed in the form of a plugin.

Examples

• Microsoft Copilot AI agent
• AI function in office applications (OnlyOffice, Joplin, email client, etc.)
• Apple intelligence

Associated security risks

• Loss of control over data processed by adding connectivity functions to third-party services (be careful with default tool configurations)
• Risks are similar to “cloud” functions in applications, allowing cloud storage or sharing, often configured by default
• Leakage of LLM authentication secrets (Bearer Token)

Measures to implement

• User awareness
• Application configuration controls
• Validation of applications on workstations and smartphones
• Monitoring and inspection of network and application flows
• Local management of secrets

Generalist or Specialized Local Agents

Unlike the previous use case where the application is simply enriched with LLM functions, agents are applications whose primary goal is to integrate LLM functions into a workflow. The risk model is similar, but by nature, the functionalities are much richer and focused on optimising the consumption of LLM services. For example:

• Configuration of multiple LLM services in parallel
• Personalisation of system and user prompt templates by the user
• Integration of local or remote MCP services to enrich the data accessible to the agent
• Cost control function
• Optimisation of requests and context management

These agents can be generalist or specialised. In particular, this type of agent is widely used by developers within their IDE . In this context, security management relies on the user and the local configuration of tools. Capabilities may be extended with marketplace, like plugins to add connectors to external services or capabilities. The complexity of configurations, the lack of proven and hardened standards due to the relative novelty of these tools generates many risks, on an application directly run on user workstation, with all their rights.

Examples

• Generalist agents: Goose
• Specialised agents: Claude desktop, Cursor, Shai, Github Copilot, Continue, Kilo Code

Associated security risks

• Connection to third-party services without controls via marketplace (MCP connector for third-party services)
• Uncontrolled access to local file system
• Sending confidential data to third-party services (business data, secrets, .env file, etc.)
• Management of local secrets (Bearer token)
• Sharing credentials with third-party services (via OAuth mandate, etc.)

Measures to implement

• User awareness
• Application configuration controls
• Software testing and validation
• Sandboxing of agents
• Protection of secrets (environment file in development directories)

Remote Agents

Remote agents, like local agents, are applications that connect different resources (LLM, RAG, third-party services), packaged within a web application, accessible to the user through their browser. All chatbot services are gradually integrating these capabilities to enrich their service by connecting to third-party services. The operation is similar to local agents, but outside the user’s workstation.

In this case, the main challenge is managing access to third-party services and the resulting secrets. Since the agent is the focal point of the architecture, entrusting its management to a third party requires granting them access rights to third-party services to capitalise on the agent’s functionality.

In the example above, the user must grant the agent an access mandate to consume the MCPs that allow access to application services. Today, most of these mandates are managed by OAuth2 delegations, with the user authorising the agent to use these technical delegations to access applications.

Examples

• ChatGPT, MistralAI
• Agents deployed internally

Associated security risks

• Leakage of authentication secrets to sensitive applications of data
• Centralisation of secrets to access remote services
• Opening of network flows between sensitive applications and agent services

Measures to implement

• Architecture to limit network exposure
• Network inspection
• Application monitoring
• Authorisation and access control management
• Restriction of access rights to need-to-know for each task

Workflow agents

Workflow agent tools are designed to build AI workflows. They may be local or remote. While all wrong behaviours listed above remain possible in this model, the workflow structure  splits the workflow into small manageable parts, allowing:

• Limit of each agent’s access rights to the required sub-set of data for performing its tasks
• More deterministic approach for human control over the process
• Unitary testing for each parts
• Repeatability of the process (workflows are defined ‘as code’)

In this case, the workflow is built and operates as an automation under the control of a project team in charge of aligning the workflow with business processes. The configuration of the workflow management tools is the key to controlling the process. The orchestration platform manages the secrets and flow to resources, so it need to be managed with proper attention as any orchestration platform.

Examples

• N8N, Langchain, Zapier, Flowise AI

Associated security risks

• Increase in complexity of the workflows and interconnection
• Configuration issues
• Leak of access token
• Exposure of sensitive resources
• Shadow orchestration platforms deployed by users
• Access to temporary artifacts by platform administrators

Measures to be implemented

• Architecture to limit network exposure
• Network inspection
• Application monitoring
• Authorisation and access control management
• Secrets management
• Restriction of access rights to need-to-know for each task

Perspectives and problems to be solved

MCP and secret management

Secret management is at the heart of the problem of deploying agent-based AI. Since LLMs are not deterministic, it is necessary to constrain access rights in terms of scope and duration for LLMs, in order to limit their access to only the data and functions required to perform tasks. It is essential to identify the reliable blocks that will act as intermediaries to grant access, particularly for MCP servers. One of the challenges is to rely on existing access rights matrices without re-implementing an additional layer of rights management for MCP servers and agents, but instead implementing mechanisms to limit access dynamically as needed.

Existing or emerging standards (OAuth2, JWT, SAML, SPIFFE/SPIRE, OPA, Cedar, etc.) partially address some of these challenges, but at the cost of high management complexity, without a reference implementation compatible with all current solutions, and in a rapidly evolving market.

Human in the loop

Beyond secret management, LLMs are unpredictable because they are non-deterministic. One of the questions to be resolved is how to include humans in the decision-making chain of an agent-based process to ensure that this inherently unpredictable behaviour does not generate risks for organisations. Today, this control, known as ‘human in the loop’, is based on the agent’s internal mechanisms and the limitation of secrets shared with it by the user. Obviously, this mode of operation is not compatible with sensitive processing.

In the future, it will be necessary to build agents that offer a high level of trust, provided by trusted editors or communities, auditable and audited, ideally open-source, to entrust these agents with performing operations on a company’s information system. In parallel, it will be necessary to develop independent agent control mechanisms that ensure sandboxing, filtering, access management, and traceability functions, allowing the responsible user to master their interaction with the information system.

Towards the end of the web browser as a access vector to the information system

For about 15 years, the web browser has been the user’s entry point to information systems. While the functional richness of browsers is immense, the attack surface they expose is just as great. Browser security, even if it is perfectible, is one of the pillars of modern security, and browser editors and communities devote a significant part of their development and maintenance efforts to maintaining the level of security and managing threats.

AI agents are changing this access paradigm to the information system by providing users with dynamic and adaptive interfaces, enriched with high-value contextual functions, which is already causing a revolution in usage and the daily lives of users. It is likely that tomorrow’s browser will be an AI agent, and even more likely that current browsers will gradually become AI agents, integrating all identity and authorisation management standards under user control.

This accelerator has been a game-changer for the 16 startups that participated. The program’s focus on technical guidance, business strategy, and mentoring has yielded impressive results, with participants such as CryptoMate and AzurSafe achieving significant milestones and successes.

“OVHcloud was the direct solution to our scalability, cost, and performance crises. Bare Metal servers are our key differentiator, giving us the raw, dedicated processing power needed for our financial engine and AI agents,” said Alan Boryszanski, co-Founder of CryptoMate. “The Startup Program’s support and credits were vital, giving us the financial breathing room to migrate and optimize our complex architecture without disrupting our 10x growth.”

Similarly, AzurSafe has surpassed $90 billion in transaction value monitored across more than 30 blockchains, highlighting emerging fraud trends and providing real-time insights using advanced AI and ML technologies. “The precision of our fraud detection tools has been approved, audited, battle-tested, and endorsed by experts in the financial and investigative industries,” said Sam Dabiri, Founder and CEO of AzurSafe. “We are preparing huge projects that will completely redefine the landscape on an international scale.”

Kavodax, another participant, has launched in 30 countries and is in discussions with VCs involved with the Accelerator.

We would like to extend our gratitude to our partners who made this program possible, including Alchemy, Degen House, Crypto Mondays London, Super Team Solana, Fintech District, and Dysnix as well as the delivery partners Link Innovations and Empact Ventures. Their expertise and support have been invaluable to the success of our participants.

In fact, Dysnix has already been able to deliver tangible value to Mira Network, another participant. Dysnix is providing DevOps services to Mira Network to aid their migration from another hyperscaler in a short timeframe, following an infrastructure audit. The outcome of this collaboration has been better infrastructure scalability and significant cost optimisation.

“The OVHcloud Startup Program Fast Forward Blockchain and Web3 accelerator has been a resounding success, and we are proud to have played a role in the growth and development of these innovative startups,” said Philip Marais, Global Startup Program Director at OVHcloud. “Our program is designed to provide founders with the acceleration they need through unique go-to-market support to allow them to thrive in the blockchain and Web3 ecosystem, and we are thrilled to see the impact it has had on our participants.”

“The blockchain and Web3 ecosystem is rapidly evolving, and it’s essential for startups to have the right support and resources to succeed,” said Omar Abi Issa, Global Sales Director for Blockchain, Web3 and AI at OVHcloud. “Our program is committed to providing the necessary tools and expertise to help startups overcome the complex challenges of this landscape and achieve their full potential.”

As we look to the future, we are excited to continue supporting the growth and development of blockchain and Web3 startups through our OVHcloud Startup Program. With our expertise, resources, and network of partners, we are confident that we can help these innovative companies achieve their full potential and make a lasting impact on the industry.

Look out for future blog articles covering interviews with our Blockchain and Web3 Accelerator participants or find out more about the Startup Program below.

If you’re a startup looking to transform your business, we encourage you to join the OVHcloud Startup Program or contact OVHcloud to discover how our solutions can support your journey!

The key to achieving this vision lies with YOU, our valued members of OVHcloud’s unique data sovereign ecosystem, including startups, scaleups, incubators, accelerators, venture capital companies, government agencies, technology partners, and other enablers. Together, we are united around a common vision of data freedom, innovation, and mutual growth.

Global Report 2025: 10 Years of Impact

To capture the essence of our unique ecosystem, we have compiled a comprehensive report, “Global Report 2025 – 10 Years of Impact”. This report showcases key stories from our ecosystem, including:

• Our support for Harfanglab, a French scaleup that’s developed cutting-edge technologies to anticipate and neutralise cyberattacks, raising almost €30m and leveraging OVHcloud and the Startup Program to drive innovation, data sovereignty, and cybersecurity excellence.
• The success of Internxt, a Southern Europe scaleup alumni, which has become a recognized privacy-first alternative to mainstream cloud providers, offering secure, user-centric, and environmentally sustainable file-sharing and storage solutions that protect user privacy and data sovereignty.
• The journey of female founders Jeanne Le Peillet and Cecile Doan, who developed a collaborative design SaaS solution, Beink Dream, selected for the France 2030 initiative.
• The acquisition of Startup Program alumnus OpenIO by OVHcloud, which has become our high-performance object storage solution.

“OVHcloud is a great partner if you are looking for a long-term, reliable, affordable and robust provider. The synergy between Internxt’s mission to protect user privacy and OVHcloud’s commitment to data sovereignty has been pivotal.”

Fran Villalba Segarra Founder & CEO at Internxt

The Startup Program: A Decade of Growth

The report also highlights the Startup Program’s journey over the last decade, including how we operate, our partnerships with incubators, accelerators, venture capital companies, and other enablers, what sets us apart, and how we have successfully supported over 5,000 members to date.

Key Statistics

Personalised Support

What sets our Startup Program apart is our personal touch. As Philip Marais, Global Startup Program Director at OVHcloud, explains: “You’re personally onboarded by a manager in your region, have free support from our engineers to solve technical and migration issues, and access to our unique ecosystem to grow your business.”

Download the Report

To learn more about our ecosystem, our plans for the future, and the impact we can have by 2035, download the “Global Report 2025 – 10 Years of Impact” now.

Our 5000+ startups’ journey with OVHcloud highlights how the right cloud partnership can help overcome challenges, achieve sustainable growth, and scale globally. If you’re a startup looking to transform your business, we encourage you to join the OVHcloud Startup Program or contact OVHcloud to discover how our solutions can support your journey!

We at OVHcloud are committed to providing secure and professional email services that meet the latest industry standards. To boost security, we’re disabling TLS 1.0 and 1.1 protocols on our Exchange solutions, in line with international standards.

Are you using a recent and updated email client? You don’t need to do anything; all email clients have already been updated and support the latest TLS (1.2). Action is needed only if you’re running a very old version.

We’re ditching older TLS versions and stepping up security across OVHcloud Exchange services. This blog will cover what’s changing and the measures we’re taking to keep your data safe. 

TLS 1.0 and 1.1 deprecations

To improve security and service quality, we’re disabling TLS 1.0 and 1.1 on all our OVHcloud Exchange solutions.
While some Microsoft systems may still use them, these TLS versions have security holes and were officially deprecated in 2021. Plus, they are already disabled on most Microsoft services, including several Exchange options.

Single-standard supported protocols

Our goal is to apply the same configuration across all infrastructure. Since these protocols are already inactive on most of our servers, updating will standardise our setups and elevate security.

Supported ciphers

We’re also making adjustments to ciphers, so only the following will be supported:

• “TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384“
• “TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256“
• “TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384“
• “TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256“

Keep in mind, only older operating systems (outdated printers or unsupported systems) might have issues.

Customers can use the SSL Labs tool to see which encryption protocols their machine supports.

We use the best practices from the 2020 version 1.6 guides, see here.

HSTS protocol activation

We also use the HTTP Strict Transport Security (HSTS) protocol to keep connections between customers and OVHcloud Exchange servers secure.

This protocol helps to:

• enforce TLS usage by blocking unencrypted connections;
• protect against Man-in-the-Middle (MITM) attacks and block redirects/downgrades to unsecured HTTPS connections;
• automatically switch from HTTP to HTTPS for higher user security.

OVHcloud customers won’t notice this update, which will be automatic—no action needed.

Exchange update management

Monthly update process

Microsoft releases security updates for Microsoft Exchange Server every Patch Tuesday. OVHcloud applies these patches every month to bolster security for its Exchange solutions.

Our update process

• The 2^nd Tuesday of each month: Microsoft update release.
• Microsoft partnership: Thanks to our strong partnership, we have access to detailed information on patches and product releases. This gives us a better idea of how much work the next update will involve, so we can plan ahead.
• Vulnerability severity analysis:
  • Moderate risk → Maintenance is planned and staggered to minimise service disruptions.
  • High risk → A dedicated team starts maintenance right after the patches are released.

Update notifications

• PRIVATE solution customers are notified at the start and end of updates.
• RESELLER, HOSTED, MXPLAN, TRUSTED, and EMAILPRO customers can use Exchange’ clustering to track maintenance progress on the OVHcloud status page.

Real-Time monitoring and protection

We use several monitoring tools, developed in-house or provided by third-party vendors, to:

• monitor the exposure of OVHcloud Exchange services on the internet;
• detect vulnerabilities and unusual activity in real time;
• generate alerts and reports for instant analysis and troubleshooting.

Advanced spam protection

Our OVHcloud Exchange solutions include a European anti-spam system that filters messages before they reach your inbox.

Benefits of spam filtering:

• advanced detection of fraudulent and phishing emails;
• smart filtering based on machine learning;
• significant decrease in spam and malicious emails.

HTTP request management update

Host Header Removal

We’re currently fixing a server issue related to incorrect HTTP Host header usage. An invalid HTTP host header in a web request causes the server to immediately abort the request—this is specific to HTTP 1.0.

Server Header Removal

The HTTP server stops sending the header.

To recap…

We’re upgrading OVHcloud Exchange security by phasing out less secure TLS 1.0/1.1 protocols, bringing it in line with internationals security standards.
Regular updates, HSTS activation, continuous monitoring, and advanced anti-spam protection guarantee a secure, high-performance Exchange environment for all our customers.

Got questions about this update? Reach out to our technical support team.

This article is primarily intended for an international audience of networks professionals, information security specialists, security researchers and technical stakeholders. Whether or not you belong to the target audience, but particularly if you do not, please be mindful of your conclusions.

Table of Contents

• 1. Introduction
• 2. Carpet-bombing is more popular than ever
• 3. The rise of packet rate attacks: billion(s) of packets per second
• 4. Ever-growing hyper-volumetric attacks: 4 Tbps reached
• 5. Institutional and residential ISPs spoofing
• 6. Operation PowerOFF and consequences
• 7. Conclusion and closing words

1. Introduction

Welcome to this brief retrospective about the DDoS attack landscape in 2024, as seen from OVHcloud’s vantage point.

Like any other cloud provider, we deal with DDoS attacks on a daily basis, automatically detecting and mitigating hundreds of attacks each and every day. We operate our own worldwide anti-DDoS infrastructure, built from systems designed and developped internally. To date, we have more than 50 Tbps of total mitigation capacity, located at the edge of our network as well as in dedicated scrubbing centers, for which we keep adding more capacity each year to keep up the pace.

Thanks to our global backbone and numerous points of presence, we do have a sensible view of Internet traffic and trends, especially when speaking about network-layer DDoS attacks. That’s why we wanted to expose and discuss several topics we encountered during the year, in the hope you may learn something or find it useful for your own sake.

Context aside, let’s dive into this retrospective: what a year! 2024 was definitely an important turning point in DDoS history, at least from our point of view. From good’ol DDoS techniques coming back at scale, to several record-breaking attacks, we’ve seen quite a lot, and no one doubts that 2024 events will be the main driving factor for anti-DDoS infrastructure planning in the coming years.

2. Carpet-bombing is more popular than ever

During the year 2024, we observed a sudden increase of attacks leveraging a technique known as “carpet-bombing”. This attack technique is named after a brutal warfare method which consists in methodically bombing every bit of surface of a large area. Similarly, “carpet-bombing” in our context refers to attacks targeting many more IP addresses than those servicing the actual target.

Carpet-bomb attacks are used in an attempt to evade anti-DDoS systems. This is because they are much harder to detect and mitigate automatically: by sending a few hundreds megabits per second per IP, attacker can reach huge volumes while evading (at least partially) detection heuristics and possible mitigation actions. Simply put, instead of trying hard to bomb a target, just bomb the whole area around it.

By targeting a large number of closely-related IPs (e.g., belonging to a larger prefix), attackers rely on common design characteristics of many networking infrastructures: you generally want to assign an address range to a physical or logical part of your infrastructure for several reasons. Briefly, this is often required because of technical limitations on networking devices and appliances, as well as what is humanly possible to understand and manage: whether for hardware or humans, you cannot store millions to billions entries in routing table, access control lists, etc. At some point, you must aggregate your resources.

Back to the main topic, carpet-bomb attacks are a double-edged sword: the part of the attack possibly reaching your final target will probably not be powerful enough to take it down, but you take a better chance at evading defenses. This is because it’s much more difficult to identify with confidence what is legitimate from what is not, but also to scrub traffic without impacting legitimate users. In the end, the total attack traffic leaking defenses may impact a significant chunk of the hosting infrastructure, even if traffic to any single destination IP would not have been enough to take it down.

2024 has been a turning point in carpet-bomb trends from our point of view. Attackers started to leverage this technique more and more often, with mixed results, and led us to rethink how to deal with such attacks. For some times now, we are testing and calibrating our solution to the issue, but need to treat carefully: facing such a radical threat may lead to actions which could be impactful for other customers. There’s a difficult balance between sensitivity (i.e., make sure you don’t detect or mitigate too much) versus specificity (i.e., make sure you don’t miss anything notable). We will keep working hard to address the matter and minimize disruption.

3. The rise of packet rate attacks: billion(s) of packets per second

In June 2024, we published a blog article titled “The Rise of Packet Rate Attacks: When Core Routers Turn Evil”.¹ This article was presenting our findings related to small core routers participating in DDoS attacks, and was a byproduct of our investigations about a concerning trend with packet rate attacks. Readers should refer to the cited article to have a detailed explanation of how they work, and why these attacks remain a longstanding threat.

Since the end of 2023 and beginning of 2024, we noticed a large increase of packet rate attacks both in frequency and intensity, with intensity reaching an all-time high at the end of summer.

During August, we dealt with more than 50 packet-rate attacks rating over one billion packets per second. Note that the highest publicly known packet rate attack at this time was the 840 Mpps attack we mitigated in April of the same year.

However, this attack campaign not only reached the billion packets per second milestone, but actually went much higher with packet rates up to 1.9 billions packets per second. Such a rate was mind-blowing for our teams, and rightly so! A symbolic threshold was not only reached, but largely exceeded. Since then, several organizations reported observing 1+ Gpps attacks and more: for instance, Cloudflare reported rates greater than 2 billions packets per second ² in an attack campaign which occurred just a few days after the attack campaign targeting OVHcloud and its customers, while Global Secure Layer reported a single 3.15 billions packets per second attack at the same time.³

Before moving on to the next topic, a notable fact related to this attack campaign is that it was heavily leveraging carpet-bombing techniques targeting up to thousands of IPs over hundreds of customers. Attackers are definitely not scared about trying to impact a lot of people in an attempt to take down a specific service, despite the increased attention this kind of attack generates.

4. Ever-growing hyper-volumetric attacks: 4 Tbps reached

During the month of September, we were thrilled to mitigate our very first 3+ Tbps attack ever. However, it was just a warning shot for what was to come: another massive attack campaign during October. Although we had only seen a handful of 2+ Tbps attacks in OVHcloud history, this two weeks campaign led to more than 40 attacks ranging from 2 Tbps up to a record-breaking (at the time) 4.2 Tbps attack.

Since most attacks exhibited similar characteristics, we will focus on the biggest one. At the time it happened, this attack was the largest bit rate attack ever (compared to previous publicly known records). It leveraged multiple attack vectors at once : TCP ACK flood accounted for ~60% of the total traffic, direct-path UDP flood accounted for 20%, while the remaining 20% was performed with various UDP reflections (mostly DNS).

We identified approximately 150,000 source IPs, mostly owned by residential ISPs from Europe and North America. For the most part, attackers did not seem to leverage source spoofing, since our data shows that traffic from IPs belonging to an ISP came from direct peering with said ISP or a related exchange/transit provider. However, the surprising amount of unique source IPs and the significant volume going through exchange/transit suggest there is possibly some undetected spoofing. Total count of unique source IPs should thus be considered with a lot of salt.

One notable thing also is that few tens of attacking IPs were sending 1+ Gbps each, which suggests high-grade residential connections with lot of upload bandwidth. Moreover, according to our analysis, all the direct-path attack traffic (approximately 80% of total) was originating from a Mirai-based botnet.

All these findings are in-line with conclusions from various cloud providers and analysts, showing the continuously growing threat of compromised IoT devices and home routers. 8 years after the initial release of Mirai code, this botnet family is still actively used to attempt disrupting the online economy.

Readers should note that since the 4.2 Tbps attack we just discussed, several actors reported even higher rates such as the 5.6 Tbps at Cloudflare in late 2024 ⁴, or the more recent 6.5 Tbps attack reported by Nokia in February 2025.⁵

5. Institutional and residential ISPs spoofing

Last but not least, we also observed another growing trend during the year: the large-scale spoofing of major residential ISPs.

We are used seeing many IPs belonging to residential ISPs participating in attacks, as a lot of compromised devices are located within those networks (“I see you.. Internet of Things!“). However we observed a growing number of attacks using those IPs, but originating from far abroad: for instance, we found traffic using IPs of major French ISPs (Orange, SFR, Bouygues, Free) but originating from the US west coast or Asia-Pacific, and coming through unrelated peering partners (despite us directly peering with said ISPs!). In this situation, source IPs are obviously spoofed.

We also observed the same technique being used by spoofing large institutional actors, such as state actors or government-backed organizations which own several Internet prefixes.

An explanation about these attacks is that attackers are trying to leverage hypothetical bypasses in defense layers such as lax rate control, allow/forward rules, and others. This makes sense because, as a major european actor based in France (with a significant business in France), we could have considered being less strict with French IPs. It’s also much harder to react against an attack that could lead to actions shutting down legitimate traffic as well, which will be the case if one decides to deny entire ranges against such attacks (we don’t do that!).

Moreover, we sometimes have customers asking us to disable any DDoS protections for their IPs, because “we can trust them”. But that’s not how the Internet works. As a provider, protecting yourself against external spoofing is maybe doable on paper, but in reality, it’s close to impossible. That’s why we have security measures, and bypassing them even with the best intent will often prove itself as a bad decision, not only for the requesting customers but also for any other services which could be impacted because of this.

Finally, this issue highlights a crucial need for DDoS attacks remediation: all network operators have a part to play in preventing IP spoofing. This shall be done at two levels: at server/switch level by locally preventing IP spoofing from a specific host, and at the network level by preventing outbound traffic with source IPs not owned by the network operator.

6. Operation PowerOFF and consequences

Operation PowerOFF is an ongoing joint operation by several law enforcement agencies around the world, specifically aimed at shutting down DDoS-for-hire operations. At the beginning of November 2024, they closed the infamous dstatc.cc platform, which provided means for attackers to benchmark the capabilities and effectiveness of DDoS attacks. Along with this closure, multiple DDoS-for-hire websites were closed, botnets dismantled, and cybercriminals arrested.⁶

This event led to a huge decline in frequency and intensity of network-layer DDoS attacks targeting OVHcloud infrastructures and customers. For some time, our attack statistics were quite below their usual levels of the past two years. This fact proves the effectiveness of global coordinated actions to take down botnets, and should call for more.

7. Conclusion and closing words

In the past, network-layer DDoS attacks were often dismissed as a minor inconvenience, or even a solved problem. However, as year 2024 proved, they still represent a growing and longstanding threat which must be addressed seriously. That’s one reason why DDoS attacks are often stated in threat reports emanating from various actors, such as a recent threat report published by the French national information security agency (ANSSI) in February 2025.⁷

Although application-layer attacks (especially HTTPS) are more popular nowadays for several reasons, no one should dismiss network-layer attacks as an unsignificant risk. If dealing successfully with billions of packets per second or several terabits of traffic may seem like an achievement for a few of us, it is a very difficult challenge for many. Be prepared!

Fighting against these threats must be done at both an individual and a global level. Coordinated efforts are a necessity in today’s DDoS landscape and will probably be even more important in years to come. It may sound scary, but remember it actually has a positive impact as demonstrated once again by Operation PowerOFF.

Thanks for reading.

1. https://blog.ovhcloud.com/the-rise-of-packet-rate-attacks-when-core-routers-turn-evil/ ↩︎
2. https://blog.cloudflare.com/ddos-threat-report-for-2024-q3/ ↩︎
3. https://globalsecurelayer.com/blog/unprecedented-3-15-billion-packet-rate-ddos-attack ↩︎
4. https://blog.cloudflare.com/ddos-threat-report-for-2024-q4/ ↩︎
5. https://arstechnica.com/security/2025/03/massive-botnet-that-appeared-overnight-is-delivering-record-size-ddoses/ ↩︎
6. https://www.europol.europa.eu/media-press/newsroom/news/law-enforcement-shuts-down-27-ddos-booters-ahead-of-annual-christmas-attacks ↩︎
7. https://www.cert.ssi.gouv.fr/cti/CERTFR-2025-CTI-001/ ↩︎

Today, we’re going to embark on a journey of discovery, and unveil our latest product: Bare Metal Pod.

You know us for the services we provide: bare metal servers, managed and unmanaged virtualisation platform, our 40+ public cloud services, domain names and telco.

This is just the tip of the iceberg, and to understand why we built and now offer Bare Metal Pod, we have to dig deeper.

So let’s begin this journey exploring the origins of Bare Metal Pod, and in later articles we’ll cover the more technical details—there’s a lot to touch on.

The OVHcloud way: more than just servers

As a cloud services provider, we supply the different platforms mentioned above. But most importantly, we have to take care of the infrastructure dedicated to these services, from the buildings, power and cooling to the software stack and automation required.

And we’ve been doing just this since 2001. It all started with the opening of our first datacentre in Paris, then building our own servers the next year, and our proprietary water-cooling solution the year after that.

At the core, we are all about efficiency, automation, and sustainability:

• Repurposing buildings as datacentres
• Designing our own servers to optimise performance and cost
• Maximising cooling efficiency to cut waste
• Automating everything to reduce errors and delays

And, in all modesty…. we’re pretty good at these.

Optimising datacentres like a pro

Basically, building our own servers in our Croix (FR) and Beauharnois (CA) plants means packing a ton of servers into a square metre. We’re talking about 4 custom racks, each hosting 48 servers, all in just 3 sq.m and using up to 160kW of 12V DC power. This gives us a server density of about 5000W per sq/ft, which beats out 90% of the industry.

And on top of that, we’ve got our proprietary water-cooling system—we save energy by not using AC for our servers. To further optimise air cooling, each of our rack is equipped with a large condenser (we call it a chilled door) at the rear of the rack, dissipating regular server heat in our water system. This keeps the datacentre comfortably warm for our staff and the network equipment, and extends hardware lifespan (less maintenance, fewer replacements, fewer outages….so more savings).

In addition to the physical optimisations we’ve just mentioned is our automation system. When a server or a cluster of servers have been assembled and tested in our plant, it’s sent to the datacentre, racked and connected to power, network, and water-cooling systems by our DC staff.

And from there, everything is automated. From server power management, discovery, testing, and readiness checks, to the moment it’s selected by a customer using their Control Panel, and then configured. No human interaction is required, meaning no delay and no error.

And these operations have been optimised and refined for over 20 years.

Enter Project Gold-o-rack

So in June 2023, a small team was assembled to review, analyse and build a new version of this system. We had 3 goals:

• Provide customers with dedicated on-premises autonomous racks
• Offer custom-built, plug-and-play Bare Metal Pods
• Upgrade the automation and security of our own datacentres

And that’s how Project Gold-o-rack came to be—a tribute to Goldorak (Grendizer), the legendary 70s anime mecha that crushed its enemies with style. Like its namesake, our system is powerful, autonomous, and unstoppable.

Using opensource technology was a must, as we absolutely can’t do without transparency and community support. So we went for OpenStack, Netbox, Grafana, and developed our own network management and automation system, and much more.

By September 2023—just three months later—we had a fully functional 24U rack, deployable and operational in 25 minutes. That’s not just fast—that’s insanely fast.

Security was a top priority since these racks would be installed in third-party datacentres. We quickly applied for SecNumCloud qualification, leveraging our existing compliance expertise.

Then, it hit us: why not offer this as a full-fledged product? And that’s how Bare Metal Pod came to be—dedicated, secure, and fully automated.

We structured the product into three key components:

1. On-Prem Cloud Platform (OPCP): The autonomous rack, with its own KMS and encryption mechanisms
2. Bare Metal Pod: Built on OPCP, hosted in our datacentres, and SecNumCloud-compliant
3. Cloud Store: A software catalogue enabling automated deployment within the rack

In June 2024, OPCP was ready, just 12 months after the 1st meeting… and shortly after we got the “green light” from the ANSSI, allowing us to pursue the SecNumCloud qualification process.

And if you were at, or watched our Summit Keynote in November 2024, you definitely saw it live…

What’s under the hood?

As an autonomous rack, it contains:

• Power Distribution Units
• Network equipment for internal and external connectivity
• Servers, including a Pod Controller

There are 9 Bare Metal server models available, from 16 to 256 cores, from 128 GB to 2.5 TB of memory, up to 792 TB NVMe SSD (RAW), Nvidia L4 and L40s GPU depending on your needs.

And the best part is that you can mix and match them, to build and manage the perfect autonomous rack, while keeping full control on security and resources.

We’ve got a total of 607 models in Bare Metal Pod, enough for nearly any configuration and need. And with up to 1500 servers in a single Pod, the possibilities are endless.

And on top of these servers, we are building an automated software library: the Cloud Store. Enclosed in the Bare Metal Pod, the Cloud Store will offer the Pod admin a selection of OS, virtualisation platforms and various software that can be pushed, installed, configured automatically on the servers in the Pod. This includes built-in security, monitoring, and logging integrated in the Pod monitoring tools.

And herein¹ lies the main challenge: making sure an entire collection of software from various editors can cohabit and interact with a single, opensource monitoring platform, a KMS, and an IAM without breaking anything…

Coming up next…

That’s a wrap for now! In the next article, we’ll deep-dive into hardware, networking, and security. Stay tuned!

Some of the Bare Metal servers options:

• Scale A1 – A8: Equipped with 4th Gen Intel Xeon Gold or AMD EPYC 9004 series processors, these servers provide between 16 to 256 cores and 128 GB to 1 TB of DDR5 ECC RAM. They are suitable for:
  • Hosting SaaS and PaaS solutions
  • Virtualisation
  • Database hosting
  • Containerisation and orchestration
  • Confidential computing
  • High-performance computing
• Scale-GPU 1 – 3: Featuring NVIDIA L4 GPU cards (x2 or x4) and up to 1.2 TB of DDR5 ECC RAM, these servers are ideal for:
  • 3D modelling
  • Media streaming
  • Virtual Desktop Infrastructure (VDI)
  • Data inference

• HGR-HCI I1 – I4: With dual 5th Gen Intel Xeon Gold or 4th Gen AMD EPYC 9004 series processors, these servers provide between 16 to 72 cores and up to 2.5 TB of DDR5 ECC RAM. They are suitable for:
  • Hyperconverged infrastructure
  • Virtualisation
  • Database hosting
  • Containerisation and orchestration
  • Confidential computing
  • High-performance computing
• HGR-SDS 1 – 2: Equipped with dual 5th Gen Intel Xeon Gold processors, these servers offer between 16 to 48 cores and up to 1.5 TB of DDR5 ECC RAM. They are ideal for:
  • Software-defined storage solutions
  • Object storage solutions
  • Big data
  • Database hosting
• HGR-STOR 1 – 2: Featuring a 5th Gen Intel Xeon Gold processor with 36 cores and up to 512 GB of DDR5 ECC RAM, these servers are designed for:
  • Archiving
  • Database hosting
  • Backup and disaster recovery plans
• HGR-AI-2: Equipped with NVIDIA L40s GPU cards (x2 or x4) and up to 2.3 TB of DDR5 ECC RAM, these servers are optimized for:
  • Machine learning
  • Deep learning

(And many other options… you get the idea.)

1. My editor liked the word and I found it cool too. https://www.collinsdictionary.com/dictionary/english/herein ↩︎

myUpchar.com‘s mission is to enable healthcare awareness and access for India. They have been in OVHcloud’s Startup Program since July 2024 and are currently serving 100M patients every month.

Can you introduce myUpchar.com and its mission?

myUpchar.com is an innovative healthcare platform that aims to bridge the gap between healthcare providers and patients by delivering accessible and affordable medical advice. Our mission is to empower individuals in India to take charge of their health with expert, reliable, and timely support, particularly for those who may not have easy access to traditional healthcare services. Our core values center around trust, transparency, and making healthcare as accessible as possible for everyone.

What challenges did myUpchar.com face before partnering with OVHcloud?

Initially, scalability was a major challenge as we grew, especially with managing high traffic spikes during certain periods. Security concerns around sensitive patient data were also at the forefront, along with the cost of infrastructure. The biggest technical hurdle was ensuring that our platform could handle an increasing number of users without compromising on performance.

How did OVHcloud help you address these challenges?

With our growing user base and the increasing complexity of handling large volumes of sensitive data, we needed a cloud solution that could offer the scalability, security, and cost efficiency we were seeking. OVHcloud presented the right combination of features to meet these demands.

We are using OVHcloud’s scalable compute instances and their public cloud solutions to ensure both performance and security. The flexibility in resource allocation and pricing structure has been a major differentiator for us, as it aligns well with our cost-conscious growth strategy.

How did you leverage OVHcloud’s Startup Program?

OVHcloud provided us with a flexible, secure, and scalable infrastructure, which allowed us to seamlessly scale our platform while reducing operational complexity. The support from OVHcloud’s Startup Program was instrumental in helping us navigate these challenges effectively.

OVHcloud’s professional services team has been excellent in helping us set up our infrastructure and optimize it as our needs evolved. Their guidance in scaling our resources and their proactive approach has helped us avoid many potential bottlenecks.

What tangible results has myUpchar.com achieved through this partnership?

Since moving to OVHcloud, we’ve seen a significant improvement in platform performance, especially during high-traffic periods. Our infrastructure is more cost-efficient, and we’ve been able to reinvest those savings into other areas like user experience improvements. Additionally, with OVHcloud’s security features, we’ve been able to enhance user trust, which has boosted our retention rates.

These improvements in performance and cost-efficiency have directly contributed to our ability to scale quickly while keeping our operations lean. The enhanced security has also improved user satisfaction and encouraged more people to use our platform.

What’s next for myUpchar.com?

Our goal is to continue growing myUpchar into a leading healthcare platform in India, expanding both our service offerings and our user base. We envision leveraging the cloud ecosystem to provide even more personalized and scalable healthcare solutions in the future.

As we grow, we foresee challenges around maintaining service quality at scale, especially with a larger user base. Cloud technologies will be essential in helping us maintain flexibility, optimize resource usage, and continue to enhance security as we expand.

What advice can you give to fellow start-ups?

My advice would be to invest in a flexible, scalable cloud infrastructure early on, and don’t hesitate to leverage startup programs that offer tailored support. Cloud solutions can save you a lot of headaches down the road, particularly around scalability and security. Finding a provider with strong support and customizable pricing structures can make a huge difference in managing costs and growing efficiently.

Our collaboration with OVHcloud has been crucial in overcoming many of the challenges we faced as we scaled myUpchar.com. With their support, we have been able to improve platform performance, reduce costs, and enhance security, all of which have contributed to our success.

I encourage other startups to explore the OVHcloud Startup Program—it offers great tools and support to help startups grow efficiently and securely.

Join the OVHcloud Startup Program

myUpchar.com’s success highlights the transformative power of leveraging OVHcloud’s Startup Program. Are you ready to take your startup to the next level? Join a growing community of innovators and benefit from tailored cloud solutions, expert guidance, and a global ecosystem.
Learn more about OVHcloud’s Startup Program and get started on your journey today!

Several month ago we discovered Falco, a Cloud Native near real-time threats detection tool, and we saw how to install it on an OVHcloud MKS cluster.

Today we will connect our Falco instance to a MKS cluster in order to retrieve Kubernetes Audit Logs events and watch if everything is OK in our cluster.

Concretely, in this blog post we will:

• deploy an OVHcloud LDP (Logs Data Platform)
• create a data stream into this LDP
• connect an OVHcloud MKS cluster to the data stream (to send Audit Logs into it)
• use the k8saudit-ovh Falco plugin to retrieve in realtime the Audit Logs of a MKS cluster
• test a rule and detect security events based on MKS audit logs activity

Prerequisites

This blog post presupposes that you already have a working OVHcloud Managed Kubernetes (MKS) cluster, and a running instance of Falco.

If it is not the case, follow the Near real-time threats detection with Falco on OVHcloud Managed Kubernetes blog post.

Deploying a Logs Data Platform (LDP)

LDP is the managed platform for collecting, processing, analyzing and storing your logs of the OVHcloud products. To be able to access to our Kubernetes clusters Audit Logs we need to deploy a LDP.

Find more information on our dedicated LDP page.

We can deploy a LDP through the OVHcloud Control Panel and the API. In this blog post, we will deploy it through the Control Panel.

First, you have to log in to the OVHcloud Control Panel, click on the Bare Metal Cloud section located at the top in the header and then click on the Logs Data Platform in the sidebar.

Choose the LDP plan you want: Standard (free) or Enterprise one, depending on your needs.

Select a region (North America or Europe). We will choose “GRA” for this blog post, click on Order button and follow the instructions.

After several minutes your LDP will be created.

Refresh the page, click on the new deployed LDP, then enter a password and click on the Save button.

Creating a Data stream and retrieving the Websocket URL

Our Kubernetes Audit Logs will be stored in a data stream so click on the Data stream tab and then click on the Add data stream button.

Choose a name of the data stream. On my side I like to call it with the name of my MKS cluster following by “-audit-logs” to know easily what it is this data stream for. My MKS cluster’s name is “my-rancher-mks-cluster” so let’s name it “my-rancher-mks-cluster-audit-logs”. Fill the description (mandatory).

The OVHcloud Audit Logs Falco plugin you will use receive the audit logs through Websocket so you need to enable Websocket broadcasting then click on the Save button.

Now, to retrieve the Websocket URL of your data stream, click on the Data stream tab, then click on the … button (located at the right in the line of your data stream), and click on Monitor in real time action.

Finally, click on the Action button and in the Copy Websocket address, then save the LDP Websocket URL somewhere ;-).

Note that the Websocket address have this kind of format: wss://<region>.logs.ovh.com/tail/?tk=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx

Connect a MKS cluster to a LDP data stream

Now we need to send the Kubernetes Audit Logs of our MKS cluster in the data stream.

For that, in the OVHcloud Control Panel, click on the Public Cloud section in the header and then in Managed Kubernetes Service in the sidebar.

Click on your Kubernetes cluster (my-rancher-mks-cluster for example), then in the Logs tab and click on the Subscribe button.

Click on the Add data stream button to visualize in real time the Audit Logs of your cluster. Then select the LDP instance and click on the Subscribe button for the data stream your created:

Retrieve the MKS Audit Logs with Falco

Falco can receive Events, compare them to a set of Rules to determine the actions to perform and generate Alerts to different endpoints.

Thanks to the k8saudit-ovh plugin, Falco can receive a new sort of Events: the Audit Logs of your MKS cluster. These events have also some rules to follow.

Concretely, when an user will execute some kubectl commands in an OVHcloud MKS cluster, Audit Logs will be generated. Falco is listening from them and depending on the configured rules, it will generate some alerts.

Let’s install or update a Falco configuration running in a MKS cluster and use this plugin.

Create a values.yaml file with the following content:

tty: true
kubernetes: false

# Just a Deployment with 1 replica (instead of a Daemonset) to have only one Pod that pulls the MKS Audit Logs from a OVHcloud LDP
controller:
  kind: deployment
  deployment:
    replicas: 1

falco:
  rule_matching: all
  rules_files:
    - /etc/falco/k8s_audit_rules.yaml
    - /etc/falco/rules.d
  plugins:
    - name: k8saudit-ovh
      library_path: libk8saudit-ovh.so
      open_params: "<region>.logs.ovh.com/tail/?tk=<ID>" # Replace with your LDP Websocket URL
    - name: json
      library_path: libjson.so
      init_config: ""
  # Plugins that Falco will load. Note: the same plugins are installed by the falcoctl-artifact-install init container.
  load_plugins: [k8saudit-ovh, json]

driver:
  enabled: false
collectors:
  enabled: false

# use falcoctl to install automatically the plugin and the rules
falcoctl:
  artifact:
    install:
      enabled: true
    follow:
      enabled: true
  config:
    indexes:
    - name: falcosecurity
      url: https://falcosecurity.github.io/falcoctl/index.yaml
    artifact:
      allowedTypes:
        - plugin
        - rulesfile
      install:
        resolveDeps: false
        refs: [k8saudit-rules:0, k8saudit-ovh:0.1, json:0]
      follow:
        refs: [k8saudit-rules:0]

This values.yaml file will install Falco with the k8saudit-ovh and the json plugins.

Install the latest version of Falco with helm install command:

$ helm install falco --create-namespace --namespace falco --values=values.yaml falcosecurity/falco

This command will install the latest version of Falco, with the k8saudit-ovh and json plugins, and create a new falco namespace:

$ helm install falco --create-namespace --namespace falco --values=values.yaml falcosecurity/falco

NAME: falco
LAST DEPLOYED: Mon Feb 10 10:15:20 2025
NAMESPACE: falco
STATUS: deployed
REVISION: 1
NOTES:
No further action should be required.

Or if you already have Falco deployed in a Kubernetes cluster, you can use the helm update command instead:

$ helm upgrade falco --create-namespace --namespace falco --values=values.yaml falcosecurity/falco

You can check if the Falco pods are correctly running:

$ kubectl get pods -n falco

NAME                                      READY   STATUS    RESTARTS   AGE
falco-6b8bc77d8b-v24jr                    2/2     Running   0          96s
falco-falcosidekick-67877d6946-4hmbn      1/1     Running   0          96s
falco-falcosidekick-67877d6946-tpjk6      1/1     Running   0          96s
falco-falcosidekick-ui-78b96fd57d-4wb6q   1/1     Running   0          96s
falco-falcosidekick-ui-78b96fd57d-v7rnm   1/1     Running   0          96s
falco-falcosidekick-ui-redis-0            1/1     Running   0          96s

Wait and execute the command again if the pods are in “Init” or “ContainerCreating” state.

Once the Falco pod is ready, run the following command to see the logs:

kubectl logs -l app.kubernetes.io/name=falco -n falco -c falco

You should see logs like that:

$ kubectl logs -l app.kubernetes.io/name=falco -n falco -c falco

Mon Feb 10 09:15:35 2025:    /etc/falco/k8s_audit_rules.yaml | schema validation: ok
Mon Feb 10 09:15:35 2025: Hostname value has been overridden via environment variable to: my-pool-1-node-921b61
Mon Feb 10 09:15:35 2025: The chosen syscall buffer dimension is: 8388608 bytes (8 MBs)
Mon Feb 10 09:15:35 2025: Starting health webserver with threadiness 2, listening on 0.0.0.0:8765
Mon Feb 10 09:15:35 2025: Loaded event sources: syscall, k8s_audit
Mon Feb 10 09:15:35 2025: Enabled event sources: k8s_audit
Mon Feb 10 09:15:35 2025: Opening 'k8s_audit' source with plugin 'k8saudit-ovh'
{"hostname":"my-pool-1-node-921b61","output":"09:15:40.698757000: Warning K8s Operation performed by user not in allowed list of users (user=csi-cinder-controller target=csi-6afb06dce281b86b7bab718b5d966dc261b2b1554941ae449519a128cb2e3fb3/volumeattachments verb=patch uri=/apis/storage.k8s.io/v1/volumeattachments/csi-6afb06dce281b86b7bab718b5d966dc261b2b1554941ae449519a128cb2e3fb3/status resp=200)","output_fields":{"evt.time":1739178940698757000,"ka.response.code":"200","ka.target.name":"csi-6afb06dce281b86b7bab718b5d966dc261b2b1554941ae449519a128cb2e3fb3","ka.target.resource":"volumeattachments","ka.uri":"/apis/storage.k8s.io/v1/volumeattachments/csi-6afb06dce281b86b7bab718b5d966dc261b2b1554941ae449519a128cb2e3fb3/status","ka.user.name":"csi-cinder-controller","ka.verb":"patch"},"priority":"Warning","rule":"Disallowed K8s User","source":"k8s_audit","tags":["k8s"],"time":"2025-02-10T09:15:40.698757000Z"}
{"hostname":"my-pool-1-node-921b61","output":"09:15:57.508657000: Warning K8s Operation performed by user not in allowed list of users (user=yacht target=my-pool-1.18051c0a88716868/events verb=patch uri=/api/v1/namespaces/default/events/my-pool-1.18051c0a88716868 resp=403)","output_fields":{"evt.time":1739178957508657000,"ka.response.code":"403","ka.target.name":"my-pool-1.18051c0a88716868","ka.target.resource":"events","ka.uri":"/api/v1/namespaces/default/events/my-pool-1.18051c0a88716868","ka.user.name":"yacht","ka.verb":"patch"},"priority":"Warning","rule":"Disallowed K8s User","source":"k8s_audit","tags":["k8s"],"time":"2025-02-10T09:15:57.508657000Z"}
{"hostname":"my-pool-1-node-921b61","output":"09:15:57.807013000: Warning K8s Operation performed by user not in allowed list of users (user=yacht target=my-pool-1/nodepools verb=update uri=/apis/kube.cloud.ovh.com/v1alpha1/nodepools/my-pool-1/status resp=200)","output_fields":{"evt.time":1739178957807013000,"ka.response.code":"200","ka.target.name":"my-pool-1","ka.target.resource":"nodepools","ka.uri":"/apis/kube.cloud.ovh.com/v1alpha1/nodepools/my-pool-1/status","ka.user.name":"yacht","ka.verb":"update"},"priority":"Warning","rule":"Disallowed K8s User","source":"k8s_audit","tags":["k8s"],"time":"2025-02-10T09:15:57.807013000Z"}

The logs confirm that Falco k8saudit-ovh plugin and the k8saudit rules have been loaded correctly 💪.

Testing Falco

In order to test Falco we need to know which rules are installed by default. In our case, as we defined it in the values.yaml file, the k8saudit-ovh plugin follow the k8s_audit_rules.yaml file. You can take a look at them in order to know them.

In this blog post we will test one of well-known default k8s audit rules:

- rule: Attach/Exec Pod
  desc: >
    Detect any attempt to attach/exec to a pod
  condition: kevt_started and pod_subresource and (kcreate or kget) and ka.target.subresource in (exec,attach) and not user_known_exec_pod_activities
  output: Attach/Exec to pod (user=%ka.user.name pod=%ka.target.name resource=%ka.target.resource ns=%ka.target.namespace action=%ka.target.subresource command=%ka.uri.param[command])
  priority: NOTICE
  source: k8s_audit
  tags: [k8s]

This rule is interesting because an event will be generated if/when an user execute commands in a pod.

Let’s test the rule!

In a tab of your terminal, watch the coming logs:

$ kubectl logs -l app.kubernetes.io/name=falco -n falco -c falco -f

In an another tab of your terminal, create a Nginx pod and execute a command into it:

$ kubectl run nginx --image=nginx

$ kubectl exec -it nginx -- cat /etc/shadow

Several seconds later, in the logs you should see this you will see this Attach/Exec to pod logs:

...
{"hostname":"my-pool-1-node-921b61","output":"09:29:46.302906000: Notice Attach/Exec to pod (user=kubernetes-admin pod=nginx-676b6c5bbc-4xc6t resource=pods ns=hello-app action=exec command=cat)","output_fields":{"evt.time":1739179786302906000,"ka.target.name":"nginx-676b6c5bbc-4xc6t","ka.target.namespace":"hello-app","ka.target.resource":"pods","ka.target.subresource":"exec","ka.uri.param[command]":"cat","ka.user.name":"kubernetes-admin"},"priority":"Notice","rule":"Attach/Exec Pod","source":"k8s_audit","tags":["k8s"],"time":"2025-02-10T09:29:46.302906000Z"}
...

🎉

Conclusion

Ensuring the security of Kubernetes clusters is important and in general we have a lot of information in the Audit Logs but we don’t use them so don’t hesitate to use this new plugin.

We installed the new k8saudit-ovh plugin in an OVHcloud MKS cluster but note that you can deploy it in a Kubernetes cluster in another Cloud provider and even in a Falco instance running locally 💪.

We visualized the logs/the events in the terminal but you can also visualize them in the sidekick UI, create a custom rule and even use Talon to execute some actions.