Add jsonpath approach for apiserver query (#12350)
* Add `jsonpath` approach for apiserver query * Refine the wording with the approach description * Refine the command log * Move the itemized number back
This commit is contained in:
committed by
Kubernetes Prow Robot
parent
e30a39af27
commit
ca4f474235
@@ -78,9 +78,35 @@ $ curl http://localhost:8080/api/
|
||||
|
||||
Use `kubectl describe secret...` to get the token for the default service account:
|
||||
|
||||
Use `kubectl describe secret` with grep/cut:
|
||||
|
||||
```shell
|
||||
$ APISERVER=$(kubectl config view --minify | grep server | cut -f 2- -d ":" | tr -d " ")
|
||||
$ TOKEN=$(kubectl describe secret $(kubectl get secrets | grep "^default" | cut -f1 -d ' ') | grep -E '^token' | cut -f2 -d':' | tr -d " ")
|
||||
$ SECRET_NAME=$(kubectl get secrets | grep ^default | cut -f1 -d ' ')
|
||||
$ TOKEN=$(kubectl describe secret $SECRET_NAME | grep -E '^token' | cut -f2 -d':' | tr -d " ")
|
||||
|
||||
$ curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
|
||||
{
|
||||
"kind": "APIVersions",
|
||||
"versions": [
|
||||
"v1"
|
||||
],
|
||||
"serverAddressByClientCIDRs": [
|
||||
{
|
||||
"clientCIDR": "0.0.0.0/0",
|
||||
"serverAddress": "10.0.1.149:443"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
Using `jsonpath`:
|
||||
|
||||
```shell
|
||||
$ APISERVER=$(kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}')
|
||||
$ SECRET_NAME=$(kubectl get serviceaccount default -o jsonpath='{.secrets[0].name}')
|
||||
$ TOKEN=$(kubectl get secret $SECRET_NAME -o jsonpath='{.data.token}' | base64 --decode)
|
||||
|
||||
$ curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
|
||||
{
|
||||
"kind": "APIVersions",
|
||||
|
||||
@@ -85,6 +85,8 @@ The output is similar to this:
|
||||
It is possible to avoid using kubectl proxy by passing an authentication token
|
||||
directly to the API server, like this:
|
||||
|
||||
Using `grep/cut` approach:
|
||||
|
||||
``` shell
|
||||
# Check all possible clusters, as you .KUBECONFIG may have multiple contexts
|
||||
kubectl config view -o jsonpath='{range .clusters[*]}{.name}{"\t"}{.cluster.server}{"\n"}{end}'
|
||||
@@ -116,6 +118,26 @@ The output is similar to this:
|
||||
}
|
||||
```
|
||||
|
||||
Using `jsonpath` approach:
|
||||
|
||||
```
|
||||
$ APISERVER=$(kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}')
|
||||
$ TOKEN=$(kubectl get secret $(kubectl get serviceaccount default -o jsonpath='{.secrets[0].name}') -o jsonpath='{.data.token}' | base64 --decode )
|
||||
$ curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
|
||||
{
|
||||
"kind": "APIVersions",
|
||||
"versions": [
|
||||
"v1"
|
||||
],
|
||||
"serverAddressByClientCIDRs": [
|
||||
{
|
||||
"clientCIDR": "0.0.0.0/0",
|
||||
"serverAddress": "10.0.1.149:443"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
The above example uses the `--insecure` flag. This leaves it subject to MITM
|
||||
attacks. When kubectl accesses the cluster it uses a stored root certificate
|
||||
and client certificates to access the server. (These are installed in the
|
||||
|
||||
Reference in New Issue
Block a user