kubectl --token = $ TOKEN不在令牌的权限下运行 [英] kubectl --token=$TOKEN doesn't run with the permissions of the token

问题描述

当我将命令kubectl与--token标志一起使用并指定令牌时，它仍将使用kubeconfig文件中的管理员凭据.

When I am using the command kubectl with the --token flag and specify a token, it still uses the administrator credentials from the kubeconfig file.

这就是我所做的:

NAMESPACE="default"
SERVICE_ACCOUNT_NAME="sa1"
kubectl create sa $SERVICE_ACCOUNT_NAME
kubectl create clusterrolebinding list-pod-clusterrolebinding \
     --clusterrole=list-pod-clusterrole \
     --serviceaccount="$NAMESPACE":"$SERVICE_ACCOUNT_NAME"
kubectl create clusterrole list-pod-clusterrole \
     --verb=list \
     --resource=pods

TOKEN=`kubectl get secrets $(kubectl get sa $SERVICE_ACCOUNT_NAME -o json | jq -r '.secrets[].name') -o json | jq -r '.data.token' | base64 -d`

# Expected it will fail but it doesn't because it uses the admin credentials
kubectl get secrets --token $TOKEN

令牌具有列出容器的权限，因此我希望kubectl get secrets --token $TOKEN失败，但是不会，因为它仍然使用管理员的上下文.

The token have permissions to list pods, so I expect the kubectl get secrets --token $TOKEN to fail but it doesn't because it still uses the context of the administrator.

我没有创建新的上下文，我知道kubectl具有使用承载令牌的能力，并且想了解如何做到这一点.

I don't create new context, I know kubectl have this ability to use bearer token and want to understand how to do it.

我也尝试了这个kubectl get secrets --insecure-skip-tls-verify --server https://<master_ip>:6443 --token $TOKEN，它也没有返回Forbidden结果.

I also tried this kubectl get secrets --insecure-skip-tls-verify --server https://<master_ip>:6443 --token $TOKENand it also didn't return a Forbidden result.

如果您对其进行测试，则可以使用katacoda:
https://www.katacoda.com/courses/kubernetes/playground

If you test it you can use katacoda:
https://www.katacoda.com/courses/kubernetes/playground

我试图以此创建上下文:

I tried to create context with this:

NAMESPACE="default"
SERVICE_ACCOUNT_NAME="sa1"
CONTEXT_NAME="sa1-context"
USER_NAME="sa1-username"
CLUSTER_NAME="kubernetes"

kubectl create sa "$SERVICE_ACCOUNT_NAME" -n "$NAMESPACE"
SECRET_NAME=`kubectl get serviceaccounts $SERVICE_ACCOUNT_NAME -n $NAMESPACE -o json | jq -r '.secrets[].name'`
TOKEN=`kubectl get secrets $SECRET_NAME -n $NAMESPACE -o json | jq -r '.data | .token' | base64 -d`

# Create user with the JWT token of the service account
echo "[*] Setting credentials for user: $USER_NAME"
kubectl config set-credentials $USER_NAME --token=$TOKEN

# Makue sure the cluster name is correct !!!
echo "[*] Setting context: $CONTEXT_NAME"
kubectl config set-context $CONTEXT_NAME \
--cluster=$CLUSTER_NAME \
--namespace=$NAMESPACE \
--user=$USER_NAME

但是当我尝试kubectl get secrets --context $CONTEXT_NAME时，它仍然成功，并被认为是失败的，因为它对此没有权限.

But when I tried kubectl get secrets --context $CONTEXT_NAME it still succeeded and was supposed fail because it doesn't have permissions for that.

推荐答案

这很棘手，因为如果您使用客户端证书对kubernetes进行身份验证，则使用kubectl覆盖令牌的令牌服务器将无法正常工作，因为使用证书进行身份验证的时间很早TLS握手过程中的过程.即使您在kubectl中提供了令牌，也会被忽略.这就是您能够获取机密的原因，因为客户端证书有权获取机密，并且令牌会被忽略.

This is tricky because if you are using client certificate for authenticating to kubernetes API server overriding token with kubectl is not going to work because the authentication with certificate happens early in the process during the TLS handshake.Even if you provide a token in kubectl it will be ignored.This is the reason why you are able to get secrets because the client certificate have permission to get secrets and the token is ignored.

因此，如果要使用kubectl令牌，则kubeconfig文件不应具有客户端证书，然后可以在Kubectl中使用--token标志覆盖该令牌.请参阅问题中的讨论服务帐户令牌的kubeconfig文件.

So if you want to use kubectl token the kubeconfig file should not have client certificate and then you can override that token with --token flag in Kubectl. See the discussion in the question on how to create a kubeconfig file for a service account token.

您还可以使用命令查看在kubectl命令中发送的承载令牌

Also you can view the bearer token being sent in kubectl command using command

kubectl get pods --v=10 2>&1 | grep -i bearer

这篇关于kubectl --token = $ TOKEN不在令牌的权限下运行的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！