Automating NIS2 Compliance in Kubernetes with Kyverno: A Practical Guide

Automating NIS2 Compliance in Kubernetes with Kyverno: A Practical Guide

Guest Contributors: Cristian Klein (Elastisys)

2025 is the year when NIS2 measures will start to bite. Is your platform team ready for the challenge?

This post gives a brief overview of NIS2 in the context of platform engineering. Then it gives some practical implementation examples using Kyverno. At the end of this post, you will know how to avoid “analysis paralysis” and get started with making your organization NIS2 compliant.

Crash Course to NIS2

As many of you already know, security is hard. This is due to two factors:

  • the budget gap: security is chronically under-funded, due to it being seen as an “overhead” and not a “feature”;
  • the knowledge gap: even for a well-funded organization it is hard to create an overall threat landscape and understand where to best invest its security budget.

NIS2 is an EU Directive which aims to improve security by closing the budget and knowledge gap. It improves on a previous EU Directive – retrospectively called NIS1. NIS2 defines “essential” and “important” entities, which are organizations critical to society, such as energy, healthcare and public administration. So how exactly does NIS2 improve the overall security of such organizations?

NIS2 closes the knowledge gap by requiring all essential and important entities to report cybersecurity incidents and near-misses to competent authorities. These authorities review these reports and issue:

Note that these security measures are not just “paperwork”. They need to be documented with solid evidence, such as audit reports, reports on implementation, reports on effectiveness, screenshots, dashboards, etc.

But how does NIS2 plug the budget gap to ensure that organizations will allocate the necessary resources and implement mandated security measures? Simply put, NIS2 includes fines of up to 2% of total global annual revenue or €10,000,000 – whichever is higher – for essential entities. Important entities may be fined up to 1.4% of total global annual revenue or €7,000,000 – whichever is higher. Note that EU Member States may include additional penalties. For example, under the proposed Swedish Cybersecurity law, CEOs may get a ban on business if found to have acted negligently when it comes to cybersecurity.

As already mentioned, NIS2 is a follow-up on a previous EU Directive – retrospectively called NIS1. Already under NIS1, energy, transportation, and financial services were in scope. With NIS2, more entities are in scope, such as public administration, manufacturing, and research. Yes, your city’s mayor will need to care about cybersecurity. Furthermore, NIS2 adds ten so-called “minimum requirements”, which are expected to have a huge impact on improving the security of essential entities.

For more details on NIS2, we recommend you read these excellent posts from Elastisys on NIS2:

NIS2 for Platform Engineers

This section will help you understand the impact of NIS2 on platform engineering and platform security.

One of the most important security measures an organization needs to take under NIS2 is to perform risk management. In brief, risk management consists of:

  • Starting from a threat catalog, such as the ENISA Threat Landscape 2024 or ISO 27005:2022;
  • Listing out risks, i.e., brainstorming with experts on what could go wrong given the threats;
  • Assessing the severity of those risks, i.e., how bad those risks are if they become reality;
  • Taking measures to reduce the severity of the worst risks;
  • Collecting evidence to show that the security measures have been implemented and are effective.

When it comes to security measures, NIS2 wants you to consider organizational, operational and technical measures.

Let us make this more concrete through an example. Say you work for a healthcare provider. A core process of your organization is to keep patient journals to ensure high-quality care. Your patient journals are stored using an application, which is hosted by a Kubernetes-based application platform.

Let us now apply risk management. Your CISO (Chief Information Security Officer) opens up ISO 27005:2022 and reads that one threat is “equipment malfunction”. He gathers a team of experts to brainstorm. Your organization realizes that there is a risk for the patient journal system to go down, due to a server failure. This is a core process of your organization, so your CISO assesses the severity is high. Next, your CISO with the team of experts will consider measures to take to reduce the risk:

  • The chief of staff is tasked with implementing a method for manual journaling, so the organization can tolerate a downtime of the patient journaling application of two hours.
  • The application team is tasked with running their application replicated across at least two servers.

This is where platform engineering comes in. If you already operate a Kubernetes-based application platform, the effort required to replicate the application on two servers is significantly lower.

This sounds simple enough, but how do you make sure that application teams won’t forget to replicate?
Guardrails! You use guardrails to warn (or deny) application developers from deploying an application with a single replica. In other words, you make it easy for them to do the right thing. This is where Kyverno, a Kubernetes-native policy engine comes into play.

How Kyverno Addresses NIS2 Requirements

Kyverno allows you to enforce guardrails as policies in a declarative way. For instance, you can create a Kyverno policy that checks if a Deployment specifies at least two replicas. If an application developer tries to deploy an application with only one replica, Kyverno can either warn them during the deployment process or block the deployment altogether until the requirement is met.

Here’s a simple example of such a Kyverno policy:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-min-two-replicas
spec:
  rules:
    - name: check-replicas
      match:
        resources:
          kinds:
            - Deployment
      validate:
        message: "Deployments must specify at least 2 replicas to ensure high availability."
        pattern:
          spec:
            replicas: ">=2"

