- Kubernetes API is organized into API groups to manage different sets of resources.
- API groups help structure APIs and enable versioning.
- Each API group is accessed via
apis/<group>/<version>in the Kubernetes API server.
API groups follow this format:
/apis/<api-group>/<version>
For example:
/apis/apps/v1
/apis/rbac.authorization.k8s.io/v1
/apis/networking.k8s.io/v1
Some core Kubernetes APIs do not have an API group:
/api/v1
Example:
Pods,Services,ConfigMaps, andSecretsbelong to the core API (api/v1).
| API Group | Example Resource | API Endpoint |
|---|---|---|
"" (core) |
Pods, Services, ConfigMaps | /api/v1 |
apps |
Deployments, StatefulSets, DaemonSets | /apis/apps/v1 |
batch |
Jobs, CronJobs | /apis/batch/v1 |
rbac.authorization.k8s.io |
Roles, ClusterRoles, RoleBindings | /apis/rbac.authorization.k8s.io/v1 |
networking.k8s.io |
NetworkPolicies, Ingress | /apis/networking.k8s.io/v1 |
policy |
PodSecurityPolicies (deprecated) | /apis/policy/v1 |
storage.k8s.io |
StorageClasses, CSI drivers | /apis/storage.k8s.io/v1 |
apiextensions.k8s.io |
CustomResourceDefinitions (CRDs) | /apis/apiextensions.k8s.io/v1 |
admissionregistration.k8s.io |
ValidatingWebhookConfigurations | /apis/admissionregistration.k8s.io/v1 |
Use kubectl to list available API groups:
kubectl api-versionsThis lists all active API groups and their versions.
List all available API resources and their groups:
kubectl api-resourcesFilter by a specific API group:
kubectl api-resources --api-group=appsCheck if a specific API resource exists:
kubectl explain deployment --api-version=apps/v1RBAC rules use API groups to define permissions.
Example: Role allowing read-only access to Pods (core API):
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: default
name: pod-reader
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list", "watch"]
apiGroups: [""]means core API (api/v1).
Example: ClusterRole allowing modifications to Deployments (apps API group):
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: deployment-editor
rules:
- apiGroups: ["apps"]
resources: ["deployments"]
verbs: ["get", "list", "update", "patch", "delete"]
apiGroups: ["apps"]refers to the apps/v1 API group.
✅ Limit RBAC permissions:
- Do not grant cluster-wide permissions unless necessary.
- Use Roles instead of ClusterRoles when possible.
✅ Control access to Custom Resources (CRDs):
- Avoid giving users permissions to
apiextensions.k8s.iounless needed. - Example: Restricting CRD modifications:
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: crd-restrict rules: - apiGroups: ["apiextensions.k8s.io"] resources: ["customresourcedefinitions"] verbs: ["get", "list"]
✅ Secure network access to the API Server:
- Use NetworkPolicies to restrict API access.
- Example: Restrict access to the API Server:
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: api-server-restrict namespace: kube-system spec: podSelector: matchLabels: component: kube-apiserver ingress: - from: - podSelector: matchLabels: role: trusted
✅ Monitor API usage with audit logs:
Enable audit logging to track API calls:
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: Metadata
resources:
- group: "*"
resources: ["*"]✅ Disable unused API groups:
- If certain API groups are not needed, disable them via the API server:
kube-apiserver --runtime-config=apiextensions.k8s.io/v1=false
| Command | Description |
|---|---|
kubectl api-versions |
List available API groups and versions. |
kubectl api-resources |
Show all API resources and their groups. |
kubectl explain <resource> --api-version=<group/version> |
Describe a resource in a specific API group. |
kubectl get --raw /apis |
Get all available API groups in raw format. |
kubectl auth can-i <verb> <resource> --api-group=<group> |
Check RBAC permissions for an API group. |
Example: Check if a user can create deployments:
kubectl auth can-i create deployments --api-group=apps🔍 Check if an API resource is available
kubectl explain <resource>🔍 Verify API access with RBAC
kubectl auth can-i get pods --api-group=""
kubectl auth can-i list deployments --api-group=apps🔍 List disabled API groups
kubectl get --raw /apis | jq .🔍 Check API server logs for errors
kubectl logs -n kube-system -l component=kube-apiserverKubernetes allows defining Custom Resource Definitions (CRDs), which create new API groups.
Example: Creating a CRD for "Database" resources:
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
name: databases.mycompany.com
spec:
group: mycompany.com
versions:
- name: v1
served: true
storage: true
scope: Namespaced
names:
plural: databases
singular: database
kind: DatabaseAfter applying:
kubectl apply -f database-crd.yaml
kubectl get crd
kubectl get databases.mycompany.com- Kubernetes APIs are structured into API groups.
- Some resources belong to the core API (
api/v1), while others have specific API groups (apis/<group>/v1). - Use RBAC to secure access to API groups.
- Audit API usage with logs and policies.
- Restrict access to API groups with NetworkPolicies and RBAC.
- Disable unused API groups for better security.