Platform security

Security by architecture

Security on GRN.CLOUD is a set of controls at distinct layers — hardware, host, network, cluster, workload, identity and data — each enforced by a specific mechanism you can inspect, express in Git and audit. This page describes those mechanisms, where each one starts and stops, and which of them are ours to operate and which are yours.

Enforced by the cluster, not by convention
Every control is a reviewable object
Dutch jurisdiction · no US Cloud Act exposure
Boundaries stated, not implied

See the layer model Talk to a security engineer

Written for the person who reviews the architecture before signing · Platform overview

The model

Defence in depth, stated as controls

The premise is that any single control will eventually be misconfigured, bypassed or outlived by an attacker's technique. So the platform is built so that no single control is load-bearing — a failure at one layer meets a different mechanism at the next.

Layered, not stacked

Each layer uses a different enforcement mechanism — SELinux on the host, OVN flows on the network, admission controllers at the API, RBAC on identity. Defeating one does not hand you the next, because they are enforced by different subsystems with different failure modes.

Least privilege as the default path

A workload that asks for nothing gets a non-root UID from its namespace range, all Linux capabilities dropped, a RuntimeDefault seccomp profile and no privilege escalation. Raising any of those is an explicit, logged, reviewable grant.

Declarative, therefore reviewable

Roles, network policies, quotas and admission rules are API objects. They can be diffed, code-reviewed, version-controlled and reconciled by Argo CD — so the security posture of a namespace is a file someone approved, not tribal knowledge.

What this page does not claim

GRN.CLOUD does not hold a published ISO 27001 or SOC 2 attestation, and nothing here should be read as one. Where this page refers to NIST or CIS material it means the architecture is organised along those principles — alignment, which is a design statement, not certification, which is a third party's signed opinion after an audit.

Nor does the platform make your application secure. Most breaches of hosted workloads begin above the platform boundary — in application code, dependencies, and credentials the customer controls. The responsibility model below is explicit about where our controls end.

Architecture

Security at every layer

Read from the top: your data and your code, down through the controls that separate you from every other tenant, to the hardware in a Dutch data centre. The marker on each layer says who operates it.

Data & application

Your code · dependencies · app roles · queries
You operate

Your source, your libraries, your schema, your application's own authentication and authorisation. The platform gives this layer a place to run, TLS to run it behind and secrets management to feed it — it cannot make the code itself correct. Input validation, dependency currency and application-level authorisation stay with you.

Identity & access

OAuth · OIDC · RBAC · ServiceAccounts
Shared

We operate the cluster's authentication server and the RBAC engine that evaluates every API request. You decide who your people are, which identity provider vouches for them, and which roles they hold in your namespaces. Authentication answers who is this; RBAC answers may this identity perform this verb on this resource. They are separate systems, and a mistake in the second is the more common one.

Workload & container

SCC · Pod Security Admission · seccomp · SELinux · CRI-O
GRN-managed

Admission control decides what a pod is allowed to be before it is ever scheduled. The restricted-v2 security context constraint drops all Linux capabilities, forbids privilege escalation, requires a non-root UID from the namespace's allocated range and applies the RuntimeDefault seccomp profile. SELinux and CRI-O enforce the resulting boundary at runtime, on the host.

Cluster & API

kube-apiserver · admission plugins · namespaces · quotas · audit
GRN-managed

Every change to the cluster is an authenticated, authorised, admission-checked and audited API call — there is no side channel. Namespaces carry the tenancy boundary for names, quotas, policies and RBAC scope. Control planes are hosted with HyperShift, so a tenant's control plane is isolated from the management cluster that runs it.

Network

OVN-Kubernetes · NetworkPolicy · TLS ingress · MetalLB
GRN-managed

Segmentation is expressed as NetworkPolicy objects that select pods by label rather than by IP address, and are enforced as flow rules in OVN — so a policy keeps meaning after a pod is rescheduled onto a different node with a different address. North–south traffic terminates TLS at the ingress layer with certificates issued and rotated by cert-manager.

Host & operating system

RHCOS/SELinux · immutable updates · KVM · kernel isolation
GRN-managed

