北海涠洲岛旅游网站建设分析,jsp网站开发公司,360怎么做网站搜索,标书制作教程Kubernetes RBAC授权
Kubernetes 安全框架 K8S安全控制框架主要由下面3个阶段进行控制#xff0c;每一个阶段都支持插件方式#xff0c;通过API Server配置来启用插件。1. Authentication#xff08;鉴权#xff09; K8s Apiserver提供三种客户端身份认证#xff1a;• H…
Kubernetes RBAC授权
Kubernetes 安全框架 K8S安全控制框架主要由下面3个阶段进行控制每一个阶段都支持插件方式通过API Server配置来启用插件。1. Authentication鉴权 K8s Apiserver提供三种客户端身份认证 • HTTPS 证书认证基于CA证书签名的数字证书认证kubeconfig • HTTP Token认证通过一个Token来识别用户serviceaccount • HTTP Base认证用户名密码的方式认证1.19版本弃用 2. Authorization授权 RBACRole-Based Access Control基于角色的访问控制负责完成授权Authorization工作。 RBAC根据API请求属性决定允许还是拒绝。 比较常见的授权维度 • user用户名 • group用户分组 • 资源例如pod、 deployment • 资源操作方法 get list create update patch watch delete • 命名空间 • API组 3. Admission Control准入控制 Adminssion Control实际上是一个准入控制器插件列表 发送到API Server的请求都需要经过这个列表中的每个准入控 制器插件的检查 检查不通过 则拒绝请求。 启用一个准入控制器 kube-apiserver --enable-admission-pluginsNamespaceLifecycle,LimitRanger ... 关闭一个准入控制器 kube-apiserver --disable-admission-pluginsPodNodeSelector,AlwaysDeny ... 查看默认启用 kubectl exec kube-apiserver-k8s-master -n kube-system -- kube-apiserver -h | grep enable-admission-plugins 基于角色的权限访问控制 RBAC
RBACRole-Based Access Control基于角色的访问控制是K8s默认授权策略并且是动态配置策略修改即时生效。主体subject• User用户 • Group用户组 • ServiceAccount服务账号 角色• Role授权特定命名空间的访问权限 • ClusterRole授权所有命名空间的访问权限 角色绑定• RoleBinding将角色绑定到主体即subject • ClusterRoleBinding将集群角色绑定到主体 注 RoleBinding在指定命名空间中执行授权 ClusterRoleBinding在集群范围执行授权。RBAC授权案例
为指定用户授权访问不同命名空间权限例如新入职一个小弟希望让他先熟悉K8s集群为了安全性先不能给他太大权限因此先给他授权访问default命名空间Pod读取权限。实施大致步骤1. 用K8S CA签发客户端证书 2. 生成kubeconfig授权文件 3. 创建RBAC权限策略 4. 指定kubeconfig文件测试权限 kubectl get pods --kubeconfig./aliang.kubeconfig 为指定用户授权访问不同命名空间权限生成kubeconfig授权文件# 设置集群 kubectl config set-cluster kubernetes \
--certificate-authority/etc/kubernetes/pki/ca.crt \
--embed-certstrue \
--serverhttps://192.168.31.61:6443 \ #masterIP
--kubeconfigaliang.kubeconfig # 设置客户端认证 kubectl config set-credentials aliang \
--client-keyaliang-key.pem \
--client-certificatealiang.pem \
--embed-certstrue \
--kubeconfigaliang.kubeconfig # 设置默认上下文 kubectl config set-context kubernetes \
--clusterkubernetes \
--useraliang \
--kubeconfigaliang.kubeconfig # 设置当前使用配置 kubectl config use-context kubernetes --kubeconfigaliang.kubeconfig 创建角色权限集合apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: default
name: pod-reader
rules:
- apiGroups: [“” ] # api组例如apps组空值表示是核心API组像namespace、 pod、 service、 pv、 pvc都在里面
resources: [“pods” ] #资源名称复数例如pods、 deployments、 services
verbs: [“get” , “watch” , “list” ] # 资源操作方法 将用户与角色绑定apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: read-pods
namespace: default
subjects:
- kind: User # 主体
name: jane # 主体名称
apiGroup: rbac.authorization.k8s.io
roleRef: # 绑定的角色
kind: Role
name: pod-reader # 角色名称
apiGroup: rbac.authorization.k8s.io 认证流程ServiceAccount服务账号简称SA用于让集群内Pod访问k8s Api。授权方式与kubeconfig方式一样。示例为一个服务账号分配只能创建deployment、 daemonset、statefulset的权限# 创建服务账号 kubectl create serviceaccount cicd-token -n app-team1 # 创建集群角色 kubectl create clusterrole deployment-clusterrole \
--verbcreate --resourcedeployments,daemonsets,statefulsets # 将服务账号绑定角色 kubectl create rolebinding cicd-token \
--serviceaccountapp-team1:cicd-token \
--clusterroledeployment-clusterrole -n app-team1 # 测试服务账号权限 kubectl --assystem:serviceaccount:app-team1:cicd-token \
get pods -n app-team1 以上命令对应yaml文件apiVersion: v1
kind: ServiceAccount
metadata:name: cicd-tokennamespace: app-team1
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:name: deployment-clusterrole
rules:
- apiGroups: [apps]resources: [deployments,daemonsets,statefulsets]verbs: [create]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:name: cicd-tokennamespace: app-team1
roleRef:apiGroup: rbac.authorization.k8s.iokind: ClusterRolename: deployment-clusterrole
subjects:
- kind: ServiceAccountname: cicd-tokennamespace: app-team1 网络访问控制
网络访问控制应用场景
默认情况下 Kubernetes 集群网络没任何网络限制 Pod 可以与任何其他 Pod 通信在某些场景下就需要进行网络控制减少网络攻击面提高安全性这就会用到网络策略。网络策略Network Policy是一个K8s资源用于限制Pod出入流量提供Pod级别和Namespace级别网络访问控制。网络策略的应用场景偏重多租户下
• 应用程序间的访问控制例如项目A不能访问项目B的Pod• 开发环境命名空间不能访问测试环境命名空间Pod• 当Pod暴露到外部时需要做Pod白名单网络策略概述 podSelector目标Pod根据标签选择。
policyTypes策略类型指定策略用于入站、出站流量。
Ingress from是可以访问的白名单可以来自于IP段、命名空间、 Pod标签等 ports是可以访问的端口。
Egress这个Pod组可以访问外部的IP段和端口 网络策略工作流程
1、创建Network Policy资源2、 Policy Controller监控网络策略同步并通知节点上程序3、节点上DaemonSet运行的程序从etcd中获取Policy调用本地Iptables创建防火墙规则网络访问控制3个案例 案例1拒绝其他命名空间Pod访问需求 test命名空间下所有pod可以互相访问也可以访问其他命名空间Pod但其他命名空间不能访问test命名空间Pod。测试kubectl run busybox --imagebusybox -n test -- sleep 12h
kubectl run web --imagenginx -n test # 可以访问 kubectl exec busybox -n test -- ping 同命名空间pod IP # 不能访问在default命名空间测试访问test命名空间pod web kubectl exec busybox -- ping test命名空间pod IP 对应的yaml案例2同一个命名空间下应用之间限制访问需求将test命名空间携带runweb标签的Pod隔离只允许携带runclient1标签的Pod访问80端口。测试kubectl run web --imagenginx -n test
kubectl run client1 --imagebusybox -n test -- sleep 12h # 可以访问 kubectl exec client1 -n test -- wget test命名空间pod IP # 不能访问 kubectl exec busybox -- wget test命名空间pod IP 对应yaml文件案例3只允许指定命名空间中的应用访问需求 只允许dev命名空间中的Pod访问prod命名空间中的pod 80端口命名空间打标签kubectl label namespace dev namedev 测试kubectl run busybox --imagebusybox -n dev -- sleep 12h # 可以访问 kubectl exec busybox -n dev -- wget test命名空间pod IP # 不可以访问 kubectl exec busybox -- wget test命名空间pod IP 对应yaml文件
