Data Security for AI: Encrypted Datasets in Multi-Tenant Clusters

In the gold rush surrounding Artificial Intelligence, a critical aspect is often overlooked: the security of the underlying data. When companies train or operate AI models in shared infrastructures (multi-tenant clusters), entirely new attack vectors emerge. A compromised model or malicious container must never be able to access the training data or IP assets of other departments or customers.

Particularly in light of the NIS-2 Directive and the EU AI Act, data security will become a legal obligation for medium-sized businesses by 2026, moving from a “nice-to-have” option.

1. Namespace-Level Isolation: More Than Just Logical Separation

In Kubernetes, the namespace is the primary boundary for resources. However, for AI workloads, simple separation is not enough. We must ensure that an AI model trained in Namespace-A has no physical or logical access to Namespace-B.

• Network Policies (Zero Trust): By default, any pod in Kubernetes can communicate with any other. For AI environments, we implement strict Deny-All-Policies. Only explicitly defined connections to the data store or model registry are allowed.
• eBPF-based Microsegmentation: Using tools like Cilium, we go beyond Layer-4 policies and enforce security at Layer-7 (API level). This prevents an infected model from scanning other services via lateral movement.

2. Encryption At Rest: Protecting the “Crown Jewels”

Training datasets and the resulting model weights are the most valuable intellectual property of an AI company. These must be encrypted at all times—even when they are at rest in storage.

• KMS Integration: We use the Kubernetes Key Management Service (KMS) to securely manage secrets and disk encryption keys. Integration with external vault solutions (like HashiCorp Vault) ensures decryption occurs only within an authorized runtime environment.
• Hardware Encryption: By using NVMe drives with built-in encryption (Self-Encrypting Drives), we minimize performance overhead while ensuring that no data can be leaked in the event of physical hardware theft from the data center.

3. Isolated Training Environments and Sandboxing

AI training often requires importing third-party libraries or pre-trained models from unsecured sources. To minimize risk to the rest of the cluster, we rely on isolated sandboxes.

• Runtime Isolation with Kata Containers: Instead of using standard containers (runc) that share the host kernel, we use Kata Containers for high-risk AI workloads. These offer hardware virtualization (Micro-VMs), making it nearly impossible for a container to escape to the host server.
• Taints and Tolerations: We dedicate specific GPU nodes exclusively to training. Through taints, we ensure that no sensitive web applications or databases run on the same physical machines as experimental AI workloads.

4. Compliance in the NIS-2 Context

The NIS-2 Directive requires companies to ensure “supply chain security” and “cyber risk management.” Applied to AI infrastructures, this means:

• Audit Logging: Every interaction with the dataset must be logged in a tamper-proof manner using tools like Grafana Loki.
• Vulnerability Scanning: Container images for AI workloads must be continuously scanned (e.g., in Harbor) for vulnerabilities before they gain access to GPU resources.

Conclusion

Data security in AI is not an obstacle but an enabler. Only those who can guarantee that models and data are strictly isolated and encrypted in multi-tenant environments can fully exploit the potential of Cloud-Native AI without risking regulatory sanctions or the loss of intellectual property. ayedo supports you in integrating these complex security architectures into your Kubernetes routine in an automated and legally compliant manner.

FAQ

How do I prevent an AI model from accessing other namespaces? This is primarily achieved through Network Policies that block any communication between namespaces. Additionally, RBAC roles (Role-Based Access Control) ensure that pods can only access the volumes (PVCs) explicitly assigned to their namespace.

Why is standard encryption often not enough for AI data? AI models access data at very high speeds. Purely software-based encryption can become a bottleneck here. The combination of KMS-controlled key management and hardware acceleration (AES-NI) is necessary to guarantee security without performance loss.

What does NIS-2 have to do with AI clusters? NIS-2 obliges operators of critical and important services to implement strict security measures. Since AI models often control central business processes or process sensitive customer data, cluster infrastructures must be secured in accordance with NIS-2 requirements (e.g., access control, encryption, incident reporting).

Can different teams safely use the same GPU? Yes, techniques like NVIDIA MIG (Multi-Instance GPU) allow GPUs to be partitioned at the hardware level. This not only provides performance isolation but also prevents data remnants in the graphics memory from being read by another process.

Does ayedo support the implementation of zero-trust AI environments? Absolutely. We help companies secure their Kubernetes clusters according to zero-trust principles. This includes configuring Cilium, Vault integrations, and implementing compliance frameworks to meet NIS-2 requirements.