Direct cloud connectors

When to use this instead of an on-prem agent

The on-prem agent catalog (see Remediation actions) is for a cloud account or cluster this platform genuinely can't reach — the common case at real scale. A direct cloud connector is the other case: an account or cluster you're comfortable connecting straight to Noviqent DevOps, with no agent process to install or keep running. You can have both kinds at once, scoped to different teams with routing keys the same way any other connector is.

Each direct connector publishes a small, fixed set of actions — restart/stop/start an instance, restart a pod, scale a deployment. There is no generic "run this" action on this path, on purpose: it's the same discipline as the on-prem catalog's own command templates, just expressed as named connector methods instead of shell strings.

No stored credential for AWS or GCP

AWS: this platform assumes a role in your own account using the External ID you set, the same no-stored-access-key pattern used elsewhere in the Noviqent fleet. For an AWS Organizations customer, the same role name deployed to every sibling account lets one connector reach any of them by account ID.

GCP: this platform impersonates a Service Account you grant it Token Creator on — no downloadable key is ever created. A single impersonated identity can reach any project granted at the organization or folder level.

Azure and Kubernetes do need a stored credential — a Service Principal client secret, and a Bearer token respectively — because neither has an assume-role equivalent for a third party. Both travel through the same encrypted credential column (or Vault, if connected) as every other connector.

Scope the token or role narrowly

None of these connectors ask for or need broad access. The Kubernetes service account only needs get/delete on pods and patch on deployments/scale — never cluster-admin. The AWS/Azure/GCP identity only needs restart/stop/start rights on compute, and for AWS specifically, a role kept separate from any read-only scanning role you might already have connected for a different product — reusing one would silently widen its blast radius.

Set it up

1. Connectors → Add a connector → pick AWS, Azure, Google Cloud, or Kubernetes
2. Fill in the connector's own fields (a role ARN and External ID for AWS, a Service Principal's IDs for Azure, a Service Account email and project for GCP, an API server URL for Kubernetes) — see each connector's own blurb for exactly what to grant it
3. Test connection to confirm it actually reaches the account or cluster
4. When the AI proposes an action against it on a ticket, review and approve it from that ticket fix's own page — approving runs it immediately, no polling involved