api_access_via_host

Home

Accessing the Kubernetes API from the Host

This guide demonstrates various methods to interact directly with the Kubernetes API server using curl from a host machine (e.g., your local machine, or a node in the cluster if run locally there). This can be useful for scripting, debugging, or understanding API mechanics.

1. Unauthenticated Access (Health Checks)

Some API endpoints, like health checks, might be accessible without authentication, depending on the API server configuration.

# Replace 10.1.2.217:6443 with your actual Kubernetes API server address and port.
# These examples use -k to ignore TLS certificate verification, common for self-signed certs in dev environments.
curl -kv 'https://10.1.2.217:6443/readyz?verbose'
curl -kv 'https://10.1.2.217:6443/livez?verbose'

2. Authenticated Access using Kubeconfig Details

Your ~/.kube/config file (or any specified kubeconfig file) contains the necessary credentials to authenticate to the API server. We can extract these details to use with curl.

Note: The following commands assume you have a kubeconfig file named config in your current directory. You might need to copy your actual kubeconfig file (e.g., from ~/.kube/config) to the current directory and name it config, or adjust the filename in the commands. For parsing YAML/JSON robustly, tools like yq or jq are recommended over grep/sed, but these examples use basic shell tools.

2.1 Extracting Details from a YAML Kubeconfig

These commands extract the server URL, CA certificate, client certificate, client key, and potentially a token from a YAML-formatted kubeconfig file.

# Extract server endpoint
grep 'server: ' config | sed 's/^.*server: //' > server.txt

# Extract CA certificate
grep 'certificate-authority-data: ' config | sed 's/^.*certificate-authority-data: //' | base64 -d > ca.pem

# Extract client certificate
grep 'client-certificate-data: ' config | sed 's/^.*client-certificate-data: //' | base64 -d > cert.pem

# Extract client key
grep 'client-key-data: ' config | sed 's/^.*client-key-data: //' | base64 -d > key.pem

# Extract token (if present and used by the context)
grep 'token: ' config | sed 's/^.*token: //' > token.txt
# Note: A kubeconfig might use either client certs/key OR a token, not always both.

2.2 Accessing API using Client Certificates

Use the extracted certificate, key, and CA to make an authenticated API call.(Note: Ensure file paths like ./ca.pem are correct relative to where you run curl.)

curl --cacert ./ca.pem --key ./key.pem --cert ./cert.pem "$(cat server.txt)/api/v1"

2.3 Accessing API using a Bearer Token

If your kubeconfig context uses a bearer token for authentication:

# Ensure token.txt was populated correctly from your kubeconfig
curl --cacert ./ca.pem -H "Authorization: Bearer $(cat token.txt)" "$(cat server.txt)/api/v1"

2.4 Note on JSON Kubeconfig (Brief Example)

If your kubeconfig were in JSON format (less common by default), you might use jq to extract data. For example, to get the CA data from a config.json:

# cat config.json | jq -r '.clusters[0].cluster."certificate-authority-data"' | base64 -d > ca.pem

(The original document only showed cat ... | jq ... without base64 decoding or output redirection, so this is an expanded example.)

3. Authenticated Access using Service Account Tokens

Service Accounts in Kubernetes use tokens for authentication. You can use these tokens to make API calls.

Important Note on Service Account Tokens (Kubernetes 1.24+):

• Starting with Kubernetes 1.24, Secrets containing service account tokens are no longer automatically generated for every service account.

• The older method of finding a secret named like service-account-name-token-xxxxx and extracting the token from it is deprecated.

• The recommended way to get a service account token is using the kubectl create token SA_NAME command (e.g., kubectl create token default -n my-namespace).

• The examples below use the older method for illustration as per the original document but will require adaptation or will not work as written on K8s 1.24+ without manually creating such a secret or using kubectl create token.

3.1 Using the Default Service Account Token

