kubernetes API服务器的安全防护

本文涉及的产品
容器服务 Serverless 版 ACK Serverless,952元额度 多规格
容器服务 Serverless 版 ACK Serverless,317元额度 多规格
简介: 12.1.了解认证机制  启动API服务器时,通过命令行选项可以开启认证插件。12.1.1.用户和组了解用户:  分为两种连接到api服务器的客户端:  1.真实的人  2.pod,使用一种称为ServiceAccount的机制了解组:  认证插件会连同用户名,和用户id返回组,组可以一次性给用户服务多个权限,不用单次赋予,  system:unauthenticated组:用于所有认证插件都不会认证客户端身份的请求。

12.1.了解认证机制
  启动API服务器时,通过命令行选项可以开启认证插件。

12.1.1.用户和组
了解用户:

  分为两种连接到api服务器的客户端:

  1.真实的人

  2.pod,使用一种称为ServiceAccount的机制

了解组:

  认证插件会连同用户名,和用户id返回组,组可以一次性给用户服务多个权限,不用单次赋予,

  system:unauthenticated组:用于所有认证插件都不会认证客户端身份的请求。

  system:authenticated组:会自动分配给一个成功通过认证的用户。

  system:serviceaccount组:包含 所有在系统中的serviceaccount。

  system:serviceaccount:组:包含了所有在特定命名空间中的serviceAccount。

12.1.2 ServiceAccount介绍
  每个pod中都包含/var/run/secrets/kubernetes.io/serviceaccount/token文件,如下图所示,文件内容用于对身份进行验证,token文件持有serviceaccount的认证token。

  

  应用程序使用token去连接api服务器时,认证插件会对serviceaccount进行身份认证,并将serviceaccount的用户名传回到api服务器内部。

   serviceaccount的用户名格式如下:

  system:serviceaccount::

  ServiceAccount是运行在pod中的应用程序,和api服务器身份认证的一中方式。

了解ServiceAccount资源

  ServiceAcount作用在单一命名空间,为每个命名空间创建默认的ServiceAccount。

  多个pod可以使用相同命名空间下的同一的ServiceAccount,

ServiceAccount如何与授权文件绑定

  在pod的manifest文件中,可以指定账户名称的方式,将一个serviceAccount赋值给一个pod,如果不指定,将使用该命名空间下默认的ServiceAccount.

  可以 将不同的ServiceAccount赋值给pod,让pod访问不同的资源。

12.1.3创建ServiceAccount
  为了集群的安全性,可以手动创建ServiceAccount,可以限制只有允许的pod访问对应的资源。

    创建方法如下:

$ kubectl get sa
NAME SECRETS AGE
default 1 21h

$ kubectl create serviceaccount yaohong
serviceaccount/yaohong created

$ kubectl get sa
NAME SECRETS AGE
default 1 21h
yaohong 1 3s
  使用describe来查看ServiceAccount。

$ kubectl describe sa yaohong
Name: yaohong
Namespace: default
Labels:
Annotations:
Image pull secrets:
Mountable secrets: yaohong-token-qhbxn //如果强制使用可挂载秘钥。那么使用这个serviceaccount的pod只能挂载这个秘钥
Tokens: yaohong-token-qhbxn
Events:
  查看该token,

$ kubectl describe secret yaohong-token-qhbxn
Name: yaohong-token-qhbxn
Namespace: default
Labels:
Annotations: kubernetes.io/service-account.name: yaohong

          kubernetes.io/service-account.uid: a3d0d2fe-bb43-11e9-ac1e-005056870b4d

Type: kubernetes.io/service-account-token

Data

ca.crt: 1342 bytes
namespace: 7 bytes
token: eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJkZWZhdWx0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6Inlhb2hvbmctdG9rZW4tcWhieG4iLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC5uYW1lIjoieWFvaG9uZyIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6ImEzZDBkMmZlLWJiNDMtMTFlOS1hYzFlLTAwNTA1Njg3MGI0ZCIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDpkZWZhdWx0Onlhb2hvbmcifQ.BwmbZKoM95hTr39BuZhinRT_vHF-typH4anjkL0HQxdVZEt_eie5TjUECV9UbLRRYIqYamkSxmyYapV150AQh-PvdcLYPmwKQLJDe1-7VC4mO2IuVdMCI_BnZFQBJobRK9EdPdbZ9uxc9l0RL5I5WyWoIjiwbrQvtCUEIkjT_99_NngdrIr7QD9S5SxHurgE3HQbmzC6ItU911LjmxtSvBqS5NApJoJaztDv0cHKvlT67ZZbverJaStQdxr4yiRbpSycRNArHy-UZKbNQXuzaZczSjVouo5A5hzgSHEBBJkQpQ6Tb-Ko5XGjjCgV_b9uQvhmgdPAus8GdFTTFAbCBw
  

