api_access_via_pod

Accessing the Kubernetes API from Within a Pod

Pods running in a Kubernetes cluster can interact with the API server using their Service Account tokens. These tokens are automatically mounted into pods, allowing them to make authenticated API calls, provided their Service Account has the necessary RBAC permissions.

1. Overview of In-Pod API Access

When a pod needs to communicate with the Kubernetes API server:

It typically uses the in-cluster API server address: https://kubernetes.default.svc (which resolves to https://kubernetes).
Authentication is handled using a Service Account token.
This token is automatically mounted into each pod at /var/run/secrets/kubernetes.io/serviceaccount/token.
The CA certificate for verifying the API server's certificate is also mounted at /var/run/secrets/kubernetes.io/serviceaccount/ca.crt.
The pod's namespace is mounted at /var/run/secrets/kubernetes.io/serviceaccount/namespace.

The permissions granted to the pod depend on the Role or ClusterRole bound to its Service Account.

(The original "Via no auth ..." section with an IP address is less relevant for typical in-pod access, as https://kubernetes is the standard service discovery FQDN, and it generally requires authentication.)

2. Using the Default Service Account

Every namespace has a default Service Account. Pods that do not specify a serviceAccountName use this default SA.

2.1 Inspecting the Default Service Account (Admin Task - Optional)

As an administrator, you can inspect the default Service Account and its associated secrets (if any).

Note on Service Account Token Secrets (Kubernetes 1.24+):

Secrets containing service account tokens are no longer automatically generated for every service account since K8s 1.24.
The commands below showing kubectl describe secret <token-name> are for inspecting such secrets if they exist (e.g., in older K8s versions or if manually created). Pods themselves will always get their token mounted via the ProjectedVolume mechanism, regardless of whether a separate Secret object for that token exists.

# List secrets (might show SA token secrets in older K8s versions)
kubectl get secrets -n default

# Describe the default Service Account
kubectl describe sa default -n default

# If a token secret for the default SA exists (e.g., default-token-xxxxx), describe it:
# kubectl describe secret default-token-xxxxx -n default

2.2 Accessing the API from a Pod (using Default SA)

Run a temporary pod with shell access: We'll use a pod with common utilities (like curl) to test API access. The xxradar/hackon image is used here; you can substitute any image that includes curl.

# This command runs a pod named 'testpod' (or similar, name is auto-generated if --name not used)
# using the default service account in the 'default' namespace.
kubectl run testpod -it --rm --image xxradar/hackon -- bash

Inside the testpod shell, execute the following commands: These commands use the automatically mounted Service Account token and CA certificate.

# Define variables for convenience
KUBE_TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
KUBE_CA="/var/run/secrets/kubernetes.io/serviceaccount/ca.crt"
NAMESPACE=$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace)

# Test connectivity (might be unauthenticated or limited for default SA without specific roles)
echo "--- Testing basic connectivity ---"
curl -kv https://kubernetes/api/v1/
curl -kv https://kubernetes/version

# Using the CA certificate for secure communication
echo "--- Securely listing pods in current namespace ($NAMESPACE) ---"
curl --cacert $KUBE_CA -H "Authorization: Bearer $KUBE_TOKEN" "https://kubernetes/api/v1/namespaces/$NAMESPACE/pods"

echo "--- Listing available APIs ---"
curl --cacert $KUBE_CA -H "Authorization: Bearer $KUBE_TOKEN" "https://kubernetes/apis/"

# Example: Trying to access a specific Calico CRD (will fail if CRD not present or no permission)
# curl --cacert $KUBE_CA -H "Authorization: Bearer $KUBE_TOKEN" "https://kubernetes/apis/crd.projectcalico.org/v1"

# Example: Trying to access this pod's own details (replace 'testpod' if your pod name is different)
# This requires the SA to have 'get' permission on 'pods' in its namespace.
# curl --cacert $KUBE_CA -H "Authorization: Bearer $KUBE_TOKEN" "https://kubernetes/api/v1/namespaces/$NAMESPACE/pods/$(hostname)"

(The original demo pod name in the last curl was from the kubectl run command, now using $(hostname) which is more reliable from within the pod created by kubectl run).

Note on the Token: The Service Account token is a JSON Web Token (JWT). You can copy it and decode it using online JWT decoders to see its claims, such as the service account name and namespace.

(The original "Try the sidecar thing ..." is too vague and has been omitted. Focus is on direct SA usage.)

3. Using a Custom Service Account with Specific Roles

For better security, create custom Service Accounts with narrowly defined permissions (Roles or ClusterRoles) specific to their tasks.

Create a custom Service Account:

kubectl create serviceaccount tokendemo -n default

Create a Role: This example creates a Role that only allows reading pods in the default namespace.
```
kubectl create role pod-reader --verb=get --verb=list --verb=watch --resource=pods -n default
```

Create a RoleBinding: This binds the pod-reader Role to the tokendemo Service Account in the default namespace.

kubectl create rolebinding my-binding --role=pod-reader --serviceaccount=default:tokendemo --namespace=default

Inspect the Custom SA and its Token (Admin Task - Optional):(Similar to the default SA, inspecting the token secret directly is less relevant for K8s 1.24+ from the pod's perspective, as the token is always mounted.)
```
kubectl get sa tokendemo -n default -o yaml
# If a token secret (e.g., tokendemo-token-xxxxx) is listed (older K8s versions):
# kubectl describe secret tokendemo-token-xxxxx -n default
```

Run a Pod using the Custom Service Account: Create a pod manifest that specifies serviceAccountName: tokendemo.

# Save as mydemo-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: mydemo
  namespace: default # Ensure it's in the same namespace as the SA and RoleBinding
spec:
  serviceAccountName: tokendemo
  containers:
  - name: mydemo-container
    image: xxradar/hackon # Or any image with curl
    command: ["sleep"]
    args: ["infinity"] # Keep the pod running

Apply it:

kubectl apply -f mydemo-pod.yaml

Test API Access from the mydemo Pod: Exec into the mydemo pod:

kubectl exec -it mydemo -n default -- bash

Inside the mydemo pod's shell, run:

# Define variables
KUBE_TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
KUBE_CA="/var/run/secrets/kubernetes.io/serviceaccount/ca.crt"
NAMESPACE=$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace) # Should be 'default'

# This call should succeed because the 'tokendemo' SA has 'pod-reader' Role.
echo "--- Listing pods in namespace $NAMESPACE (should succeed) ---"
curl --cacert $KUBE_CA -H "Authorization: Bearer $KUBE_TOKEN" "https://kubernetes/api/v1/namespaces/$NAMESPACE/pods"

# This call should show details for the 'mydemo' pod itself.
echo "--- Getting details for this pod ($(hostname)) (should succeed) ---"
curl --cacert $KUBE_CA -H "Authorization: Bearer $KUBE_TOKEN" "https://kubernetes/api/v1/namespaces/$NAMESPACE/pods/$(hostname)"

# Attempting to list deployments should fail, as the Role does not grant this permission.
echo "--- Attempting to list deployments in namespace $NAMESPACE (should fail) ---"
curl --cacert $KUBE_CA -H "Authorization: Bearer $KUBE_TOKEN" "https://kubernetes/apis/apps/v1/namespaces/$NAMESPACE/deployments"

Exit the pod's shell when done. Don't forget to clean up the pod and SA if it was just for testing:

# kubectl delete pod mydemo -n default
# kubectl delete rolebinding my-binding -n default
# kubectl delete role pod-reader -n default
# kubectl delete sa tokendemo -n default

Home

Previousapi_access_via_host Nextbpf_labs

Last updated 6 months ago