Standard interfaces, scoped credentials, nothing installed
DevOpsArk reads your estate the way your own scripts would, through the Kubernetes API, cloud provider APIs and OpenTelemetry. That is what makes a security review short and a cluster onboarding a five-minute job.
How does DevOpsArk connect to my infrastructure?
DevOpsArk connects to your estate over standard interfaces (the Kubernetes API, cloud provider APIs, Git provider APIs and OpenTelemetry) using scoped, revocable credentials, and installs nothing inside your clusters by default.
What connects to what
What DevOpsArk reads, and what it can write
| Source | Read (default) | Write (only if granted) |
|---|---|---|
| Kubernetes | Nodes, namespaces, workloads, services, ingresses, events, resource metrics, RBAC, CRDs | Workload manifests via ArkCD, scaling and rollout operations, approved remediation |
| Cloud accounts | Instances, networks, storage, load balancers, IAM, DNS zones, billing exports | Cluster provisioning via DMK8S, DNS record changes, approved remediation of tagged resources |
| Git providers | Repository contents, manifests, commits, pull requests, pipeline runs, team membership | Generated container definitions, pull request checks, deployment statuses, release notes |
| Registries | Repositories, images, tags, digests, existing scan results | Images pushed by ArkBuilder |
| Telemetry | Metrics, logs and traces you route to the platform, plus existing Prometheus and Loki | Nothing, telemetry sources are read-only |
Clusters that cannot accept inbound connections
Edge sites behind carrier NAT, regulated environments with no public endpoint, and air-gapped clusters all share the same constraint: nothing outside may initiate a connection inward.
For these, the cluster initiates an outbound connection to a relay and management traffic flows over the connection it established. No ingress rule, no public API endpoint and no inbound firewall change is required.
Because the connection is initiated by the cluster, it is also revoked by the cluster: removing the relay component ends the connection regardless of anything at the other end.
Connecting a cluster, step by step
- 1Create a ServiceAccount
Apply the supplied read-only ClusterRole and binding in the cluster, or supply a cloud provider identity instead.
- 2Register the endpoint
Provide the API endpoint and credential in DevOpsArk, or deploy the relay for a restricted cluster.
- 3Verify
The connection is checked immediately and the inventory begins building.
- 4Review what is visible
Inventory, health, security posture and cost attribution appear without any further configuration.
- 5Grant write scope selectively
Add namespace-scoped write permissions only for the operations you want DevOpsArk to perform.
What leaves your environment, and what does not
- Resource inventory and configuration
- Metrics and resource usage
- Kubernetes and cloud events
- Logs you explicitly route to the platform
- Deployment and pipeline history
- Access bindings and policy configuration
- Billing and usage exports
- Application data in your databases
- Contents of persistent volumes
- Object storage contents
- Secret values held in external stores
- Customer or end-user records
Architecture questions
Through the Kubernetes API using a ServiceAccount token, a cloud provider identity such as an IAM role, or a kubeconfig you supply. A read-only ClusterRole is enough for inventory, monitoring, cost attribution and security posture.
No. Agentless is the default and covers the whole observability and posture surface. An optional in-cluster component is available where you want higher-frequency metric sampling or process-level signals.
Read-only at the account, subscription or project level for inventory, posture and cost. Write permissions are separate, granted per account and per action type, and only required for provisioning or remediation.
Yes. An outbound-only relay lets the cluster initiate the connection, so no ingress rule, public API endpoint or firewall change is required. This is the normal arrangement for edge sites and regulated environments.
Operational telemetry: inventory, resource configuration, metrics, events, deployment history, and the logs you route to the platform. Application data in your databases and persistent volumes is not read.
The DevOpsArk control plane is hosted. Managed clusters provisioned through DMK8S run in your own cloud account, so workloads and data stay under your governance.
By deleting the ServiceAccount, IAM role or application registration you created. Access is a credential you control, so revocation is immediate and does not depend on the platform cooperating.
Yes. Registry credentials are stored in the secrets module and used to read image metadata and to publish builds. Amazon ECR, Azure Container Registry, Google Artifact Registry, GitHub and GitLab registries and self-hosted Harbor are supported.
Connect a cluster during the call
Onboarding is a ServiceAccount and a role binding. Most demos start with your own inventory rather than ours.