1. Get the token for the default service account:(This method is for K8s < 1.24 or if token secrets are explicitly created.) First, find the name of the secret associated with the default service account (adjust namespace if not default):

   # This command attempts to find an auto-generated secret name.
   # On K8s 1.24+, this secret might not exist by default.
   DEFAULT_SA_SECRET_NAME=$(kubectl get sa default -n default -o jsonpath='{.secrets[0].name}')
   
   if [ -z "$DEFAULT_SA_SECRET_NAME" ]; then
     echo "No secret found for default SA automatically. For K8s 1.24+, use 'kubectl create token default -n default'."
   else
     echo "Found secret name: $DEFAULT_SA_SECRET_NAME"
     # Extract the token from this secret
     kubectl get secret "$DEFAULT_SA_SECRET_NAME" -n default -o jsonpath='{.data.token}' | base64 -d > default_token.txt
     echo "Token extracted to default_token.txt"
   fi

   If using K8s 1.24+, use this instead:

   # kubectl create token default -n default > default_token.txt

2. Make an API call using the token:(Assuming server.txt and ca.pem were extracted from a kubeconfig as shown in section 2.1)

   # Ensure default_token.txt contains a valid token
   curl -kv --cacert ./ca.pem -H "Authorization: Bearer $(cat default_token.txt)" "$(cat server.txt)/apis/"

3.2 Using a Custom Service Account with ClusterRole Privileges

1. Create a Service Account:

   kubectl create serviceaccount demo -n default

2. Define a ClusterRole: Create clusterrole.yaml with the following content:

   cat > clusterrole.yaml <<EOF
   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:
     name: demo-reader-role
   rules:
   - apiGroups: ["*"]
     resources: ["*"]
     verbs: ["get", "watch", "list"]
   EOF

   Then apply it:

   kubectl create -f clusterrole.yaml

3. Define a ClusterRoleBinding: Create clusterrolebinding.yaml with the following content:

   cat > clusterrolebinding.yaml <<EOF
   kind: ClusterRoleBinding
   apiVersion: rbac.authorization.k8s.io/v1
   metadata:
     name: demo-reader-binding
   subjects:
   - kind: ServiceAccount
     name: demo
     namespace: default # ServiceAccount is in the 'default' namespace
   roleRef:
     kind: ClusterRole
     name: demo-reader-role
     apiGroup: rbac.authorization.k8s.io
   EOF

   Then apply it:

   kubectl create -f clusterrolebinding.yaml

4. Get the token for the demo service account:(This method is for K8s < 1.24 or if token secrets are explicitly created after SA creation.) First, find the name of a secret associated with the demo service account. This might take a moment to appear after SA creation or might require manual secret creation and linking in some setups.

   # This command attempts to find an auto-generated secret name.
   # On K8s 1.24+, this secret might not exist by default.
   DEMO_SA_SECRET_NAME=$(kubectl get sa demo -n default -o jsonpath='{.secrets[0].name}')
   
   if [ -z "$DEMO_SA_SECRET_NAME" ]; then
     echo "No secret found for demo SA automatically. For K8s 1.24+, use 'kubectl create token demo -n default'."
   else
     echo "Found secret name: $DEMO_SA_SECRET_NAME"
     # Extract the token from this secret
     kubectl get secret "$DEMO_SA_SECRET_NAME" -n default -o jsonpath='{.data.token}' | base64 -d > mydemotoken.txt
     echo "Token extracted to mydemotoken.txt"
   fi

   If using K8s 1.24+, use this instead:

   # kubectl create token demo -n default > mydemotoken.txt

5. Make an API call using the demo SA token:(Assuming server.txt and ca.pem were extracted earlier)

   # Ensure mydemotoken.txt contains a valid token
   curl -kv --cacert ./ca.pem -H "Authorization: Bearer $(cat mydemotoken.txt)" "$(cat server.txt)/api/v1/namespaces/default/pods/"

Home