Shared Responsibility Managed Kubernetes

This English version is provided for convenience only. The German version is legally binding; in the event of any discrepancy between the two versions, the German version shall prevail.

1. Introduction

The Shared Responsibility Model (SRM) describes the allocation of responsibilities between centron GmbH, Heganger 29, 96103 Hallstadt, Germany (the “Provider”) and the Customer when using Managed Kubernetes.

Secure use of Kubernetes requires that both the Provider and the Customer understand and fulfil their respective responsibilities. The Provider provides a managed Kubernetes platform and secures the underlying infrastructure, while the Customer is responsible for the security and configuration of its applications, containers and workloads.

As is customary for Platform-as-a-Service and Infrastructure-as-a-Service offerings, a considerable part of the responsibility remains with the Customer.

2. Basic principle

The Provider is responsible for the security of the platform and infrastructure, in particular:

• operation and protection of the Kubernetes control plane
• underlying data centre and network infrastructure
• hardware and virtualisation layer
• basic cluster provisioning and platform services

The Customer is responsible for security within the Kubernetes cluster, in particular:

• containers and deployments
• applications and services
• access controls and user management
• configuration of the cluster

This model corresponds to the general principle that the Provider protects the infrastructure, while the Customer secures its workloads.

3. Data security

The Customer is responsible for securing all data that it stores or processes within the Kubernetes cluster.

The following is recommended:

• protecting the access credentials for the centron account as well as kubeconfig files
• strictly separating user and role models
• managing Kubernetes Secrets securely
• encrypting data appropriately

The Provider makes the platform and security mechanisms available but assumes no responsibility for the content in the Kubernetes clusters or for its protection.

Kubernetes Secrets can be stored in encrypted form at platform level (Encryption at Rest). This additional security component supplements the protection concept but does not replace the Customer’s own securing of access controls.

4. Cluster and workload security

The Customer is fully responsible for:

• deployment and configuration of containers
• securing applications
• maintaining and updating container images
• management of namespaces and resources

The Provider assumes no responsibility for insecure or faulty configurations within the cluster.

5. Network and access security

The Provider provides basic network functions, including automated firewall mechanisms for cluster communication.

The Customer is responsible for:

• configuration of Kubernetes network policies
• access control for services and APIs
• securing external endpoints
• management of open ports and ingress rules

The Provider assumes no responsibility for misconfigurations within the cluster network architecture.

6. Encryption

The Provider provides the following security mechanisms:

• encryption of data within the platform (e.g. etcd)
• securing of API communication via TLS

The Customer is responsible for:

• secure use of certificates
• protection of access credentials and API access
• implementation of additional encryption measures within the applications

Communication with the Kubernetes API is encrypted, typically via TLS.

7. Logging and monitoring

The Provider makes basic infrastructure available but does not assume full responsibility for monitoring within the cluster.

The Customer is responsible for:

• setting up monitoring and alerting systems
• analysing logs
• monitoring applications and resources
• detecting security incidents

Depending on the configuration, audit logging or detailed logging may not be included by default and must be set up by the Customer.

8. Compliance and certifications

The Provider operates the underlying infrastructure in accordance with common security and compliance standards.

This may include, in particular:

• audits by independent third parties
• security certifications

However, the Customer remains responsible for compliance with all regulatory requirements applicable to it and for the correct use of the platform within the framework of these requirements.

Kubernetes platforms may be part of audits, for example in the context of ISO/IEC 27001 on the basis of IT-Grundschutz and C5:2026 audits.

9. Availability and high availability

The Provider ensures the availability of the Kubernetes platform and of the control plane.

The Customer is responsible for:

• architecture of highly available applications
• use of redundancy mechanisms
• scaling of workloads
• implementation of backup and recovery strategies

Kubernetes enables the use of highly available configurations, which must be actively implemented by the Customer.

10. Key management and access

The Provider manages central key components of the platform, including:

• certificates for the Kubernetes API
• internal encryption keys

The Customer is responsible for:

• secure storage of kubeconfig files
• management of API access
• implementation of identity and access management

Access credentials are provided to the Customer and must be protected by the Customer.

11. Summary of responsibilities

The Provider provides a secure, managed Kubernetes platform and protects the underlying infrastructure as well as central platform components.

The Customer is responsible for the secure use of this platform, in particular for:

• containers and applications
• access controls
• data and secrets
• configuration and operation

Security in the cloud is therefore a shared responsibility in which both parties must fulfil clearly defined tasks.