Nodes run an immutable, image-based operating system that is replaced rather than patched in place, which removes configuration drift as an attack surface. SELinux confines container processes in enforcing mode. On VPC, workers are KubeVirt virtual machines, so tenants are separated by a KVM hypervisor boundary in addition to the container boundary.

Site & hardware

Netherlands · EU jurisdiction · three zones per site · renewable power
GRN-managed

The physical machines, the racks they sit in and the company that owns them are in the Netherlands, under Dutch and EU law. Sites are built as three independent availability zones with their own power, cooling and uplinks. Jurisdiction is a security property, not only a legal one: it determines who can compel disclosure of your data.

Infrastructure

Hosts, hypervisor and hardware

The layer most cloud security pages skip. Everything above it inherits its assumptions from here — if the host is compromised, no control in the cluster above survives it.

Nodes are immutable by design. The operating system ships as a versioned image; an update replaces the image and reboots the node rather than mutating a running system, so every node of a given role is bit-identical and configuration drift cannot accumulate quietly.

SELinux enforcing
CRI-O
KVM / KubeVirt
Immutable OS

Virtualisation → Dedicated hardware →

Immutable, image-based nodes

The node OS is replaced, not patched in place. Rollback is selecting the previous image, and no node accumulates hand-edits.

SELinux in enforcing mode

Mandatory access control confines each container process. A container escape must also defeat a kernel policy that the process cannot edit.

CRI-O runtime

A container runtime scoped to Kubernetes only — a deliberately smaller surface than a general-purpose container daemon.

Hypervisor boundary on VPC

Workers are KubeVirt VMs on KVM. Tenants are separated by a virtual machine boundary as well as a namespace and a container boundary.

Physical isolation on DPC

Dedicated Private Cloud runs bare-metal workers with local NVMe and an isolated network — no shared kernel, no shared disk.

Three-zone sites

Each regional site is three availability zones with independent power, cooling and uplinks, so a single physical failure is contained.

EU-owned, EU-operated

Hardware and the operating company are in the Netherlands. No US parent, and therefore no US Cloud Act disclosure route.

Renewable power

Sites run on renewable energy with heat reuse — an operational property of the estate, not a security control.

Boundary

Physical access control, CCTV, visitor procedures and environmental monitoring are properties of the data centre facilities and their operators, and are governed by those facilities' certifications rather than by anything in the cluster. Ask us for the current facility attestations for the site your workload lands in; do not infer them from this page.

Network

Segmentation and traffic control

A flat network inside a cluster is the most common way a small compromise becomes a large one. Segmentation here is label-based and enforced in the data plane, so it survives rescheduling, autoscaling and IP churn.

NetworkPolicy objects select pods by label and describe permitted ingress and egress. OVN-Kubernetes compiles them into flow rules on every node. Because the selector is a label and not an address, a policy written once stays correct as pods move.

NetworkPolicy
OVN-Kubernetes
cert-manager
MetalLB / BGP

Networking architecture →

East–west micro-segmentation

Policy is written per namespace and per label selector, down to a single service, rather than per subnet.

Egress control

Policies restrict outbound traffic as well as inbound, which is what limits data exfiltration and command-and-control from a compromised pod.

TLS termination and rotation

cert-manager issues and automatically renews certificates for routes and internal services. Expiry becomes a non-event.

Namespace-scoped DNS

Service discovery is cluster-internal. A service with no route has no path in from the internet at all.

Private-only endpoints

Services can be published so they are reachable solely over a VPN tunnel, never through a public route.

Load balancing at the edge

MetalLB advertises service addresses over BGP; the ingress layer is the single, instrumented north–south entry point.

Optional in-transit encryption

OVN-Kubernetes supports IPsec for pod-to-pod traffic between nodes. It is a configuration decision per cluster — see the boundary note.

Dual-stack

IPv4 and IPv6, with policy applying equally to both — a common gap when v6 is enabled without revisiting the rules.

Boundary — read this before assuming isolation

