背景

目标生成一个仅能操作名为demo的namespace的kubeconfig文件，仅给业务用户最小的所需权限。

rbac资源准备

创建ServiceAccount

cat<< EOF | kubectl apply -f -
apiVersion: v1
kind: ServiceAccount
metadata:
  name: demo-account
  namespace: demo
EOF

Secret

在 K8s 1.24 版本之后，ServiceAccount 对应的 Secret 就不会自动创建了

# kubectl -n demo get secret
No resources found in demo namespace.

需要我们自己手动创建一下。之前的k8s自动会创建。

cat<< EOF | kubectl apply -f -
apiVersion: v1
kind: Secret
metadata:
  name: demo-account-secret
  namespace: demo
  annotations:
    kubernetes.io/service-account.name: "demo-account"
type: kubernetes.io/service-account-token
EOF

这个 Secret 创建出来之后，K8s 会自动将 ServiceAccount 对应的 token 写进这个 Secret

image-20240620103846206

可以看到token信息了。

后面创建kubeconfig文件时会用到这个token。

创建Role

cat<< EOF | kubectl apply -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: demo-role
  namespace: demo
rules:
- apiGroups: [""]
  resources: ["services", "configmaps", "secrets", "pods"]
  verbs: ["get", "list", "watch", "create", "delete", "update", "patch"]
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["get", "list", "watch", "create", "delete", "update", "patch"]
EOF

对常用资源的操作权限

RoleBinding

cat<< EOF | kubectl apply -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: demo-rolebinding
  namespace: demo
subjects:
- kind: ServiceAccount
  name: demo-account
  namespace: demo
roleRef:
  kind: Role
  name: demo-role
  apiGroup: rbac.authorization.k8s.io
EOF

创建kubeconfig文件

关于kubeconfig文件的介绍之前写过

TODO

我们可以先复制一下集群默认的kubeconfig文件

kubectl config view --flatten --minify > cluster-cert.txt

  • kubectl config view: 这个命令用于显示合并的kubeconfig设置。kubeconfig文件包含了Kubernetes集群的配置信息，包括集群、用户和上下文的信息。

  • --flatten: 这个选项用于将配置信息扁平化，这意味着它会将多层嵌套的配置合并成一个连续的、没有嵌套的文本流。这对于将配置导出到文件中非常有用。

  • --minify: 这个选项用于移除所有非必需的字段，只保留最基本的配置信息。这有助于减少输出的大小，并使配置更加简洁。

  • > cluster-cert.txt: 这部分是重定向操作符，它将kubectl config view命令的输出重定向到一个名为cluster-cert.txt的文件中。如果该文件已存在，它将被覆盖；如果文件不存在，它将被创建。

综合起来，这个命令的作用是：使用kubectl工具查看当前的kubeconfig配置，通过--flatten和--minify选项简化输出，然后将这些简化的配置信息保存到一个名为cluster-cert.txt的文本文件中。这个文件通常包含了访问Kubernetes集群所需的证书和密钥信息，可以用于其他脚本或工具中，以便自动化或简化集群操作。

改一下其中的users部分

把 secret 中的 token 拿下来放到新的 cluster-cert.txt 中

kubectl -n demo describe secrets demo-account-secret

填到下面user部分

apiVersion: v1
kind: Config

clusters:
- cluster:
    certificate-authority-data: # 都一样，不用改
    server: # 都一样，不用改
  name: demo-cluster # 可以改一下，和业务相关命名


users:
- name: demo # 你的用户名
  user:
    token: # 上边拿到的的token
    
contexts:
- context:
    cluster: demo-cluster # 和上面改的名要一致
    namespace: demo # 你的ns
    user: demo # 和上面改的名要一致
  name: demo-context # 可以改一下，和业务相关命名

current-context: demo-context # 和contexts下的name保持一致
preferences: {}

注意：或者其他地方都不修改，直接替换user下的token也可以。

之前我会手动将config文件进行合并，

现在发现了一个很简单的办法。根本不需要自己动手，被自己之前的操作蠢哭了。。。

合并kubeconfig文件

export KUBECONFIG=/root/.kube/config:/root/.kube/cluster-cert.txt

之后kubectl config view 可以看到合并后的kubeconfig文件

kubectl config view
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: DATA+OMITTED
    server: https://lb.kubesphere.local:6443
  name: cluster.local
- cluster:
    certificate-authority-data: DATA+OMITTED
    server: https://127.0.0.1:26443
  name: orbstack
contexts:
- context:
    cluster: cluster.local
    user: kubernetes-admin
  name: kubernetes-admin@cluster.local
- context:
    cluster: orbstack
    user: orbstack
  name: orbstack
current-context: orbstack
kind: Config
preferences: {}
users:
- name: kubernetes-admin
  user:
    client-certificate-data: DATA+OMITTED
    client-key-data: DATA+OMITTED
- name: orbstack
  user:
    client-certificate-data: DATA+OMITTED
    client-key-data: DATA+OMITTED

测试一下

kubectl --kubeconfig cluster-cert.txt -n demo get pods

image-20240625102545656