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的安全机制"认证与授权"是如何解决的。
- 常用命令
- 安装
- 安装Kubeadm
- 安装单Master集群
- 安装高可用集群(手动分发证书)
- 安装高可用集群(自动分发证书)
- 启动参数解析
- certificate-key
- ETCD相关参数
- Kubernetes端口汇总
- 安装IPv4-IPv6双栈集群
- 下载二进制文件
- 使用Kata容器
- 快速安装shell脚本
- 存储
- 实践
- Ceph-RBD实践
- CephFS实践
- 对象存储
- 阿里云CSI
- CSI
- 安全
- 认证与授权
- 认证
- 认证-实践
- 授权
- ServiceAccount
- NodeAuthorizor
- TLS bootstrapping
- Kubelet的认证
- 准入控制
- 准入控制示例
- Pod安全上下文
- Selinux-Seccomp-Capabilities
- 给容器配置安全上下文
- PodSecurityPolicy
- K8S-1.8手动开启认证与授权
- Helm
- Helm命令
- Chart
- 快速入门
- 内置对象
- 模板函数与管道
- 模板函数列表
- 流程控制
- Chart依赖
- Repository
- 开源的Chart包
- CRD
- CRD入门
- 工作负载
- Pod
- Pod的重启策略
- Container
- 探针
- 工作负载的状态
- 有状态服务
- 网络插件
- Multus
- Calico+Flannel
- 容器网络限速
- 自研网络插件
- 设计文档
- Cilium
- 安装Cilium
- Calico
- Calico-FAQ
- IPAM
- Whereabouts
- 控制平面与Pod网络分开
- 重新编译
- 编译kubeadm
- 编译kubeadm-1.23
- 资源预留
- 资源预留简介
- imagefs与nodefs
- 资源预留 vs 驱逐 vs OOM
- 负载均衡
- 灰度与蓝绿
- Ingress的TLS
- 多个NginxIngressController实例
- Service的会话亲和
- CNI实践
- CNI规范
- 使用cnitool模拟调用
- CNI快速入门
- 性能测试
- 性能测试简介
- 制作kubemark镜像
- 使用clusterloader2进行性能测试
- 编译clusterloader2二进制文件
- 搭建性能测试环境
- 运行density测试
- 运行load测试
- 参数调优
- Measurement
- TestMetrics
- EtcdMetrics
- SLOMeasurement
- PrometheusMeasurement
- APIResponsivenessPrometheus
- PodStartupLatency
- FAQ
- 调度
- 亲和性与反亲和性
- GPU
- HPA
- 命名规范
- 可信云认证
- 磁盘限速
- Virtual-kubelet
- VK思路整理
- Kubebuilder
- FAQ
- 阿里云日志服务SLS