Add local cloud Kubernetes updates

Author: carlospolop

src/pentesting-cloud/gcp-security/gcp-services/gcp-containers-gke-and-composer-enum.md

@@ -74,6 +74,24 @@ You can read more about `gcloud` for containers [here](https://cloud.google.com/
 
 This is a simple script to enumerate kubernetes in GCP: [https://gitlab.com/gitlab-com/gl-security/security-operations/gl-redteam/gcp_k8s_enum](https://gitlab.com/gitlab-com/gl-security/security-operations/gl-redteam/gcp_k8s_enum)
 
+### Current GKE identity and metadata checks
+
+When reviewing modern GKE clusters, separate Google Cloud IAM permissions, Kubernetes RBAC, pod workload identity, and node credentials. A Google principal can often retrieve cluster endpoint data with `container.clusters.get`, but the resulting Kubernetes requests still need to pass GKE/Kubernetes authorization and any network restrictions such as private endpoints or authorized networks.
+
+Workload Identity Federation for GKE is the preferred way for pods to access Google Cloud APIs. Check whether the cluster has a workload pool and whether Kubernetes service accounts are mapped directly as IAM principals or are allowed to impersonate IAM service accounts:
+
+```bash
+gcloud container clusters describe <cluster> --region <region> \
+  --format='value(workloadIdentityConfig.workloadPool)'
+
+kubectl get serviceaccounts -A -o yaml | grep -n 'iam.gke.io' -B 5 -A 8
+kubectl get pods -A -o custom-columns='NS:.metadata.namespace,NAME:.metadata.name,SA:.spec.serviceAccountName,NODE:.spec.nodeName'
+```
+
+If a service account has the annotation `iam.gke.io/gcp-service-account`, review the IAM service account policy for `roles/iam.workloadIdentityUser` grants to Kubernetes service account principals. Also check IAM allow policies for direct workload identity principals or broad principal sets.
+
+Metadata access depends on cluster mode, node pool configuration, and workload settings. Do not assume every pod can steal the node service account. In Workload Identity-enabled environments, ordinary pods should use the GKE metadata server to obtain the workload identity intended for their Kubernetes service account. Node compromise, `hostNetwork` pods in some Standard configurations, and legacy node metadata exposure can still change the blast radius, so verify the actual node pool metadata mode, node service account, OAuth scopes, and pod placement.
+
 ### TLS Boostrap Privilege Escalation
 
 Initially this privilege escalation technique allowed to **privesc inside the GKE cluster** effectively allowing an attacker to **fully compromise it**.
@@ -104,4 +122,3 @@ Even if the API **doesn't allow to modify resources**, it could be possible to f
 {{#include ../../../banners/hacktricks-training.md}}
 
 
-

src/pentesting-cloud/kubernetes-security/abusing-roles-clusterroles-in-kubernetes/README.md

@@ -357,7 +357,8 @@ curl -v -H "Authorization: Bearer <jwt_token>" https://<master_ip>:<port>/api/v1
 
 ### Creating and Reading Secrets
 
-There is a special kind of a Kubernetes secret of type **kubernetes.io/service-account-token** which stores serviceaccount tokens.
+There is a special kind of Kubernetes Secret of type **kubernetes.io/service-account-token** which stores service account tokens. Modern Kubernetes versions do **not** automatically create one long-lived Secret for every ServiceAccount; projected, bound TokenRequest tokens are the normal workload path. However, manually created service account token Secrets are still supported, and upgraded or legacy clusters may still contain long-lived token Secrets. Current clusters can also mark unused auto-generated legacy token Secrets invalid and eventually clean them up, leaving labels such as `kubernetes.io/legacy-token-invalid-since` and `kubernetes.io/legacy-token-last-used`.
+
 If you have permissions to create and read secrets, and you also know the serviceaccount's name, you can create a secret as follows and then steal the victim serviceaccount's token from it:
 
 ```yaml
@@ -870,4 +871,3 @@ https://github.com/aquasecurity/kube-bench
 {{#include ../../../banners/hacktricks-training.md}}
 
 
-

src/pentesting-cloud/kubernetes-security/exposing-services-in-kubernetes.md

@@ -116,6 +116,8 @@ kubectl get services --all-namespaces -o=custom-columns='NAMESPACE:.metadata.nam
 
 Traffic that ingresses into the cluster with the **external IP** (as **destination IP**), on the Service port, will be **routed to one of the Service endpoints**. `externalIPs` are not managed by Kubernetes and are the responsibility of the cluster administrator.
 
+`externalIPs` is a sensitive route-control field because a user who can set it might claim traffic for an IP address the Service owner should not control if the surrounding network routes that IP to the cluster. Kubernetes announced the deprecation and planned removal of Service `externalIPs` in v1.36, so prefer controller-owned exposure mechanisms such as LoadBalancer integrations or Gateway API where possible, and restrict/admit this field carefully while it still exists.
+
 In the Service spec, `externalIPs` can be specified along with any of the `ServiceTypes`. In the example below, "`my-service`" can be accessed by clients on "`80.11.12.10:80`" (`externalIP:port`)
 
 ```yaml
@@ -160,6 +162,21 @@ List all ExternalNames:
 kubectl get services --all-namespaces | grep ExternalName
 ```
 
+### EndpointSlices
+
+EndpointSlices show the concrete backend addresses and ports that a Service currently routes to. They are especially useful when a Service has no selector, when labels do not explain the traffic path, or when only some backends are ready.
+
+List EndpointSlices associated with Services:
+
+```bash
+kubectl get endpointslices --all-namespaces
+kubectl get endpointslice -n <namespace> -l kubernetes.io/service-name=<service-name> -o yaml
+kubectl get endpointslice -n <namespace> -l kubernetes.io/service-name=<service-name> \
+  -o custom-columns='NAME:.metadata.name,ADDR:.endpoints[*].addresses,READY:.endpoints[*].conditions.ready,PORTS:.ports[*].port'
+```
+
+When reviewing exposure, compare the Service selector with the EndpointSlice `targetRef`, endpoint addresses, readiness conditions, and ports. A selectorless Service can be paired with manually managed EndpointSlices and route traffic to non-Pod or unexpected destinations.
+
 ### Ingress
 
 Unlike all the above examples, **Ingress is NOT a type of service**. Instead, it sits **in front of multiple services and act as a “smart router”** or entrypoint into your cluster.
@@ -171,28 +188,37 @@ The default GKE ingress controller will spin up a [HTTP(S) Load Balancer](https:
 The YAML for a Ingress object on GKE with a [L7 HTTP Load Balancer](https://cloud.google.com/compute/docs/load-balancing/http/) might look like this:
 
 ```yaml
-apiVersion: extensions/v1beta1
+apiVersion: networking.k8s.io/v1
 kind: Ingress
 metadata:
   name: my-ingress
 spec:
-  backend:
-    serviceName: other
-    servicePort: 8080
+  defaultBackend:
+    service:
+      name: other
+      port:
+        number: 8080
   rules:
     - host: foo.mydomain.com
       http:
         paths:
-          - backend:
-              serviceName: foo
-              servicePort: 8080
+          - path: /
+            pathType: Prefix
+            backend:
+              service:
+                name: foo
+                port:
+                  number: 8080
     - host: mydomain.com
       http:
         paths:
-          - path: /bar/*
+          - path: /bar
+            pathType: Prefix
             backend:
-              serviceName: bar
-              servicePort: 8080
+              service:
+                name: bar
+                port:
+                  number: 8080
 ```
 
 List all the ingresses:
@@ -207,12 +233,29 @@ Although in this case it's better to get the info of each one by one to read it
 kubectl get ingresses --all-namespaces -o=yaml
 ```
 
+### Gateway API
+
+Gateway API is the newer Kubernetes API for exposing Services. It separates infrastructure-owned Gateway objects from application-owned Route objects such as HTTPRoute. This is useful for delegation, but it also means exposure can be split across namespaces.
+
+List Gateway API exposure objects:
+
+```bash
+kubectl get gatewayclasses
+kubectl get gateways --all-namespaces
+kubectl get httproutes --all-namespaces
+kubectl get gateway -n <namespace> <gateway-name> -o yaml
+kubectl get httproute -n <namespace> <route-name> -o yaml
+```
+
+Check Gateway listeners, allowed route namespaces, Route `parentRefs`, hostnames, filters, backend references, and status conditions such as whether the route was accepted. A Route that is accepted by a shared Gateway can expose a backend even when no legacy Ingress object exists.
+
 ### References
 
 - [https://medium.com/google-cloud/kubernetes-nodeport-vs-loadbalancer-vs-ingress-when-should-i-use-what-922f010849e0](https://medium.com/google-cloud/kubernetes-nodeport-vs-loadbalancer-vs-ingress-when-should-i-use-what-922f010849e0)
 - [https://kubernetes.io/docs/concepts/services-networking/service/](https://kubernetes.io/docs/concepts/services-networking/service/)
+- [https://kubernetes.io/blog/2026/05/14/kubernetes-v1-36-deprecation-and-removal-of-service-externalips/](https://kubernetes.io/blog/2026/05/14/kubernetes-v1-36-deprecation-and-removal-of-service-externalips/)
+- [https://kubernetes.io/docs/concepts/services-networking/endpoint-slices/](https://kubernetes.io/docs/concepts/services-networking/endpoint-slices/)
+- [https://gateway-api.sigs.k8s.io/](https://gateway-api.sigs.k8s.io/)
 
 {{#include ../../banners/hacktricks-training.md}}
 
-
-

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

@@ -192,6 +192,23 @@ k api-resources --namespaced=false #Resources NOT specific to a namespace
 {{#endtab }}
 {{#endtabs }}
 
+### Object metadata worth checking
+
+When you can read an object, export the full YAML or JSON instead of relying only on table output or `describe`. The most useful security context is often in generic object fields that exist across many resource types:
+
+```bash
+kubectl get pod <pod> -n <ns> -o yaml
+kubectl get deploy <deploy> -n <ns> -o json | jq '.metadata, .spec, .status'
+kubectl get pods -A -o custom-columns='NS:.metadata.namespace,NAME:.metadata.name,SA:.spec.serviceAccountName,NODE:.spec.nodeName,PHASE:.status.phase'
+```
+
+- `metadata.uid`, `name`, `namespace`, `apiVersion` and `kind` identify the exact object and avoid confusion between objects with the same name in different namespaces or API groups.
+- `metadata.labels` and selectors connect Services, Deployments, ReplicaSets, Pods, NetworkPolicies and automation. Following selectors is often the fastest way to identify the real backend pods for a Service.
+- `metadata.annotations` can leak operational context such as ingress behavior, cloud load balancer settings, GitOps or Helm metadata, policy exemptions, and service mesh configuration. They should not contain secrets, but real clusters often expose useful clues there.
+- `metadata.ownerReferences` shows controller lineage. If a Pod is owned by a ReplicaSet owned by a Deployment, changing or deleting only the Pod usually does not fix the source.
+- `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.
+
 ### Get Current Privileges
 
 {{#tabs }}
@@ -330,7 +347,7 @@ kurl -k -v https://$APISERVER/api/v1/namespaces/{namespace}/serviceaccounts
 
 ### Get Deployments
 
-The deployments specify the **components** that need to be **run**.
+Deployments specify the desired state for stateless application workloads. They create ReplicaSets, and those ReplicaSets create Pods.
 
 {{#tabs }}
 {{#tab name="kubectl" }}
@@ -345,7 +362,30 @@ k get deployments -n custnamespace
 {{#tab name="API" }}
 
 ```bash
-kurl -v https://$APISERVER/api/v1/namespaces/<namespace>/deployments/
+kurl -v https://$APISERVER/apis/apps/v1/namespaces/<namespace>/deployments/
+```
+
+{{#endtab }}
+{{#endtabs }}
+
+### Get StatefulSets
+
+StatefulSets manage Pods that need stable names, ordered rollout behavior, and often per-replica persistent volumes.
+
+{{#tabs }}
+{{#tab name="kubectl" }}
+
+```bash
+k get statefulsets
+k get statefulsets -n custnamespace
+```
+
+{{#endtab }}
+
+{{#tab name="API" }}
+
+```bash
+kurl -v https://$APISERVER/apis/apps/v1/namespaces/<namespace>/statefulsets/
 ```
 
 {{#endtab }}
@@ -391,7 +431,7 @@ k get services -n custnamespace
 {{#tab name="API" }}
 
 ```bash
-kurl -v https://$APISERVER/api/v1/namespaces/default/services/
+kurl -v https://$APISERVER/api/v1/namespaces/<namespace>/services/
 ```
 
 {{#endtab }}
@@ -421,7 +461,7 @@ kurl -v https://$APISERVER/api/v1/nodes/
 
 ### Get DaemonSets
 
-**DaeamonSets** allows to ensure that a **specific pod is running in all the nodes** of the cluster (or in the ones selected). If you delete the DaemonSet the pods managed by it will be also removed.
+**DaemonSets** ensure that a **specific Pod is running on all selected nodes** of the cluster. If you delete the DaemonSet, the Pods managed by it will also be removed.
 
 {{#tabs }}
 {{#tab name="kubectl" }}
@@ -435,29 +475,53 @@ k get daemonsets
 {{#tab name="API" }}
 
 ```bash
-kurl -v https://$APISERVER/apis/extensions/v1beta1/namespaces/default/daemonsets
+kurl -v https://$APISERVER/apis/apps/v1/namespaces/<namespace>/daemonsets
+```
+
+{{#endtab }}
+{{#endtabs }}
+
+### Get Jobs
+
+Jobs create Pods that run until completion. They are commonly used for migrations, backups, batch work, and one-off administrative tasks.
+
+{{#tabs }}
+{{#tab name="kubectl" }}
+
+```bash
+k get jobs
+k get jobs -n custnamespace
+```
+
+{{#endtab }}
+
+{{#tab name="API" }}
+
+```bash
+kurl -v https://$APISERVER/apis/batch/v1/namespaces/<namespace>/jobs
 ```
 
 {{#endtab }}
 {{#endtabs }}
 
-### Get cronjob
+### Get CronJobs
 
-Cron jobs allows to schedule using crontab like syntax the launch of a pod that will perform some action.
+CronJobs use a crontab-like schedule to create Jobs that launch Pods for task-style execution.
 
 {{#tabs }}
 {{#tab name="kubectl" }}
 
 ```bash
 k get cronjobs
+k get cronjobs -n custnamespace
 ```
 
 {{#endtab }}
 
 {{#tab name="API" }}
 
 ```bash
-kurl -v https://$APISERVER/apis/batch/v1beta1/namespaces/<namespace>/cronjobs
+kurl -v https://$APISERVER/apis/batch/v1/namespaces/<namespace>/cronjobs
 ```
 
 {{#endtab }}
@@ -849,6 +913,3 @@ https://www.cyberark.com/resources/threat-research-blog/kubernetes-pentest-metho
 {{#endref}}
 
 {{#include ../../banners/hacktricks-training.md}}
-
-
-

src/pentesting-cloud/kubernetes-security/kubernetes-hardening/kubernetes-securitycontext-s.md

@@ -55,12 +55,32 @@ Note that the attributes set in **both SecurityContext and PodSecurityContext**,
 | <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>seccompProfile</strong></a><br><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#seccompprofile-v1-core"><em>SeccompProfile</em></a></p>                                                               | The **seccomp options** to use by this container.                                                                                                                                                                                                                                                                     |
 | <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>windowsOptions</strong></a><br><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#windowssecuritycontextoptions-v1-core"><em>WindowsSecurityContextOptions</em></a></p>                                 | The **Windows specific settings** applied to all containers.                                                                                                                                                                                                                                                          |
 
+## Practical workload review checklist
+
+When reviewing a Pod or workload template, inspect both `spec.securityContext` and every container-level `securityContext` under `containers`, `initContainers`, and `ephemeralContainers`. Container-level fields can override the pod-level defaults, so a safe-looking pod default does not guarantee that every container is safe.
+
+High-risk combinations to prioritize:
+
+- `privileged: true`, especially with `hostPID`, `hostIPC`, `hostNetwork`, `hostPath`, host ports, or runtime socket mounts.
+- Added capabilities such as `SYS_ADMIN`, `NET_ADMIN`, `SYS_PTRACE`, `SYS_MODULE`, `DAC_READ_SEARCH`, or `DAC_OVERRIDE`.
+- `allowPrivilegeEscalation: true` or unset in containers that can execute attacker-controlled code.
+- `seccompProfile: Unconfined`, `procMount: Unmasked`, or missing runtime profiles on sensitive workloads.
+- Writable root filesystems or broad writable volume mounts in workloads that process untrusted input.
+- Missing CPU, memory, or ephemeral-storage requests and limits in multi-tenant namespaces.
+
+For most application workloads, a good baseline is to run as a non-root UID, set `runAsNonRoot: true`, set `allowPrivilegeEscalation: false`, drop all capabilities and add back only the minimum required ones, use `seccompProfile: RuntimeDefault`, prefer a read-only root filesystem, and avoid host namespaces, hostPath mounts, and privileged mode.
+
+At cluster level, use [Pod Security Admission](https://kubernetes.io/docs/concepts/security/pod-security-admission/) namespace labels to enforce the Kubernetes [Pod Security Standards](https://kubernetes.io/docs/concepts/security/pod-security-standards/) where possible. Use `restricted` for namespaces that can support it, at least `baseline` for ordinary application namespaces, and keep privileged exceptions narrow, documented, and isolated to trusted platform namespaces or node pools.
+
 ## References
 
 - [https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core)
 - [https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core)
+- [https://kubernetes.io/docs/tasks/configure-pod-container/security-context/](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/)
+- [https://kubernetes.io/docs/concepts/security/linux-kernel-security-constraints/](https://kubernetes.io/docs/concepts/security/linux-kernel-security-constraints/)
+- [https://kubernetes.io/docs/concepts/security/pod-security-standards/](https://kubernetes.io/docs/concepts/security/pod-security-standards/)
+- [https://kubernetes.io/docs/concepts/security/pod-security-admission/](https://kubernetes.io/docs/concepts/security/pod-security-admission/)
 
 {{#include ../../../banners/hacktricks-training.md}}
 
 
-