Introduction

Third-party Kubernetes operators often install Custom Resource Definitions, or CRDs, so they can expose domain-specific objects such as Certificate, KafkaTopic, or Prometheus. Accessing those resources is usually straightforward once you know the CRD's group, version, and plural name, but many people get stuck because they try to query them like built-in resources without first inspecting the CRD.

Find the exact resource name first

Before reading or creating a custom resource, inspect the CRD itself. That tells you the API group, supported versions, and the plural name that kubectl expects.

kubectl get crd
kubectl get crd certificates.cert-manager.io -o yaml

Inside the CRD definition, the most important fields are usually:

• 'spec.group'
• 'spec.versions'
• 'spec.names.kind'
• 'spec.names.plural'

For example, if the CRD is certificates.cert-manager.io, then:

• the group is cert-manager.io
• the kind is Certificate
• the plural resource name is certificates

That means kubectl queries should use the plural form, optionally with the group appended.

Query CRD instances with kubectl

Once you know the plural resource name, you can fetch objects exactly like native Kubernetes resources.

1kubectl get certificates
2kubectl get certificates -A
3kubectl describe certificate my-tls-cert
4kubectl get certificates.cert-manager.io -n production

The resource may be namespaced or cluster-scoped. The CRD definition shows that under spec.scope. If the scope is Namespaced, you need -n <namespace> or -A. If the scope is Cluster, namespace flags do nothing.

You can also inspect a single object as JSON or YAML:

kubectl get certificate my-tls-cert -n production -o yaml

That is often the fastest way to understand the fields exposed by a third-party controller.

Discover CRDs from the aggregated API view

When you do not know the exact group or short name yet, kubectl api-resources is a useful discovery step because it shows the resource names that the API server currently exposes.

kubectl api-resources | grep cert
kubectl api-resources --api-group=cert-manager.io

This is often faster than guessing a plural form from memory, especially when several third-party operators install similar-sounding resource kinds.

Create or update custom resources from manifests

Once a CRD is installed, you interact with its instances through standard manifests. The apiVersion is the CRD group plus version, and the kind matches the custom kind defined by the CRD.

1apiVersion: cert-manager.io/v1
2kind: Certificate
3metadata:
4  name: my-tls-cert
5  namespace: production
6spec:
7  secretName: my-tls-secret
8  issuerRef:
9    name: letsencrypt-prod
10    kind: ClusterIssuer
11  dnsNames:
12    - example.com

Apply it with:

kubectl apply -f certificate.yaml

This is the same workflow you use for Deployments or Services. The difference is that the schema came from a third-party CRD rather than the core Kubernetes API.

Access CRDs programmatically

If you need to read CRD objects from code, use a client that supports dynamic Kubernetes resources. In Python, the official client includes a CustomObjectsApi for this case.

1from kubernetes import client, config
2
3config.load_kube_config()
4
5api = client.CustomObjectsApi()
6result = api.get_namespaced_custom_object(
7    group="cert-manager.io",
8    version="v1",
9    namespace="production",
10    plural="certificates",
11    name="my-tls-cert",
12)
13
14print(result["metadata"]["name"])
15print(result["spec"]["secretName"])

The important inputs are exactly the same ones you inspected from the CRD: group, version, plural, and optionally namespace.

Access control still applies

CRDs are not exempt from RBAC. You may be able to see the CRD definition itself but still be blocked from listing or reading instances. If a third-party operator installed the CRD in your cluster, confirm that your user or service account can access the resource type.

For example:

kubectl auth can-i get certificates.cert-manager.io -n production
kubectl auth can-i list certificates.cert-manager.io -A

If those checks return no, the problem is permissions, not syntax.

Common Pitfalls

The most common mistake is querying the kind instead of the plural resource name. kubectl get Certificate may not behave the way you expect, while kubectl get certificates is the correct resource form.

Another issue is forgetting the API group. Short names sometimes work, but when there are collisions or aliases, using the fully qualified resource such as certificates.cert-manager.io is safer.

Namespace confusion is also common. Many custom resources are namespaced, but some are cluster-scoped. Check spec.scope in the CRD before assuming the object should be visible in a namespace.

Finally, do not assume the CRD schema from memory. Operators evolve, versions deprecate fields, and examples on the internet may refer to older API versions. Always inspect the CRD actually installed in your cluster.

Summary

• Inspect the CRD first to find its group, version, kind, and plural name.
• Use the plural resource name with kubectl get, describe, and apply.
• Read the CRD's scope so you know whether the resource is namespaced or cluster-scoped.
• Use CustomObjectsApi or an equivalent dynamic client when accessing CRDs from code.
• Check RBAC if the syntax looks correct but access still fails.