A service mesh architecture is increasingly being leveraged to prevent unauthorized access to data shared between microservices or between microservices and the control plane (comprising the API server, scheduler, and controller). The mesh is capable of swiftly identifying traffic that might potentially compromise a cluster.
Service meshes apply mutual TLS (mTLS) method for authentication between services and this feature is implemented via the Envoy high-performance server. This allows fine-grained access control over the service API. As a result, only such personal data is processed as is necessary for each specific purpose. Also, by default, personal data is made accessible only to a finite number of users with a legitimate interest in such data.
Service meshes operate at layer 7 in the OSI networking stack that supports end-user applications. So, fine-grained policies targeting individual users can be automatically generated in this layer. This will allow organizations to keep data subjects informed about what kind of personal data is going to be processed (e.g., email, phone no.), who will be able to collect, store, and process it, and how long it will be retained. This allows data subjects to exercise their right, where required, to object to the processing of their personal data. Where data subjects are in agreement to the processing of their personal data, organizations can obtain their explicit consent via online forms, scanned statements, emails, or e-signatures.
Accompanying each service is a load balancer ("layer 7 proxy"), and all client requests are routed by the proxy to available API servers. And for this reason, it should be easy to generate metrics, logs, and traces for every service within the mesh. This will help data controllers identify and mitigate potential risks to any data subject arising from the processing of her/his personal data. Logging of all API requests and responses will help ascertain which user did what and when in case of any GDPR violation. Under GDPR, the data subject is entitled to receive her/his personal data in a machine-readable format. Since every data point is captured by the service mesh, organizations can meet this requirement without any hassle. In short, a well-thought-out service mesh implementation can meet the requirements under GDPR articles 5, 13, 15, 17, 18, 20, 21, 25, 30, 32, 34, 35, and 46.
In Kubernetes ecosystems, personal data often moves from within containers to an external storage asset (e.g., shared cloud storage, network storage devices), and this ensures data persists even after a pod has gone away. It is critically important that personal data is encrypted during its journey through the container infrastructure and across the Kubernetes network. Security risks and attendant GDPR violations are not limited to such data in motion. Data at rest (static data), i.e., residing on hard drives, might also be subject to cyberattacks. Storing sensitive data on drives even though there is no longer any valid reason to do so is a direct violation of GDPR provisions, and employees might do this uninentionally, if not deliberately. Therefore, it is important for data processors to be doubly sure data at rest is encrypted in etcd, Kubernetes' backing store for all of its cluster data. For this, Kubernetes typically makes use of a key management service (KMS), which simplifies and centralizes the storage and management of encryption keys. Further, the data encryption keys are again encrypted, using a key encryption key, and put away securely into a remotely located storage device.