f

src/pentesting-cloud/kubernetes-security/kubernetes-enumeration.md

@@ -209,6 +209,36 @@ kubectl get pods -A -o custom-columns='NS:.metadata.namespace,NAME:.metadata.nam
 - `metadata.finalizers` and `metadata.deletionTimestamp` explain resources stuck in deletion and can reveal cleanup controllers or persistence/disruption tricks.
 - `status`, Events, and conditions can reveal node placement, pod IPs, image IDs, failure messages, scheduling issues, admission denials, and controller progress. They are useful clues, but audit logs are still required to prove who performed an action.
 
+### Dynamic Resource Allocation and device evidence
+
+If the cluster uses GPUs, NICs, FPGAs, or other specialized hardware, check whether Kubernetes Dynamic Resource Allocation (DRA) is present. DRA uses `resource.k8s.io` objects such as `DeviceClass`, `ResourceSlice`, `ResourceClaim`, and `ResourceClaimTemplate` to describe available devices and claim them for Pods. These objects can reveal which nodes can access valuable hardware, which driver manages it, and which workload has an allocation.
+
+```bash
+kubectl api-resources --api-group=resource.k8s.io
+kubectl get deviceclasses.resource.k8s.io 2>/dev/null
+kubectl get resourceslices.resource.k8s.io 2>/dev/null
+kubectl get resourceclaims.resource.k8s.io -A 2>/dev/null
+kubectl get resourceclaimtemplates.resource.k8s.io -A 2>/dev/null
+kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"/"}{.metadata.name}{" claims="}{.spec.resourceClaims}{" node="}{.spec.nodeName}{"\n"}{end}'
+kubectl get daemonsets,pods -A -o wide | grep -Ei 'dra|device|gpu|nvidia|amd|intel|sriov|fpga'
+```
+
+During review, restrict writes to cluster-scoped `DeviceClass` and `ResourceSlice` objects to admins and DRA drivers, and keep `ResourceClaim` / `ResourceClaimTemplate` rights scoped to the namespaces that need them. Driver permissions to update `ResourceClaim` status should be explicit and narrow. On nodes, the kubelet PodResources API is commonly exposed through `/var/lib/kubelet/pod-resources/kubelet.sock`; monitoring DaemonSets may mount that directory to inspect assigned devices, so review those Pods like other privileged node agents.
+
+### ClusterTrustBundle and add-on certificate trust
+
+Recent clusters may expose `ClusterTrustBundle` objects in the `certificates.k8s.io` API group. They are cluster-scoped X.509 trust anchor bundles that Pods can mount through projected volumes. Broad read access is expected, but write access is sensitive because changing trusted roots can affect webhooks, aggregated APIs, service meshes, and applications that consume cluster-distributed CA material.
+
+```bash
+kubectl api-resources --api-group=certificates.k8s.io | grep -i clustertrustbundle
+kubectl get clustertrustbundles.certificates.k8s.io 2>/dev/null
+kubectl get clustertrustbundle <name> -o yaml 2>/dev/null
+kubectl get pods -A -o yaml | grep -n -E 'clusterTrustBundle|trustBundle|caBundle'
+kubectl get apiservices -o jsonpath='{range .items[*]}{.metadata.name}{" insecure="}{.spec.insecureSkipTLSVerify}{" service="}{.spec.service.namespace}{"/"}{.spec.service.name}{"\n"}{end}'
+```
+
+During review, record `signerName`, bundle fingerprints, writer identities, projected-volume consumers, and any trust-distribution controller such as cert-manager trust-manager. Treat `APIService` objects with `insecureSkipTLSVerify: true`, stale `caBundle` values, or broad permissions to patch APIService/webhook trust fields as certificate-trust findings rather than ordinary object inventory.
+
 ### Get Current Privileges
 
 {{#tabs }}