kubernetes
  • Introduction
  • 安装
    • 组件端口
    • 二进制安装
    • Kubeadm
      • 安装单Master集群
      • 安装高可用集群(手动分发证书)
      • 安装高可用集群(自动上传证书)
      • 安装ETCD集群
      • 安装高可用集群(外部ETCD)
    • 启动参数解析
      • ETCD相关参数
  • 负载均衡
    • Service
    • Ingress
    • 安装MetalLB
    • Nginx-ingress-controller
      • 转发TCP与UDP服务
      • 启动参数
      • 自定义Nginx模板
  • 存储
    • Volume
    • PV与PVC
    • StorageClass
    • Local-PV
      • Static-Provisioner
    • 实践
      • Ceph-RBD
      • NFS
  • 有状态服务
    • Mysql实践
    • Operator
      • Etcd
      • Zookeeper
      • Mysql
  • 认证与授权
    • 认证
      • 实践
    • 授权
  • Helm
    • 安装
    • Chart
      • 依赖
    • Helm命令
    • Repository
  • 日志
  • 监控
    • Prometheus体系
      • Prometheus
        • 内置函数
        • 配置
          • 规则文件
        • PromQL
      • Exporter
        • Metrics
      • Grafana
        • 配置
      • AlertManager
        • 配置
    • 容器监控
      • Cadvisor的指标
      • k8s中部署Prom与Cadvisor
  • Istio
  • 资源预留
    • imagefs与nodefs
    • 总结
  • 集群联邦
    • 联邦DNS原理
    • 联邦DNS安装
    • 安装federation-v1
  • Other
    • ImagePullSecret
    • QOS
    • Apiserver的代理
    • 资源配额
Powered by GitBook
On this page

Was this helpful?

认证与授权

k8s为什么需要认证与授权这样的安全机制?

首先第一个场景:假设我们装好了一个k8s集群,不想给其他人使用。假设在同一个子网的其他主机上,其他人扫描到了k8s集群的地址与端口,虽然他们无法登录k8s集群的主机,但是他们知道了master的地址后,可以通过API访问集群。此时,我们该如何阻止别人通过API操作集群内的资源呢?

这个场景产生的安全问题,很多其他组件都有,比如etcd等等。

第二个场景:一个管理员创建了一个k8s集群,给两个用户使用,每个用户分配一个命名空间。两个用户拿到了这个集群的apiserver的地址,不能登录master主机,但能够通过API访问集群,那么管理员如何控制用户A只能操作命名空间user-a下的资源,用户B只能操作user-b下的资源呢?举个例子

用户A发起如下一个请求,获取自已命名空间下的Pod,管理员如何做到该请求能够正常返回?

GET ip:port/api/v1/namespaces/user-a/pods

假设用户A又发起如下一个请求,获取用户B的命名空间下的Pod,管理员如何做才能使用该请求被拒绝呢?

GET ip:port/api/v1/namespaces/user-b/pods

基于上面的问题,我们接下来介绍k8s的安全机制"认证与授权"是如何解决的。

PreviousMysqlNext认证

Last updated 5 years ago

Was this helpful?