On this page
Security & responsibilities
Define access, application security and data ownership with a practical responsibility matrix.
Use this planning guidance now for an inquiry and pilot proposal. Service commitments require a written agreement.
Before you start
Identify your application's owner, data categories and required access. Confirm the infrastructure and Kubernetes operating scope in the pilot proposal; “managed” does not remove your responsibility for application code and data use.
Make ownership visible
| Area | ClusterPilot · agree scope | Customer |
|---|---|---|
| Infrastructure / cluster | Provisioning, networking and lifecycle operations included in the pilot. | Requirements, change approvals and application compatibility checks. |
| Access | Agreed credential delivery, permissions and access-revocation process. | Authorized people, secure devices, requests when team membership changes. |
| Application | The confirmed platform interfaces and separately agreed assistance. | Images, dependencies, application authentication, secrets and configuration. |
| Data / recovery | Only the explicitly included storage/backup/recovery services. | Lawful use, classification, recovery requirements and application-level validation. |
| Monitoring / incidents | Agreed signals, channels and escalation during confirmed support coverage. | User-visible checks, business impact and availability of the application contact. |
Use the least access that works
- ✓Separate deployment access from read-only diagnosis where the agreed role model allows it.
- ✓Keep individual ownership of credentials and record how access is revoked or refreshed.
- ✓Do not grant broad cluster privileges to application automation just to avoid a Forbidden error.
- ✓Confirm namespace isolation and NetworkPolicy enforcement; their existence in Kubernetes does not prove your pilot's isolation guarantees.
Keep application credentials private
Keep passwords, private keys and API tokens out of image layers, Git and manifests shared for support. Kubernetes Secret values are commonly base64-encoded; that encoding is not encryption. Confirm access restrictions, storage protection and the agreed secret delivery/rotation process. A dashboard or operator should not be assumed to provide a qualified secrets service.
Review approved images and dependency updates. Prefer a non-root process, a read-only filesystem where compatible and no automatic service-account token when the application does not call the Kubernetes API. Test these settings with your application rather than removing restrictions after an unexplained startup failure.
Deploy your first application →Agree data and audit requirements
Before uploading sensitive data, confirm the agreed location, processing terms, authorized operator access, logging/retention and exit procedure. Define which actions must be traceable and how you obtain evidence. Cloud team management, audit exports and compliance certifications are not confirmed by these guides and need individual qualification.
Get useful support quickly →Technical references
These Kubernetes references describe technical behavior. Your pilot agreement defines the capabilities confirmed for your cluster.
Use this guide within your agreed pilot scope. Kubernetes examples are not evidence of a generally available Cloud capability.