Kubernetes networking is allow-by-default. If no NetworkPolicy selects a pod, that pod accepts traffic from any pod in the cluster. Isolation begins with an explicit default-deny policy in your namespace; we can supply and enforce a baseline, but a namespace with no policy is not segmented, and no vendor can make it so on your behalf.

IPsec is opt-in and partial. When enabled, OVN-Kubernetes encrypts pod-to-pod traffic between different nodes; traffic between two pods on the same node is not encrypted by it. Enabling it after a cluster is built also requires an MTU change. If you need it, say so during cluster design rather than after.

default-deny.yaml — the first policy in any namespace

# Selects every pod in the namespace, permits nothing.
# From here, each allowed flow is added explicitly and reviewed.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: payments
spec:
  podSelector: {}            # {} means "all pods in this namespace"
  policyTypes:
    - Ingress
    - Egress                 # omitting Egress leaves exfiltration paths open

Cluster

The API is the only door

Every action against a cluster — by a person, a pipeline or a controller — is an HTTPS call to the Kubernetes API server. That single choke point is where authentication, authorisation, admission and audit all happen, which is why the cluster layer is where policy is most reliably enforced.

A request is authenticated, then authorised by RBAC, then evaluated by admission plugins that may reject or mutate it, and only then persisted. It is recorded in the audit log regardless of the outcome.

RBAC
restricted-v2 SCC
Pod Security Admission
HyperShift

Managed Kubernetes → Platform overview →

Namespaces as the tenancy unit

Names, quotas, RBAC scope, network policy and admission profile all attach to the namespace boundary.

Security Context Constraints

OpenShift's admission control on what a pod may be. restricted-v2 is the default for ordinary workloads.

Pod Security Admission

The upstream Kubernetes standard, evaluated alongside SCC. Namespace labels select the profile that applies.

Scoped service accounts

Workload identity is a ServiceAccount with an explicit role binding — not a shared cluster credential.

Quotas and limit ranges

ResourceQuota bounds the blast radius of a runaway or hostile workload — denial of service is a security outcome.

Isolated hosted control planes

HyperShift runs each tenant control plane separately from the management cluster hosting it.

Admission policy across clusters

Red Hat ACM and ACS distribute policy and report where a cluster has drifted from it.

API audit trail

Requests are recorded with identity, verb, resource and decision — including the ones that were denied.

Boundary

SCC and Pod Security Admission constrain the shape of a workload — its UID, capabilities, seccomp profile, volume types and escalation rights. They do not inspect what your container actually does once it is running within those limits. Runtime behaviour is the job of the detection layer, and application logic is yours.

A namespace-scoped tenancy boundary is strong but not a hypervisor. Where your threat model requires kernel-level or hardware-level separation between tenants, that is an infrastructure tier decision — see isolation levels — not a policy you can write.

Workload

Images, runtime and supply chain

A container image is a shipped artefact with a dependency tree inside it. Most practical compromise of a cloud-native workload arrives through that tree rather than through the platform underneath it.

The controls that matter are unglamorous: know what is in the image, know where it came from, rebuild it when a dependency is fixed, and give it the smallest runtime privileges it can function with.

Non-root by default
Capabilities dropped
Registry scanning
Red Hat ACS

Application platform → CI/CD on GitLab →

Non-root, always

Containers get a UID from the namespace's allocated range. An image that only works as root fails admission rather than running as root.

All capabilities dropped

requiredDropCapabilities: ALL. Anything the workload genuinely needs is added back explicitly and visibly.

No privilege escalation

allowPrivilegeEscalation: false blocks the setuid path a process would use to gain rights it was not given.

Seccomp by default

The RuntimeDefault profile filters the syscall surface reachable from inside the container.

Read-only root filesystem

Available per workload, and worth taking: it removes the attacker's easiest place to drop a payload.

Registry and image scanning

Images are scanned for known vulnerabilities so a CVE is a work item with a location, not a rumour.

Your build, your pipeline

Run GitLab CI in-cluster next to the registry — source, build and artefact stay inside your own tenancy.

Runtime posture

Red Hat ACS reports on running deployments that violate policy, not only on images at rest.

