> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cynative.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 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](/connectors/aws) |
| `eks` | EKS Kubernetes APIs | AWS credentials validate (registers alongside `aws`) | [AWS](/connectors/aws) |
| `gcp` | Google Cloud APIs | Application Default Credentials resolve and validate live | [GCP](/connectors/gcp) |
| `gke` | GKE Kubernetes APIs | GCP ADC validates (registers alongside `gcp`) | [GCP](/connectors/gcp) |
| `azure` | Azure Resource Manager APIs | Azure credential chain mints a test ARM control-plane token | [Azure](/connectors/azure) |
| `aks` | AKS Kubernetes APIs | Azure credential chain mints a test ARM token (registers alongside `azure`) | [Azure](/connectors/azure) |
| `kubernetes` | Self-managed Kubernetes APIs | A kubeconfig context loads **and** a dial-guarded fetch of the configured ClusterRole succeeds | [Kubernetes](/connectors/kubernetes) |
| `github` | GitHub REST API | A `gh` token for `github.com` validates live (probe `GET /user` → `/rate_limit`) | [GitHub & GitLab](/connectors/github-gitlab) |
| `gitlab` | GitLab REST API (gitlab.com or self-managed) | A `GITLAB_TOKEN` / `glab` token validates live (`GET /api/v4/user`) | [GitHub & GitLab](/connectors/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`:

```yaml theme={null}
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:

```bash theme={null}
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](/proxy) for what is routed, what is not, and what an intercepting proxy can see.

<Note>
  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.
</Note>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.