12.1.4将ServiceAccount分配给pod
  在pod中定义的spec.serviceAccountName字段上设置,此字段必须在pod创建时设置后续不能被修改。

  自定义pod的ServiceAccount的方法如下图

12.2通过基于角色的权限控制加强集群安全
12.2.1.介绍RBAC授权插件
  RBAC授权插件将用户角色作为决定用户能否执行操作的关机因素。

12.2.2介绍RBAC授权资源
  RBAC授权规则通过四种资源来进行配置的,他们可以分为两组:

    Role和ClusterRole,他们决定资源上可执行哪些动词。

     RoleBinding和ClusterRoleBinding,他们将上述角色绑定到特定的用户,组或者ServiceAccounts上。

  Role和RoleBinding是namespace级别资源

  ClusterRole和ClusterRoleBinding是集群级别资源

12.2.3使用Role和RoleBinding
  Role资源定义了哪些操作可以在哪些资源上执行,

创建Role

  service-reader.yml

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: kube-system
name: service-reader
rules:

  • apiGroups: [""]
    verbs: ["get", "list"]

resources: ["services"]
  在kube-system中创建Role

kubectl -n kube-system create -f service-reader.yml

  查看该namespace下的role

$ kubectl -n kube-system get role
NAME AGE
extension-apiserver-authentication-reader 41h
kube-state-metrics-resizer 41h
service-reader 2m17s
system::leader-locking-kube-controller-manager 41h
system::leader-locking-kube-scheduler 41h
system:controller:bootstrap-signer 41h
system:controller:cloud-provider 41h
system:controller:token-cleaner 41h
绑定角色到ServiceAccount

   将service-reader角色绑定到default ServiceAccount

$ kubectl create rolebinding test --role=service-reader
rolebinding.rbac.authorization.k8s.io/test created
  

$ kubectl get rolebinding test -o yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
creationTimestamp: 2019-08-11T03:40:51Z
name: test
namespace: default
resourceVersion: "239323"
selfLink: /apis/rbac.authorization.k8s.io/v1/namespaces/default/rolebindings/test
uid: d0aff243-bbe9-11e9-ac1e-005056870b4d
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: service-reader
  

12.2.4使用ClusterRole和ClusterRoleBinding
查看集群ClusterRole

kubectl get clusterrole

NAME AGE
admin 42h
cluster-admin 42h
edit 42h
flannel 42h
kube-state-metrics 42h
system:aggregate-to-admin 42h
...
创建ClusterRole

kubectl create clusterrole flannel --verb=get,list -n kube-system 
查看yaml文件

kubectl get clusterrole flannel -o yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
annotations:

kubectl.kubernetes.io/last-applied-configuration: |
  {"apiVersion":"rbac.authorization.k8s.io/v1","kind":"ClusterRole","metadata":{"annotations":{},"name":"flannel"},"rules":[{"apiGroups":[""],"resources":["pods"],"verbs":["get"]},{"apiGroups":[""],"resources":["nodes"],"verbs":["list","watch"]},{"apiGroups":[""],"resources":["nodes/status"],"verbs":["patch"]}]}

creationTimestamp: 2019-08-09T09:58:42Z
name: flannel
resourceVersion: "360"
selfLink: /apis/rbac.authorization.k8s.io/v1/clusterroles/flannel
uid: 45100f6f-ba8c-11e9-8f57-005056870608
rules:

  • apiGroups:

    • ""
      resources:
    • pods
      verbs:
    • get
  • apiGroups:

    • ""
      resources:
    • nodes
      verbs:
    • list
    • watch
  • apiGroups:

    • ""
      resources:
    • nodes/status
      verbs:
    • patch

创建clusterRoleBinding

$ kubectl create clusterrolebinding cluster-tetst --clusterrole=pv-reader --serviceaccount=kuebsystem:yaohong
clusterrolebinding.rbac.authorization.k8s.io/cluster-tetst created
  

12.2.5了解默认的ClusterRole和ClusterRoleBinding
如下所示使用kubectl get clusterroles和kubectl get clusterrolesbinding可以获取k8s默认资源。

用edit ClusterRole允许对资源进行修改

用admin ClusterRole赋予一个命名空间全部的权限

$ kubectl get clusterroles
NAME AGE
admin 44h
cluster-admin 44h
edit 44h
flannel 44h
kube-state-metrics 44h
system:aggregate-to-admin 44h
system:aggregate-to-edit 44h
system:aggregate-to-view 44h
system:auth-delegator 44h
system:aws-cloud-provider 44h
system:basic-user 44h
system:certificates.k8s.io:certificatesigningrequests:nodeclient 44h
system:certificates.k8s.io:certificatesigningrequests:selfnodeclient 44h
system:controller:attachdetach-controller 44h
system:controller:certificate-controller 44h
system:controller:clusterrole-aggregation-controller 44h
。。。
  