Boundary

Scanning finds published vulnerabilities in identified components. It cannot find a flaw in your own code, an unpublished vulnerability, or a malicious package that has not been reported yet. It is a currency check, not a proof of safety.

Cryptographic image signing and provenance attestation (Sigstore-style) are supported by the underlying platform and can be enabled per cluster. Whether they are enforced on your cluster is a configuration decision to confirm with us during design — do not assume it is on.

Identity

Authentication and authorisation are two systems

Conflating them is the most expensive mistake in cluster security. Authentication establishes which identity is making a request. Authorisation decides whether that identity may perform a specific verb on a specific resource in a specific namespace. A correct login followed by an over-broad role binding is still a breach.

The cluster's OAuth server integrates with an external identity provider over OIDC, so people authenticate against your directory — with your MFA and your joiner–mover–leaver process — rather than against a second set of credentials we hold.

OIDC / OAuth
Keycloak
RoleBinding
ServiceAccount

Discuss SSO integration →

Bring your own identity provider

OIDC federation to your directory. Deprovisioning a person there removes their cluster access — one place to revoke.

MFA where it belongs

Multi-factor is enforced by your identity provider, so it applies uniformly and we never hold a second credential for your staff.

Namespace-scoped roles

A RoleBinding grants rights in one namespace. ClusterRole bindings are the exception that gets argued for, not the default.

Workload identity

Applications authenticate as ServiceAccounts with short-lived projected tokens, not as a person and not with a static key.

Every grant is an object

Access is a YAML file in Git with an author and a reviewer. "Who can delete production?" is a query, not a meeting.

Separation of duties

Platform administration and tenant administration are different role sets — our operators are not your namespace admins.

Group-driven access

Bind roles to groups from your directory so access follows the team, not the individual.

Auditable authentication

Boundary

RBAC is additive and has no deny rule: a subject's effective permissions are the union of every binding that names them or a group they belong to. There is no rule that subtracts. This makes broad grants genuinely dangerous, and it means periodic review of role bindings is a real operational task rather than a compliance formality.

Data

Encryption, secrets and backups

"Encrypted" is not one property. Data in transit, data at rest on a disk, data at rest in the cluster's own database, and data in a backup are four different problems with four different controls — and the honest answer differs for each.

What follows separates them, including where a control is a configuration decision rather than something that is simply on.

TLS in transit
Ceph / NooBaa
Velero
etcd encryption

Storage architecture → Managed databases →

In transit, externally

TLS terminates at the ingress layer with certificates issued and rotated by cert-manager. Control-plane traffic is TLS throughout.

In transit, internally

Pod-to-pod encryption between nodes is available via OVN IPsec, as a per-cluster decision — see the network boundary note.

At rest, on storage

Persistent volumes are backed by Ceph; encryption at rest is configured per storage class and per cluster.

At rest, in etcd

OpenShift can encrypt Secrets, ConfigMaps, Routes and OAuth tokens in etcd, with keys rotated weekly. It is not on by default.

Secrets at runtime

Credentials are mounted or injected as Kubernetes Secrets at runtime rather than baked into an image or a Git repository.

Backups

Velero and CSI snapshots cover cluster state and volumes on a schedule you choose, with restore rehearsal available.

Data residency

Primary and replica copies stay on infrastructure in the Netherlands unless you explicitly ask for something else.

Deletion

Volume and object deletion is a platform operation you control; retention of backups follows the schedule you set.

Boundary — the part most pages leave out

A Kubernetes Secret is base64-encoded, not encrypted. Encoding is not a security control. Secrets are protected by RBAC on the API and, if etcd encryption is enabled, by encryption in the datastore. Anyone who can read Secrets in a namespace can read their plaintext — which makes the RBAC grant, not the storage format, the control that matters.

Encryption at rest defends against a specific threat: loss of physical media or of the stored data. It does nothing against a compromised credential or an over-permissive role, because those paths read the data through the API, already decrypted. Treat it as a necessary control with a narrow scope, not as general protection.

A backup you have never restored is a hypothesis. Restore testing is scheduled work; ask us to rehearse it with you rather than assuming it.