With this policy in place, your platform engineering team can ensure that all applications deployed on your Kubernetes-based platform adhere to the NIS2 minimum requirement of mitigating risks, such as server failures, through redundancy.

Practical Implementation Examples

Kyverno plays a critical role in addressing NIS2 requirements.

For example, NIS2 Article 21(2)(d) “supply chain security” can be fulfilled by enforcing image verification. Specifically, the Kyverno policy below validates that only signed container images are used in deployments.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: verify-image
  annotations:
    policies.kyverno.io/title: Verify Image 
spec:
  validationFailureAction: Enforce
  background: false
  rules:
  - name: verify-image
  match:
    any:
    - resources:
      kinds:
      - Pod
  verifyImages:
  - imageReferences:
    - "ghcr.io/kyverno/test-verify-image*"
    mutateDigest: true
    attestors:
    - entries:
      - keys:
        publicKeys: |
        -----BEGIN PUBLIC KEY-----
        
        -----END PUBLIC KEY-----

As another example, NIS2 Article 21(2)(h) “use of cryptography” can be fulfilled by making sure that all Ingresses have certificates properly configured to them. The Kyverno policy below enforces this by making sure that the field spec.tls and required annotations are properly set up.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
 name: require-ingress-https
 annotations:
   policies.kyverno.io/title: Require Ingress TLS
spec:
 background: true
 validationFailureAction: Audit
 rules:
 - name: has-tls
   match:
     any:
     - resources:
         kinds:
         - Ingress
   preconditions:
     all:
     - key: "{{request.operation || 'BACKGROUND'}}"
       operator: AnyIn
       value:
       - CREATE
       - UPDATE
   validate:
     message: "TLS must be defined."
     deny:
       conditions:
         all:
         - key: tls
           operator: AnyNotIn
           value: "{{ request.object.spec.keys(@) }}"

As another example, NIS2 Article 21(2)(a) “information system security” will likely lead to your organization implementing a principle of least privilege. In Kubernetes, this means ensuring that all namespaces are configured with the restricted Pod Security Standard. The Kyverno policy below will enforce this policy, except for namespaces that legitimately need elevated permissions:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: podsecurity-subrule-restricted
  annotations:
    policies.kyverno.io/title: Restricted Pod Security Standards  
spec:
  background: true
  validationFailureAction: Audit
  rules:
  - name: restricted
    match:
      any:
      - resources:
          kinds:
            - Pod
    exclude:
       any:
       - resources:
           namespaces:
             - my-system-namespace
    validate:
      podSecurity:
        level: restricted
        version: latest

Refer to this GitHub repository for a curated list of Kyverno policies.

Best Practices & Recommendations

Getting started with NIS2 compliance requires both strategic planning and practical steps. Here’s how your organization can begin its journey:

  • Build the right foundations: Begin by hiring a Chief Information Security Officer (CISO) and allocating a dedicated budget for cybersecurity. While the CISO leads the effort, success requires collaboration across teams. Promote awareness of NIS2, risk management, and platform security among all stakeholders to create a culture of shared responsibility.
  • Assess and educate: Use tools like Kyverno to evaluate your current security posture by running policies in Audit mode. Share the results with development teams to help them understand the risks and implications of misconfigured workloads. Education is key – empower teams with the knowledge to fix vulnerabilities and deploy secure workloads.
  • Enforce and streamline: Once workloads are compliant, switch to Enforce mode to prevent misconfigurations and ensure continuous compliance. Streamline reporting and evidence gathering using tools like Nirmata Control Hub, which provides centralized dashboards and real-time insights. This simplifies audits and ensures your organization has the needed evidence to demonstrate compliance with NIS2.

Build vs buy: If you don’t have an in-house platform team (or don’t want to invest in one), consider using an application platform with built-in guardrails, such as Elastisys Welkin®.

Conclusion

Kyverno offers a comprehensive solution for ensuring compliance with NIS2 minimum requirements, helping organizations enforce policies, and prevent misconfigurations in Kubernetes environments. By leveraging Kyverno, you can seamlessly integrate security and compliance controls into your platform, enabling continuous enforcement without adding complexity for developers or platform teams.

Ready to take your NIS2 compliance to the next level? Learn more about Nirmata Control Hub and how it simplifies Kyverno policy management, enhances security, and facilitates NIS2 minimum requirements for your Kubernetes workloads. Request a demo today!

Looking for a turnkey application platform? Navigating NIS2 compliance while ensuring security and operational resilience can be complex, but Elastisys Welkin® makes it easier. As a turnkey application platform designed for organizations operating software critical to society, Elastisys Welkin enables seamless compliance, reduces risk, and strengthens security – without adding unnecessary complexity.

By combining Elastisys Welkin with Elastisys’ expert consulting and training services, your organization can achieve resilience by design, ensuring compliance with EU regulations while accelerating innovation.
Want to see how Elastisys Welkin® can support your NIS2 compliance journey? Get in touch with us today!

Kubernetes Policy Comparison: Kyverno vs. OPA/Gatekeeper
No Comments

Sorry, the comment form is closed at this time.