![Rancher RKE2 Cert-manager 的 Vault 发行者显示“权限被拒绝”](https://linux22.com/image/792057/Rancher%20RKE2%20Cert-manager%20%E7%9A%84%20Vault%20%E5%8F%91%E8%A1%8C%E8%80%85%E6%98%BE%E7%A4%BA%E2%80%9C%E6%9D%83%E9%99%90%E8%A2%AB%E6%8B%92%E7%BB%9D%E2%80%9D.png)
有人知道 Rancher RKE2 集群出了什么问题吗?我在部署带有 Vault 发行者的 Cert-manager 时遇到了一些奇怪的问题,Vault 被“拒绝访问”(或更确切地说是kubectl describe clusterissuers vault-issuer
显示Error initializing issuer: while requesting a Vault token using the Kubernetes auth: error calling Vault server: Error making API request.; URL: POST https://vault.services.xxx.net/v1/auth/kubernetes/login Code: 403. Errors: * permission denied
),尽管它在 Rancher 的本地集群中运行良好(它是在 3 个节点上部署了“rke up”的 RKE1)。
如果不对此进行过多阐述,这会使事情变得过于复杂,我更愿意关注一些与 IMO 相关的线索……
- 尽管安装了正确的 RBAC 规则,Kubernetes 仍然拒绝“kubectl auth can-i”测试,如下所示:
» kubectl auth can-i create tokenreviews --as=system:serviceaccount:default:vault-issuer
来自服务器的错误(禁止):{"Code":{"Code":"Forbidden","Status":403},"Message":"clusters.management.cattle.io "cm-4jbln242" 被禁止:用户 "system:serviceaccount:default:vault-issuer" 无法在集群范围内获取 API 组 "management.cattle.io" 中的资源 "clusters"","Cause":null,"FieldName":""} (post selfsubjectaccessreviews.authorization.k8s.io)
即使我允许列出这样的集群:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: cattle-mgmt-get-clusters
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: list-clusters
# no luck even if referencing cluster-admin clusterrole
#kind: ClusterRole
#name: cluster-admin
subjects:
- kind: ServiceAccount
name: vault-issuer
namespace: default
...它不起作用。
- 我发现使用原始命令时我的 vault-issuer SA 据称不存在(这不是真的):
Error from server (NotFound): service accounts "vault-issuer" not found
# but sure, it exists when getting it in a normal way...
» kubectl get sa -n default vault-issuer
NAME SECRETS AGE
vault-issuer 0 6h31m
保险库发行者 SA 的创建方式如下:
apiVersion: v1
kind: ServiceAccount
metadata:
name: vault-issuer
namespace: default
Rancher版本:v2.7.9 RKE2集群版本:v1.26.11+rke2r1
我的集群的配置非常标准......CoreDNS,Calico,Nginx Ingress控制器......这是它的yaml配置:
kind: Cluster
metadata:
name: infra-cloud
annotations:
field.cattle.io/creatorId: user-7ts7q
field.cattle.io/description: Common Infra Cloud
creationTimestamp: '2024-01-05T12:48:38Z'
finalizers:
- wrangler.cattle.io/provisioning-cluster-remove
- wrangler.cattle.io/rke-cluster-remove
- wrangler.cattle.io/cloud-config-secret-remover
generation: 2
labels:
{}
namespace: fleet-default
resourceVersion: '84718360'
uid: c8f76d68-9bc7-4608-81fa-81fe06c960ca
fields:
- infra-cloud
- 'true'
- infra-cloud-kubeconfig
spec:
clusterAgentDeploymentCustomization:
appendTolerations:
overrideAffinity:
overrideResourceRequirements:
defaultPodSecurityAdmissionConfigurationTemplateName: ''
defaultPodSecurityPolicyTemplateName: ''
fleetAgentDeploymentCustomization:
appendTolerations:
overrideAffinity:
overrideResourceRequirements:
kubernetesVersion: v1.26.11+rke2r1
localClusterAuthEndpoint:
caCerts: ''
enabled: false
fqdn: ''
rkeConfig:
chartValues:
rke2-calico: {}
etcd:
disableSnapshots: false
snapshotRetention: 5
snapshotScheduleCron: 0 */5 * * *
machineGlobalConfig:
cni: calico
disable-kube-proxy: false
etcd-expose-metrics: false
machinePoolDefaults:
machinePools:
machineSelectorConfig:
- config:
protect-kernel-defaults: false
registries:
configs:
{}
mirrors:
{}
upgradeStrategy:
controlPlaneConcurrency: '1'
controlPlaneDrainOptions:
deleteEmptyDirData: true
disableEviction: false
enabled: false
force: false
gracePeriod: -1
ignoreDaemonSets: true
skipWaitForDeleteTimeoutSeconds: 0
timeout: 120
workerConcurrency: '1'
workerDrainOptions:
deleteEmptyDirData: true
disableEviction: false
enabled: false
force: false
gracePeriod: -1
ignoreDaemonSets: true
skipWaitForDeleteTimeoutSeconds: 0
timeout: 120
machineSelectorConfig:
- config: {}
__clone: true
此外,当我在另一个(较旧的)RKE2 集群(由另一个 Rancher 创建)中尝试 (1) 和 (2) 时,它的行为也相同。当我在本地 KIND 集群上测试它时,它按预期工作。
我遗漏了什么?一些 RBAC,或者是任何 Rancher 的强化(顺便说一句,我没有使用 CIS 配置文件)。提前谢谢您!
更新:我发现我可以在 Rancher 集群的配置下启用授权集群端点(Rancher UI:配置 -> 网络 -> 授权端点),然后原始命令按预期工作,并且现在测试vault write auth/kubernetes/login role=vault-issuer jwt="<your_token>"
不会返回“权限被拒绝”,因此看起来罪魁祸首是 Rancher 的身份验证代理及其模拟功能。但出于某种原因,cert-manager 的 vault-issuer 仍然返回“权限被拒绝”。不幸的是,对我来说使用 ACE 不是一个好的解决方案,所以我不打算再深入研究,但它可能是其他原因,例如 JWT 令牌中的一些错误参数……无论如何,其他人知道是否可以使用 Rancher 端点(身份验证代理)解决这个问题吗?
UPDATE2:基本上这是一个已知问题:https://github.com/rancher/rancher/issues/22417(整体&开放) +https://github.com/rancher/rancher/issues/16221+https://github.com/rancher/rancher/issues/17447+https://github.com/rancher/rancher/issues/14997
不开心...ACE对我们来说并不好,所以我们会继续寻找其他解决方案,或者我们会暂时使用AppRole auth。