Detection

Logging, audit and posture

Prevention fails eventually. What determines the size of the incident is how quickly it is noticed and how completely it can be reconstructed afterwards.

The API audit log is the primary security record: it captures who called what, on which resource, with which decision — including denials, which are frequently the first visible sign of a compromised credential probing its limits.

API audit log
Loki
Observatorium
Red Hat ACS

Observability on the platform →

Kubernetes API audit

Identity, verb, resource, source and decision for every API request, successful or refused.

Log aggregation

Loki collects cluster and workload logs; Observatorium provides the long-term metrics view.

Posture reporting

Red Hat ACS reports deployments that violate policy and clusters that have drifted from their baseline.

Runtime detection

ACS observes process and network behaviour inside running containers, not just image contents.

Export to your SIEM

Logs can be shipped to your own collector so your security team correlates platform events with everything else.

Change traceability

Where the platform is driven by Argo CD, a change in the cluster maps back to a reviewed commit.

Denials are signal

Rejected admission requests and RBAC denials are recorded and are often the earliest indicator worth alerting on.

Alerting

Metric and log-based alerts route to the channels your team already watches.

Boundary

Audit logging records control-plane activity — calls to the Kubernetes API. It does not record what happens inside your container or your database: an application-level data access leaves no trace in it. Application audit logging is yours to implement, and for many regulatory questions it is the log that actually gets asked for.

Retention periods, alert routing and whether logs are forwarded to your SIEM are configured per customer. Agree them in writing during onboarding — the defaults are a starting point, not a commitment.

Operations

Patching, upgrades and recovery

Most real-world compromise exploits a vulnerability that had a patch available. Security at this layer is not a technology choice — it is whether updates actually get applied, on a cadence, without an outage as the price.

Because nodes are immutable images and workloads are declarative, an update is a rolling replacement: nodes are drained, replaced with the new image and rejoined one at a time, with the previous image available as a rollback.

Rolling node replacement
Managed upgrades
Velero restore
Argo CD

Managed lifecycle → Ask about incident response →

Platform patching is ours

Host OS, control plane, and the storage, networking and observability layers are patched by our engineers.

Upgrades without downtime

Nodes are drained and replaced in sequence; workloads with more than one replica ride through it.

Rollback by design

The previous node image and the previous declarative state both remain available.

Workload patching is yours

Your base images and dependencies are rebuilt and redeployed by your pipeline — we cannot do this for you.

Backup and restore

Velero and CSI snapshots, on your schedule, with restore rehearsal on request.

Multi-zone recovery

Three-zone sites mean a zone failure is a capacity event rather than a data-loss event.

Configuration as code

Argo CD reconciles the cluster to Git, so drift is visible and correction is a revert.

A named escalation path

Security issues reach engineers who operate the platform, not a first-line queue.

Boundary

We patch the platform. We do not patch your application, your base images or your dependencies — that requires rebuilding artefacts we do not own and cannot test. A fully patched platform running a vulnerable container is a vulnerable system, and this is the most common shape of a real incident.

Incident response responsibilities, notification timelines and breach-notification duties under GDPR Article 33 are set out in the contract and the Data Processing Agreement. Ask for both before you need them.

Isolation

Choose the separation your threat model needs

Every control on this page applies across all three infrastructure models. What changes is the strength of the boundary between you and any other tenant — and that is an architectural decision, not a policy you can write after the fact.

Namespace boundary

Public Cloud

Shared infrastructure with application-level control. Separation is by namespace, RBAC, NetworkPolicy and the container runtime — the standard Kubernetes tenancy model. Appropriate for development, test and workloads whose threat model accepts a shared kernel.

Public Cloud →

Kernel boundary

Virtual Private Cloud

Dedicated compute with cluster-level control on KubeVirt VM workers. Adds a KVM hypervisor boundary beneath the container boundary, so a container escape still lands inside your own virtual machine. The usual choice for production.

Virtual Private Cloud →

Hardware boundary

Dedicated Private Cloud

