返回介绍

PART Ⅰ : 容器云OPENSHIFT

PART Ⅱ:容器云 KUBERNETES

PART Ⅲ:持续集成与持续部署

PART Ⅴ:日志/监控/告警

PART Ⅵ:基础

PART Ⅶ:数据存储、处理

PART VIII:CODE

PART X:HACKINTOSH

PART XI:安全

用户认证ServiceAccount与授权策略RBAC

发布于 2024-06-08 21:16:47 字数 7602 浏览 0 评论 0 收藏 0

官方文档:https://kubernetes.io/docs/reference/access-authn-authz/rbac/

还是得先从kubernetes集群角色说起

  • ETCD:存储所有k8s资源状态数据
  • API Server:对外暴露操作ETCD等REST API接口

Kubernetes的API Server有众多的资源REST API接口,同时还有众多依赖API Server进行操作的集群组件,例如Controller Manager等。API Server为了保护API请求的合法性。API Serve内部需要先验证请求的权限。需要验证

目前Kubernetes支持的授权策略有:

  • ABAC:基于属性的访问控制
  • RBAC:基于角色的访问控制
  • Webhook
  • Node
  • AlwaysDeny:拒绝所有的请求,一般用于测试。
  • AlwaysAllow:表示允许所有的请求,不进行认证授权。(默认配置)

从1.6版本起,Kubernetes 默认启用RBAC访问控制策略。从1.8开始,RBAC已成为稳定的功能。API Server启用RABC需要设置启动参数–-authorization-mode=RBAC,。

Kubernetes的RBAC认证授权策略使用rbac.authorization.k8s.io API组

Role

ClusterRole

RoleBinding

ClusterRoleBind

1、限制客户端用户只能访问或操作指定命名空间的特定资源

场景用户用户角色限制Namespace限制资源对象语义化的限制动作
开发者developertestpod、configmap只能查看pod/configmap
能登录到pod中进行操作

①创建RBAC相关的资源声明文件

  • ServiceAccount
  • ClusterRole
  • RoleBinding
  • ClusterRoleBinding
#=========================ServiceAccount======================
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: developer
  namespace: default
# 或者使用命令:kubectl -n default create sa developer
#=========================ClusterRole======================
--- 
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: developer
rules:
- apiGroups:
  - ""
  resources:
  - pods
  - pods/attach
  - pods/exec
  - pods/log
  - pods/status
  - configmaps
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - ""
  resources:
  - services
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - ""
  resources:
  - pods/exec
  verbs:
  - create
# Portforward
- apiGroups:
  - ""
  resources:
  - pods
  - pods/portforward
  verbs:
  - get
  - list
  - create

#=========================RoleBinding======================

---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: developer
  namespace: test
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: developer
subjects:
- kind: ServiceAccount
  name: developer
  namespace: default
# 或者使用命令:kubectl create rolebinding developer --clusterrole=developer --serviceaccount=default:developer --namespace=test
#=========================ClusterRoleBinding======================
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: developer
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: developer
subjects:
- kind: ServiceAccount
  name: developer
  namespace: default

②获取serviceaccount的secret

k -n default get secrets 
k -n default get secrets developer-token-** -oyaml

获得如下secrets的详细内容

apiVersion: v1
type: kubernetes.io/service-account-token
kind: Secret
metadata:
  namespace: default
data:
  ca.crt: ******12345678********    # API Server服务端的CA证书
  namespace: ZGVmYXVsdA==                    # 该字符串为“default”base64转码后的值
  token: *******ABCDEF*********     # 该token是经过base64处理的,需要进行解码处理

base64解码secret中的Token

echo "*******ABCDEF*********" | base64 -d

③组装kubeconfig

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: ******12345678********
    server: https://master.k8s117.curiouser.com:8443
  name: k8s117
contexts:
- context:
    cluster: k8s117
    namespace: test
    user: k8s117-developer
  name: k8s117-developer
current-context: k8s117-developer
kind: Config
preferences: {}
users:
- name: k8s117-developer
  user:
    token: "*******ABCDEF*********base64解码后的值"

④测试

  • 看是否能获取所有的命名空间(不能)
  • 看是否能查看test命名空间下的所有POD和ConfigMap(能)
  • 看是否能登录到test命名空间下的POD(能)
  • 看是否能使用kube-proxy端口转发test命名空间下POD的端口(能)

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。
列表为空,暂无数据
    我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
    原文