Cynative Connectors: Multi-Cloud Credential Discovery

Cynative connectors discover credentials from your shell environment and enforce read-only access to AWS, GCP, Azure, Kubernetes, GitHub, and GitLab.

Cynative connectors use credentials that are already present in your shell — there is no separate credential store, no new cloud identity to create, and no extra login step. Run Cynative from the shell where you normally run aws, gcloud, az, kubectl, gh, or glab, and the matching connectors register automatically. If a connector can retrieve credentials, it is listed in the startup inventory; if it cannot, it is skipped quietly.

Connector catalog

Connector id	System	Credential prerequisite	Guide
aws	AWS service APIs	AWS SDK default chain resolves and validates credentials live	AWS
eks	EKS Kubernetes APIs	AWS credentials validate (registers alongside aws)	AWS
gcp	Google Cloud APIs	Application Default Credentials resolve and validate live	GCP
gke	GKE Kubernetes APIs	GCP ADC validates (registers alongside gcp)	GCP
azure	Azure Resource Manager APIs	Azure credential chain mints a test ARM control-plane token	Azure
aks	AKS Kubernetes APIs	Azure credential chain mints a test ARM token (registers alongside azure)	Azure
kubernetes	Self-managed Kubernetes APIs	A kubeconfig context loads and a dial-guarded fetch of the configured ClusterRole succeeds	Kubernetes
github	GitHub REST API	A gh token for github.com validates live (probe GET /user → /rate_limit)	GitHub & GitLab
gitlab	GitLab REST API (gitlab.com or self-managed)	A GITLAB_TOKEN / glab token validates live (GET /api/v4/user)	GitHub & GitLab

The model can look up an exact AWS, GitHub, GitLab, GCP, Azure, or Kubernetes operation — with a request template — through the api_reference tool.

Three layers of read-only enforcement

Cynative combines up to three independent controls on every request, applied in order before any credential is attached:

Layer	What it does	Connectors where active
Network	Host pinning: the request host must match the authoritative endpoint for that connector (AWS service host, ARM endpoint, api.github.com, the kubeconfig server, etc.). Dial-time IP authorization: the resolved IP is checked against a deny set before the TCP connection is established, closing DNS-rebinding and TOCTOU windows.	All connectors
Action gate	Each request is classified to its cloud/API operation; the required IAM actions, GCP permissions, Azure RBAC actions, GitHub category, GitLab category, or Kubernetes RBAC verb are checked against the configured policy/role/ceiling. The gate fails closed: an unresolvable operation is denied.	All connectors
Credential	For AWS assumed-role identities only: credentials are re-vended via STS AssumeRole scoped to the configured policy (default SecurityAudit), putting an AWS-side boundary under the agent in addition to the client-side gate. IAM-user and root identities run unscoped with their base credentials, gated client-side only.	AWS (assumed-role identities only)

Defense at a glance

Control	AWS	GCP	Azure	GitHub	GitLab	EKS	GKE	AKS	K8s self-managed
Read-only by default	✓	✓	✓	✓	✓	✓	✓	✓	✓
Enforcement model	IAM action simulation	role permission eval	RBAC role-definition	read/write classifier	read/write classifier	live view RBAC	live view RBAC	live view RBAC	live view RBAC
Configurable exposure	✓ any policy ARN	✓ predefined roles	✓ role name/GUID	✓ (connectors.github.permissions: category[/subcategory] → read|write|none ceiling)	✓ (connectors.gitlab.permissions: category → read|write|none ceiling; default read-only, ci-variables blocked)	✓ (cluster_role)	✓ (cluster_role)	✓ (cluster_role)	✓ (cluster_role)
Credential downscoping	✓ STS-scoped, AWS-side — assumed-role identities only	— · CAB is GCS-only	— · no Entra primitive	— · user tokens	— · token scopes fixed at issue	— · authn/authz decoupled	— · authn/authz decoupled	— · authn/authz decoupled	— · authn/authz decoupled
Host pinning	✓	✓	✓ (cloud)	✓	✓ (+ port)	✓ (endpoint + port)	✓ (endpoint + port)	✓ (endpoint + port)	✓ (kubeconfig host + port)
Dial-time IP authorization	✓ internal-range deny	✓ internal-range deny	✓ internal-range deny	✓ internal-range deny	✓ internal-range deny (allow_private_network opt-in)	✓ IP pin	✓ IP pin (IP-literal only)	✓ IP pin	✓ IP pin (RFC1918 ok)
Model-supplied-credential rejection	✓	✓	✓ (+SAS)	✓	✓	✓	✓	✓	✓
Response redaction	✓	✓	✓	✓	✓	✓	✓	✓	✓