Bare-metal workers, local NVMe and an isolated network. No shared kernel and no shared storage with another tenant. For regulated workloads and threat models that will not accept shared silicon.

Dedicated Private Cloud →

Not sure which boundary your obligations require? That is a conversation worth having before design, not after — talk to an engineer.

Responsibility

Who secures what

Shared responsibility is where most cloud security incidents actually originate — not because a control failed, but because both parties assumed the other one owned it. This table is the summary; the contract and the DPA are authoritative.

Control	Owner	What that means in practice
Physical & environmental	GRN.CLOUD	Facilities, hardware, power, cooling, physical access to the estate.
Host OS & hypervisor	GRN.CLOUD	Immutable node images, SELinux, KVM, host patching and replacement.
Kubernetes control plane	GRN.CLOUD	API server, etcd, scheduler, controllers, cluster upgrades.
Cluster network fabric	GRN.CLOUD	OVN-Kubernetes, ingress, load balancing, policy enforcement engine.
NetworkPolicy content	You	Which flows your namespaces permit. We enforce the policies; you decide them.
Platform RBAC	GRN.CLOUD	Cluster-level roles, operator permissions, separation of platform duties.
Tenant RBAC	You	Who on your team holds which role in which namespace, and periodic review of it.
Identity provider & MFA	You	Your directory, your MFA policy, your joiner–mover–leaver process.
Container images	You	Base image choice, dependency currency, rebuilds when a CVE is fixed.
Image scanning & posture tooling	GRN.CLOUD	We provide and run the tooling; acting on its findings is yours.
Application code & secrets hygiene	You	Application logic, authorisation, input handling, and not committing credentials.
Secrets storage	Shared	We provide the Secret store, RBAC and optional etcd encryption; you scope access to it.
Backups	Shared	We provide Velero, snapshots and the schedule mechanism; you define RPO/RTO and verify restores.
Platform monitoring & audit	GRN.CLOUD	Cluster logging, API audit, platform alerting.
Application logging & audit	You	What your application records about its own data access.
Data classification	You	Only you know what your data is and which regime governs it.
Jurisdiction & residency	GRN.CLOUD	EU-owned infrastructure and company, operated under Dutch and EU law.
GDPR role	Shared	You are the controller; we are the processor. Set out in the DPA.

This table is a description of the operating model, not a contractual term. Where it and your signed agreement differ, the agreement governs.

Alignment

How the architecture maps to NIST CSF 2.0

The NIST Cybersecurity Framework 2.0 (February 2024) organises security outcomes into six Functions — GOVERN was added in 2.0 alongside the original five. It is a way to check an architecture for gaps, which is how it is used here.

CSF 2.0 Function	Outcome	Where it appears in this architecture
GOVERN	Strategy, expectations and policy are set and monitored	The responsibility model above; the DPA and contract; policy distributed and reported by Red Hat ACM/ACS.
IDENTIFY	Assets and risks are understood	Every workload, role, policy and volume is an API object that can be enumerated. Image scanning inventories what is deployed.
PROTECT	Safeguards are in place	RBAC, SCC and Pod Security Admission, NetworkPolicy, TLS, encryption options, namespace and hypervisor isolation.
DETECT	Attacks and compromises are found	API audit logging, Loki aggregation, ACS runtime and posture reporting, alerting on denials.
RESPOND	Action is taken on a detected incident	Named escalation to platform engineers; namespace and policy changes take effect immediately; GDPR Art. 33 duties in the DPA.
RECOVER	Assets and operations are restored	Velero and snapshot restore, rollback to the previous node image and previous declarative state, three-zone site design.

Alignment is not certification

This table shows that the architecture has a mechanism for each CSF Function. That is a design check, and it is useful. It is not an assessment, a maturity rating, or a statement of conformance — those require an independent assessor and produce a signed report. GRN.CLOUD does not currently publish one, and no sentence on this page should be quoted as if it did.

The same distinction applies to GDPR. Technical controls such as encryption, access control and logging support Article 32 obligations, but compliance is a legal determination about your processing, your lawful basis and your documentation — not a property the infrastructure can confer on you.

