我正在使用服务帐户令牌卷投影，如此处所述。这是我正在使用的清单文件：
kind: Pod
apiVersion: v1
metadata:
name: pod-acr
spec:
containers:
- image: yorchaksacr.azurecr.io/busybox:1.0
name: busybox
command: ["/bin/sh","-c","sleep 36000"]
volumeMounts:
- mountPath: /var/run/secrets/tokens
name: vault-token
serviceAccountName: pull-acr-images
volumes:
- name: vault-token
projected:
sources:
- serviceAccountToken:
path: vault-token
expirationSeconds: 7200
audience: vault
正如预期的那样，令牌在/var/run/secrets/tokens/vault-token下挂载到容器：
/ # ls -la /var/run/secrets/tokens
total 4
drwxrwxrwt 3 root root 100 Jul 24 21:35 .
drwxr-xr-x 4 root root 4096 Jul 24 21:35 ..
drwxr-xr-x 2 root root 60 Jul 24 21:35 ..2019_07_24_21_35_15.018111081
lrwxrwxrwx 1 root root 31 Jul 24 21:35 ..data -> ..2019_07_24_21_35_15.018111081
lrwxrwxrwx 1 root root 18 Jul 24 21:35 vault-token -> ..data/vault-token
问题是，如果我尝试使用此令牌向 API 服务器进行身份验证，API 会拒绝调用，并显示401 Unauthorized：
/ # wget --header="Authorization: Bearer $(cat /var/run/secrets/tokens/vault-token)" --no-check-certificate https://10.2.1.19:6443
Connecting to 10.2.1.19:6443 (10.2.1.19:6443)
wget: server returned error: HTTP/1.1 401 Unauthorized
但是，如果我使用默认路径和令牌，其中服务帐户令牌投影到所有 Pod/var/run/secrets/kubernetes.io/serviceacconts/token有效：
/ # wget --header="Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" --no-check-certificate https://10.2.1.19:6443
Connecting to 10.2.1.19:6443 (10.2.1.19:6443)
saving to 'index.html'
index.html 100% |************************************************************************************************************************************************************| 2738 0:00:00 ETA
'index.html' saved
如果我cat这两个令牌，我可以看到它们实际上是不同的：
# cat /var/run/secrets/tokens/vault-token
eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJhdWQiOlsidmF1bHQiXSwiZXhwIjoxNTY0MDEzMjcwLCJpYXQiOjE1NjQwMDYwNzAsImlzcyI6Imh0dHBzOi8vMTAuMi4xLjE5Iiwia3ViZXJuZXRlcy5pbyI6eyJuYW1lc3BhY2UiOiJkZWZhdWx0IiwicG9kIjp7Im5hbWUiOiJwb2QtYWNyIiwidWlkIjoiNThiNjI5YWEtZGU4Ni00YTAzLWI3YmQtMTI4ZGFiZWVkYmQ5In0sInNlcnZpY2VhY2NvdW50Ijp7Im5hbWUiOiJwdWxsLWFjci1pbWFnZXMiLCJ1aWQiOiJlZGE0NDlmYS1iODE2LTQ0ZGMtYTFjNi0yMWJhZWUwZmVkN2YifX0sIm5iZiI6MTU2NDAwNjA3MCwic3ViIjoic3lzdGVtOnNlcnZpY2VhY2NvdW50OmRlZmF1bHQ6cHVsbC1hY3ItaW1hZ2VzIn0.UjPaTgWHPwCeeh1ltBb64hv0yEjKkRxKw_BZ3PLDA3HsJK-keXN40Khp-8mNnLQ-uYIfMgW4FXwYIm0SVeQUhM4sh4rwjAYDEfEHDah9AvhEL8I65T_jhnhT10E1M7mzk1x0RFGvjZAECd1RlYM7IuXIkEfZCI_6GRVAbX3Vmk6XF0sRh2T8DZzw8kj_Z54J2gYCt2beBnn7hC9rOC9LW9J0AFEAAQQE_UJME5y4jZD6hfJMSGOouyQm70nVGytqKVsLbzyorH5pugEqrs1Z_dLx6E3Ta9kELRPvyDZgeNiS44fEYlRApn6fZawsppc1oRNoeyMqiIPRdgQekBVfTA/ #
# cat /var/run/secrets/kubernetes.io/serviceaccount/token
eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJkZWZhdWx0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6InB1bGwtYWNyLWltYWdlcy10b2tlbi1oYjU0NyIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50Lm5hbWUiOiJwdWxsLWFjci1pbWFnZXMiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC51aWQiOiJlZGE0NDlmYS1iODE2LTQ0ZGMtYTFjNi0yMWJhZWUwZmVkN2YiLCJzdWIiOiJzeXN0ZW06c2VydmljZWFjY291bnQ6ZGVmYXVsdDpwdWxsLWFjci1pbWFnZXMifQ.nqqhZVmBUuKVi6E3L9MEn8oW1dKd-DV4c9jcVy5mXAuEMZ1WgLlaaHFF1ibnVMjEK6VUJyJhp7w08hgSmyyh-KY4BQ5oJf1jmSySvmttJxjXW-KsMpf5rHF0ZDmgaqZwbi7FvowtoTECstFBVNoszKJUn1iV5mU_6MQkEtGTNyE4KuZ9LEvPuZxiNZ5UyW3UaHXLqF63-w_xlkfa_75E-cgXqvSSGTCb6RsTuOmVyCqganx5SpIb5EU-3Mu7hUWEhSRAh3tpcPIwjS7-NkuO0ReH7Z40rPHqkIokshUUO75WM_oPq7tlu6PSCTwOK-Jw66kzi-jqKNyKvMeWJUq4WQ/ #
有人知道为什么我会看到这种行为吗？我希望这两个令牌都可以工作，但显然看起来并非如此。
API 服务器的配置：
spec:
containers:
- command:
- kube-apiserver
- --advertise-address=10.2.1.19
- --allow-privileged=true
- --authorization-mode=Node,RBAC
- --client-ca-file=/etc/kubernetes/pki/ca.crt
- --enable-admission-plugins=NodeRestriction
- --enable-bootstrap-token-auth=true
- --etcd-cafile=/etc/kubernetes/pki/etcd/ca.crt
- --etcd-certfile=/etc/kubernetes/pki/apiserver-etcd-client.crt
- --etcd-keyfile=/etc/kubernetes/pki/apiserver-etcd-client.key
- --etcd-servers=https://127.0.0.1:2379
- --insecure-port=0
- --kubelet-client-certificate=/etc/kubernetes/pki/apiserver-kubelet-client.crt
- --kubelet-client-key=/etc/kubernetes/pki/apiserver-kubelet-client.key
- --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname
- --proxy-client-cert-file=/etc/kubernetes/pki/front-proxy-client.crt
- --proxy-client-key-file=/etc/kubernetes/pki/front-proxy-client.key
- --requestheader-allowed-names=front-proxy-client
- --requestheader-client-ca-file=/etc/kubernetes/pki/front-proxy-ca.crt
- --requestheader-extra-headers-prefix=X-Remote-Extra-
- --requestheader-group-headers=X-Remote-Group
- --requestheader-username-headers=X-Remote-User
- --secure-port=6443
- --service-account-key-file=/etc/kubernetes/pki/sa.pub
- --service-cluster-ip-range=10.96.0.0/12
- --tls-cert-file=/etc/kubernetes/pki/apiserver.crt
- --tls-private-key-file=/etc/kubernetes/pki/apiserver.key
- --basic-auth-file=/etc/kubernetes/pki/passwordfile
- --service-account-issuer=https://10.2.1.19
- --service-account-signing-key-file=/etc/kubernetes/pki/sa.key
image: k8s.gcr.io/kube-apiserver:v1.15.1
imagePullPolicy: IfNotPresent
令人困惑的是，401 未授权表示身份验证问题而不是授权问题(请参阅此处)。这意味着 Kubernetes 服务帐户令牌身份验证器不喜欢/var/run/secrets/tokens/vault-token令牌(我们称之为vault-token)。 这两种令牌在几个方面有所不同。这是解码vault-token：
{
"aud": [
"vault"
],
"exp": 1564013270,
"iat": 1564006070,
"iss": "https://10.2.1.19",
"kubernetes.io": {
"namespace": "default",
"pod": {
"name": "pod-acr",
"uid": "58b629aa-de86-4a03-b7bd-128dabeedbd9"
},
"serviceaccount": {
"name": "pull-acr-images",
"uid": "eda449fa-b816-44dc-a1c6-21baee0fed7f"
}
},
"nbf": 1564006070,
"sub": "system:serviceaccount:default:pull-acr-images"
}
请注意受众 (["vault"])、发行者 ("https://10.2.1.19") 和主题 ("system:serviceaccount:default:pull-acr-images")。
以下是default-path-token：
{
"iss": "kubernetes/serviceaccount",
"kubernetes.io/serviceaccount/namespace": "default",
"kubernetes.io/serviceaccount/secret.name": "pull-acr-images-token-hb547",
"kubernetes.io/serviceaccount/service-account.name": "pull-acr-images",
"kubernetes.io/serviceaccount/service-account.uid": "eda449fa-b816-44dc-a1c6-21baee0fed7f",
"sub": "system:serviceaccount:default:pull-acr-images"
}
相同的主题，但不同的发行人("kubernetes/serviceaccount")和没有受众。
我不确定为什么default-path-token具有不同的颁发者，或者为什么它正确进行身份验证，但您的vault-token未正确进行身份验证，因为受众与颁发者不匹配。
更具体地说，线索在您在此处链接的文档中。它说此功能正常工作取决于您如何为kube-apiserver设置以下标志：
--service-account-issuer--service-account-signing-key-file--service-account-api-audiences
不确定这些文档是错误的还是过时的，但由于您使用的是v1.15.1现在调用了标志：
--service-account-issuer--service-account-signing-key-file string--api-audiences
标志文档说--api-audiences标志：
API 的标识符。服务帐户令牌身份验证器将验证用于 API 的令牌是否绑定到其中至少一个受众。如果配置了 --service-account-issuer 标志而未配置此标志，则此字段默认为包含颁发者 URL 的单个元素列表。
由于您没有设置此标志并且您有--service-account-issuer=https://10.2.1.19，并且您的 pod 规范中有audience: vault，因此您的令牌将声明其绑定到vault受众，令牌身份验证器将尝试将其与--service-account-issuer标志的值匹配，显然这些不匹配。
您可以通过在 Pod 规范中指定audience: https://10.2.1.19而不是audience: vault来匹配这些匹配。一个警告：这个解决方案在技术上可以确保令牌进行身份验证，但我不确定真正的正确答案是什么，因为在 pod 规范中使用这些标志和字段，因为它们是真正想要的，只是让这些字符串匹配可能有点黑客。