Cynative ships a vendor-curated, read-only baseline that you can re-point to a different policy or role per connector — a spectrum of exposure that is safe by default, not a binary read/write toggle. Only AWS has credential downscoping, and even there it applies to assumed-role identities only. For every other connector the action/RBAC gate is the sole client-side control. Kubernetes exposure is operator-selectable per connector via connectors.<id>.cluster_role (default the built-in view role).

Shared request model

All connector-backed requests go through the http_request tool. The model sets auth_provider to one of the registered connector ids and includes the connector-specific auth argument object (such as aws_auth, gcp_auth, or aks_auth).

Cynative applies request authorization before attaching credentials, then applies the dial guard when the HTTP transport connects:

1. The URL must use HTTPS.
2. The selected connector must authorize the request host.
3. The selected connector must authorize the requested action when it implements action authorization.
4. Credentials are attached only after host and action authorization pass.
5. At dial time, the selected connector or the default dial guard authorizes the resolved IP address before the credential-bearing request is sent. When the operator has configured a proxy through the standard HTTPS_PROXY / HTTP_PROXY / NO_PROXY variables, a proxied request connects only to that proxy and the address check is the proxy’s.

Shared configuration

Connector hardening is configured under the top-level connectors: key in ~/.cynative/config.yaml:

cache:
  dir: ~/.cynative/cache
  ttl: 24h

connectors:
  github:
    permissions:        # category[/subcategory] → read|write|none; omit for the secure default
      default: read
  gitlab:
    permissions:        # category → read|write|none; omit for the secure default
      default: read
  aws:
    policy: arn:aws:iam::aws:policy/SecurityAudit
  gcp:
    role: roles/viewer
  azure:
    role_definition: Reader

Most keys are also settable through CYNATIVE_* environment variables, for example CYNATIVE_CONNECTORS_AWS_POLICY, CYNATIVE_CONNECTORS_GCP_ROLE, CYNATIVE_CONNECTORS_AZURE_ROLE_DEFINITION, CYNATIVE_CACHE_DIR, and CYNATIVE_CACHE_TTL. The GitHub and GitLab permissions maps take a compact comma-separated key=value form, for example:

export CYNATIVE_CONNECTORS_GITHUB_PERMISSIONS="default=read,issues=write"

A non-empty environment value replaces the file map wholesale; a blank value is treated as unset.

Outbound proxies

Outbound proxy settings (HTTPS_PROXY, HTTP_PROXY, NO_PROXY) apply uniformly to every connector. See the proxy documentation for what is routed, what is not, and what an intercepting proxy can see.

Cynative itself reads almost no vendor environment variables directly — the vendor SDK/CLI does. The AWS SDK default chain reads AWS_PROFILE, AWS_ACCESS_KEY_ID, and related variables; Google ADC reads GOOGLE_APPLICATION_CREDENTIALS; the Azure credential chain reads AZURE_TENANT_ID and peers; go-gh reads GH_TOKEN; the GitLab connector reads GITLAB_TOKEN. To change which identity Cynative uses, set the vendor’s own variables (or run its login command) in the shell Cynative runs from. Cynative’s CYNATIVE_* variables control exposure settings and connector-specific knobs, not vendor credentials.