FAQ

The questions a security architect actually asks in a review.

Are you ISO 27001 or SOC 2 certified?

We do not publish an ISO 27001 or SOC 2 attestation, and we will not imply one. What we can give you is the architecture on this page, the Data Processing Agreement, the facility attestations held by the data centres your workload runs in, and direct access to the engineers who operate the platform. If a certificate is a hard procurement requirement, tell us early — it is a fair requirement, and it is better raised before design than during it.

Is my data encrypted at rest?

It depends which "at rest" you mean, which is why the data section separates them. Persistent volume encryption is configured per storage class and per cluster. Encryption of Secrets, ConfigMaps, Routes and OAuth tokens inside etcd is an OpenShift capability that is not enabled by default and is a per-cluster decision. Ask us to confirm in writing what is enabled on your cluster rather than assuming a default.

Is traffic between my pods encrypted?

Not automatically. Traffic inside the cluster network is isolated by NetworkPolicy but is not encrypted unless IPsec is enabled on the cluster, and when it is, it covers pod-to-pod traffic between different nodes rather than traffic between two pods on the same node. If you need in-cluster encryption — many regulated workloads do — raise it during cluster design, because enabling it later also requires an MTU change. Application-level mTLS through a service mesh is the other route.

How is my workload isolated from other customers?

By namespace, RBAC, NetworkPolicy and the container runtime on Public Cloud; additionally by a KVM hypervisor boundary on Virtual Private Cloud, where workers are KubeVirt VMs; and by dedicated physical hardware with an isolated network on Dedicated Private Cloud. The strength of the boundary is an infrastructure tier choice — see isolation levels. Pick it against your threat model, not your budget alone.

Can your staff read my data?

Platform administration and tenant administration are separate role sets, and platform operators do not hold roles inside your namespaces as a matter of course. Administrative activity against the cluster API is recorded in the audit log. The precise standing access, break-glass procedure and how it is logged and reviewed should be confirmed with us in writing and reflected in your agreement — you should not accept a marketing sentence as the answer to this question, from us or anyone else.

Do I get the audit logs?

Kubernetes API audit records who called what and with which decision, and logs can be forwarded to your own SIEM. Two caveats worth internalising: control-plane audit does not capture data access inside your application or database — that is your application's job to log — and retention periods are agreed per customer rather than assumed.

What happens when a CVE is published?

For the platform — host OS, control plane, storage, networking, observability — remediation is ours, applied as a rolling node replacement. For your container images and dependencies it is yours, because it requires rebuilding artefacts we do not own. Scanning tells you which of your images are affected; the rebuild and redeploy run through your pipeline.

Are you subject to the US CLOUD Act?

No. The company, the staff and the hardware are in the Netherlands, and there is no US parent through which a CLOUD Act order could reach your data. Requests for data would have to come through Dutch or EU legal process. This is a structural property of who owns the infrastructure — it is not something a US-headquartered provider can match with a regional deployment.

Can we run our own penetration test?

Yes, against your own workloads and tenancy, subject to a scope agreed in advance in writing so our monitoring does not treat it as a live incident. Testing that reaches into shared platform components or other tenants is out of scope. Contact us with the intended scope and dates before you book the testers.

How do we start a technical security review?

Ask for a session with an engineer who operates the platform rather than a sales call. Bring your threat model, your regulatory constraints and your isolation requirements; useful output is a written statement of which controls are enabled on your cluster, which are available, and which we would need to build.

Review the architecture before you commit to it.

Bring your threat model and your compliance obligations. You will talk to the engineers who operate the platform, and you will get written answers about what is enabled on your cluster.

Talk to a security engineer See the whole platform

EU-owned and EU-operated · Dutch jurisdiction · No US Cloud Act exposure · 100% renewable energy

Far far away, behind the word moun tains, far from the countries Vokalia and Consonantia, there live the blind texts. Separated they live in Bookmarksgrove right at the coast of

759 Pinewood Avenue
Marquette, Michigan
info@domain.com
Online Support
906-624-2565
Mon-Fri 8am-5pm

Purchase Now