# Kubernetes API Resources

> zop.dev's provisioner bridges into any reachable cluster and manages 11 Kubernetes resource kinds directly: configmap, cronjob, deployment, hpa, job, namespace, node, pdb, pod, secret, and service. Cluster credentials can be supplied as a kubeconfig, a host with certificates, a bearer token, or a username and password.

Source: https://zop.dev/integrations/provision/cross-provider/kubernetes-api-resources
Updated: 2026-08-19

---

Sometimes you need to manage raw Kubernetes objects, not just zop.dev's higher-level abstractions. The provisioner bridges into any reachable cluster and manages core API objects directly.

## Handlers for core Kubernetes object kinds

Eleven Kubernetes resource handlers: configmap, cronjob, deployment, hpa, job, namespace, node, pdb, pod, secret, and service.

## Cluster credentials in several shapes

```text
Cluster credentials accepted in multiple shapes: kubeconfig path or content, host with CA and client cert/key, bearer token, username/password, context, namespace, and insecure flag.
```

## The gke bridge fetches the kubeconfig

Reached via the GCP gke bridge resource type, which fetches the kubeconfig and delegates to the k8s handler registry via k8s_resource_type.

## The escape hatch below the abstractions

Most of the platform speaks in higher-level nouns: services, namespaces, datastores. This is
the layer beneath: 11 handlers for core API objects, for the cases the abstractions do not
cover. Patching a configmap the platform did not author, draining decisions that need node
objects, one-off jobs, inspecting a pod directly. The value is reach; the discipline is using
it for what genuinely has no higher-level expression, because objects managed here live
outside the specs the platform reconciles.

## Reached through the gke bridge

The path in is indirect by design: the GCP `gke` bridge resource type fetches the cluster's
kubeconfig and delegates to the k8s handler registry via `k8s_resource_type`. One API flow
covers "find the cluster, authenticate, act on an object inside it", which is also why the
credential input is so flexible. Kubeconfig by path or content, host with CA and client
certificate and key, bearer token, username and password, plus context, namespace, and an
insecure flag. That flexibility exists for reachability across cluster generations; the
`insecure` flag in particular is a debugging tool, not a configuration.

## Edits that Helm will fight

The sharp edge of raw object access: anything under a Helm release's management is owned by
that release. Hand-edit a deployment that a release renders, and the change holds only until
the next upgrade re-renders it, leaving drift that looks like a mystery regression weeks later.
The safe uses are objects nothing else owns, or reads. For owned objects, change the release's
values instead, so the source of truth stays where the platform expects it. Secrets deserve
one extra caution: they are among the 11 kinds, and access to this layer is access to every
secret in reach of the credential supplied.