CloudInspector is prompt-first. You ask questions in plain language and get answers on an interactive map or in a table. There are no dense dashboards to learn.

Yes. CloudInspector lets you export the state of your environment at a chosen point in time as CSV, supporting audit, compliance, and governance documentation.

CloudInspector comes with an installer and free installation support.

The standard plan allows installing CloudInspector in 1 Kubernetes cluster with up to 250 nodes. Please contact us if you need more.

You decide where CloudInspector stores data. Your data never leaves your network.

You decide on the retention time of any data that CloudInspector collects from your Kubernetes clusters.

CloudInspector is built to stay inside your network, and several independent controls enforce that. There is simply nowhere for data to go:

• The pod has no egress network access.
• NetworkPolicies enforce a default-deny posture.
• No external endpoints are configured anywhere in the product.
• DNS resolution is disabled, so the pod cannot even look up an outside address.

Each control holds on its own, so a single misconfiguration cannot open a path out.

No. CloudInspector is read-only by design, and Kubernetes RBAC enforces this at the API level rather than trusting the application to behave. Its ServiceAccount has:

• No write permissions.
• No patch permissions.
• No delete permissions.

It can observe your cluster, but it cannot change anything in it.

No. CloudInspector is not an operator and has none of the privileges that would let it influence workloads behind the scenes:

• No access to mutate resources.
• No admission controller role.
• No webhook registration.
• No operator privileges.
• No CRD modification rights.

It reads the state of your cluster and nothing more.

No. Its RBAC role does not grant access to Secret resources. In the rare case where a deployment needs secret metadata (for example, which Secrets exist, never their contents), that access is granted explicitly, limited to the minimum required, and documented so you always know exactly what is in scope.

No. The same controls that block ordinary egress also close the less obvious paths sometimes used to smuggle data out:

• Egress is blocked at the CNI level, not just in the application.
• DNS egress is blocked, so DNS tunnelling is not possible.
• The pod has no raw socket capabilities, which rules out ICMP and similar channels.
• It runs without the NET_ADMIN capability.

There is no covert path out, because the network does not allow one.

You stay in control of which version runs, and when. CloudInspector supports the standard supply-chain controls, so a new release cannot reach your cluster without your approval:

• Pin the exact image by digest.
• Verify image signatures before deployment.
• Enforce admission policies on what may run.
• Require supply-chain attestation.
• Mirror images through your own internal registry.

Version upgrades can be gated behind manual approval, so nothing changes until you decide it should.

Yes, and we encourage it. CloudInspector runs like any other workload you can observe and audit, using the tooling you already trust:

• Enable Kubernetes audit logs.
• Use Falco or another runtime-detection tool.
• Add eBPF-based monitoring.
• Watch its network flows.
• Inspect its container logs.

Nothing about its behavior is hidden from your existing security stack.

Even in that worst case, the design keeps the impact contained. Because CloudInspector has no privileges and no way out, a compromised image still cannot do much:

• No egress means no data can be exfiltrated.
• No write RBAC means nothing in the cluster can be modified.
• No elevated privileges means there is nothing to escalate.
• No host access means the node itself stays safe.

The blast radius is limited to read-only access to the Kubernetes API.

No. CloudInspector runs with namespace-scoped, read-only permissions. It never needs cluster-admin, and you can scope it to exactly the namespaces you want it to see.

Yes. None of the above asks you to take our word for it. You can verify CloudInspector's security posture with the tools and processes you already use:

• Run penetration testing against it.
• Perform a static code review.
• Validate its RBAC with policy tools such as OPA/Gatekeeper.
• Enforce Pod Security Standards at the restricted level.
• Apply Kyverno policies.
• Run kube-bench.

The product is designed to pass this kind of scrutiny, not to avoid it.