wps@wps:~$ kubectl get clusterrolebindings
NAME AGE
clust-tetst 17m
cluster-admin 44h
cluster-tetst 13m
flannel 44h
kube-state-metrics 44h
kubelet-bootstrap 44h
system:aws-cloud-provider 44h
system:basic-user 44h
system:controller:attachdetach-controller 44h
system:controller:certificate-controller 44h
。。。

相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
目录
相关文章
|
1月前
|
Prometheus Kubernetes 监控
k8s部署针对外部服务器的prometheus服务
通过上述步骤,您不仅成功地在Kubernetes集群内部署了Prometheus,还实现了对集群外服务器的有效监控。理解并实施网络配置是关键,确保监控数据的准确无误传输。随着监控需求的增长,您还可以进一步探索Prometheus生态中的其他组件,如Alertmanager、Grafana等,以构建完整的监控与报警体系。
123 60
|
1月前
|
Prometheus Kubernetes 监控
k8s部署针对外部服务器的prometheus服务
通过上述步骤,您不仅成功地在Kubernetes集群内部署了Prometheus,还实现了对集群外服务器的有效监控。理解并实施网络配置是关键,确保监控数据的准确无误传输。随着监控需求的增长,您还可以进一步探索Prometheus生态中的其他组件,如Alertmanager、Grafana等,以构建完整的监控与报警体系。
214 62
|
1月前
|
Kubernetes 安全 Cloud Native
云上攻防-云原生篇&K8s安全-Kubelet未授权访问、API Server未授权访问
本文介绍了云原生环境下Kubernetes集群的安全问题及攻击方法。首先概述了云环境下的新型攻击路径,如通过虚拟机攻击云管理平台、容器逃逸控制宿主机等。接着详细解释了Kubernetes集群架构,并列举了常见组件的默认端口及其安全隐患。文章通过具体案例演示了API Server 8080和6443端口未授权访问的攻击过程,以及Kubelet 10250端口未授权访问的利用方法,展示了如何通过这些漏洞实现权限提升和横向渗透。
154 0
云上攻防-云原生篇&K8s安全-Kubelet未授权访问、API Server未授权访问
|
1月前
|
Kubernetes 应用服务中间件 nginx
搭建Kubernetes v1.31.1服务器集群,采用Calico网络技术
在阿里云服务器上部署k8s集群,一、3台k8s服务器,1个Master节点,2个工作节点,采用Calico网络技术。二、部署nginx服务到k8s集群,并验证nginx服务运行状态。
527 1
|
1月前
|
JSON JavaScript 前端开发
使用 Node.js 和 Express 构建 RESTful API 服务器
【10月更文挑战第3天】使用 Node.js 和 Express 构建 RESTful API 服务器
|
1月前
|
JSON JavaScript 前端开发
使用JavaScript和Node.js构建简单的RESTful API服务器
【10月更文挑战第12天】使用JavaScript和Node.js构建简单的RESTful API服务器
17 0
|
3月前
|
资源调度 Kubernetes API
在K8S中,能否实现不通过api-Server创建Pod?
在K8S中,能否实现不通过api-Server创建Pod?
|
3月前
|
API C# 开发框架
WPF与Web服务集成大揭秘:手把手教你调用RESTful API,客户端与服务器端优劣对比全解析!
【8月更文挑战第31天】在现代软件开发中,WPF 和 Web 服务各具特色。WPF 以其出色的界面展示能力受到欢迎,而 Web 服务则凭借跨平台和易维护性在互联网应用中占有一席之地。本文探讨了 WPF 如何通过 HttpClient 类调用 RESTful API,并展示了基于 ASP.NET Core 的 Web 服务如何实现同样的功能。通过对比分析,揭示了两者各自的优缺点:WPF 客户端直接处理数据,减轻服务器负担,但需处理网络异常;Web 服务则能利用服务器端功能如缓存和权限验证,但可能增加服务器负载。希望本文能帮助开发者根据具体需求选择合适的技术方案。
165 0
|
3月前
|
Kubernetes 负载均衡 API
在K8S中,api-service 和 kube-schedule 高可用原理是什么?
在K8S中,api-service 和 kube-schedule 高可用原理是什么?
|
3月前
|
Kubernetes 监控 API
在k8S中,各模块如何与API Server进行通信的?
在k8S中,各模块如何与API Server进行通信的?
下一篇
无影云桌面