Kubernetes指南
Linux性能优化实战eBPF 核心技术与实战SDN指南个人博客
中文
中文
  • 序言
  • 基础入门
    • Kubernetes 简介
    • Kubernetes 基本概念
    • Kubernetes 101
    • Kubernetes 201
    • Kubernetes 集群
  • 核心原理
    • 核心原理
    • 架构原理
    • 设计理念
    • 核心组件
      • etcd
      • kube-apiserver
      • kube-scheduler
      • kube-controller-manager
      • kubelet
      • kube-proxy
      • kube-dns
      • Federation
      • kubeadm
      • hyperkube
      • kubectl
    • 资源对象
      • Autoscaling
      • ConfigMap
      • CronJob
      • CustomResourceDefinition
      • DaemonSet
      • Deployment
      • Ingress
      • Job
      • LocalVolume
      • Namespace
      • NetworkPolicy
      • Node
      • PersistentVolume
      • Pod
      • PodPreset
      • ReplicaSet
      • Resource Quota
      • Secret
      • SecurityContext
      • Service
      • ServiceAccount
      • StatefulSet
      • Volume
  • 部署配置
    • 部署指南
    • kubectl 安装
    • 单机部署
    • 特性开关
    • 最佳配置
    • 版本支持
    • 集群部署
      • kubeadm
      • kops
      • Kubespray
      • Azure
      • Windows
      • LinuxKit
      • kubeasz
    • 附加组件
      • Addon-manager
      • DNS
      • Dashboard
      • 监控
      • 日志
      • Metrics
      • GPU
      • Cluster Autoscaler
      • ip-masq-agent
    • Kubernetes-The-Hard-Way
      • 准备部署环境
      • 安装必要工具
      • 创建计算资源
      • 配置创建证书
      • 配置生成配置
      • 配置生成密钥
      • 部署 Etcd 群集
      • 部署控制节点
      • 部署计算节点
      • 配置 Kubectl
      • 配置网络路由
      • 部署 DNS 扩展
      • 烟雾测试
      • 删除集群
  • 插件扩展
    • API 扩展
      • Aggregation
      • CustomResourceDefinition
    • 访问控制
      • 认证
      • RBAC 授权
      • 准入控制
    • Scheduler 扩展
    • 网络插件
      • CNI
      • Flannel
      • Calico
      • Weave
      • Cilium
      • OVN
      • Contiv
      • SR-IOV
      • Romana
      • OpenContrail
      • Kuryr
    • 运行时插件 CRI
      • CRI-tools
      • Frakti
    • 存储插件
      • 容器存储接口 CSI
      • FlexVolume
      • glusterfs
    • 网络策略
    • Ingress Controller
      • Ingress + Letsencrypt
      • minikube Ingress
      • Traefik Ingress
      • Keepalived-VIP
    • Cloud Provider 扩展
    • Device 插件
  • 服务治理
    • 服务治理
      • 一般准则
      • 滚动升级
      • Helm
      • Operator
      • Service Mesh
      • Linkerd
      • Linkerd2
    • Istio
      • 安装
      • 流量管理
      • 安全管理
      • 策略管理
      • 度量管理
      • 排错
      • 社区
    • Devops
      • Draft
      • Jenkins X
      • Spinnaker
      • Kompose
      • Skaffold
      • Argo
      • Flux GitOps
  • 实践案例
    • 实践概览
    • 资源控制
    • 集群高可用
    • 应用高可用
    • 调试
    • 端口映射
    • 端口转发
    • 用户管理
    • GPU
    • HugePage
    • 安全
    • 审计
    • 备份恢复
    • 证书轮换
    • 大规模集群
    • 大数据与机器学习
      • Spark
      • Tensorflow
    • Serverless
  • 排错指南
    • 排错概览
    • 集群排错
    • Pod 排错
    • 网络排错
    • PV 排错
      • AzureDisk
      • AzureFile
    • Windows 排错
    • 云平台排错
      • Azure
    • 排错工具
  • 社区贡献
    • 开发指南
    • 单元测试和集成测试
    • 社区贡献
  • 附录
    • 生态圈
    • 学习资源
    • 国内镜像
    • 如何贡献
    • 参考文档
由 GitBook 提供支持
在本页
  • RBAC
  • 开启 RBAC
  • 访问控制
  • 双向 TLS
  • 实现原理
  • 最佳实践
  • 参考文档
  1. 服务治理
  2. Istio

安全管理

上一页流量管理下一页策略管理

最后更新于2年前

Istio 提供了 RBAC 访问控制、双向 TLS 认证以及密钥管理等安全管理功能。

RBAC

Istio Role-Based Access Control (RBAC) 提供了 namespace、service 以及 method 级别的访问控制。其特性包括

  • 简单易用:提供基于角色的语意

  • 支持认证:提供服务 - 服务和用户 - 服务的认证

  • 灵活:提供角色和角色绑定的自定义属性

开启 RBAC

通过 RbacConfig 来启用 RBAC,其中 mode 支持如下选项:

  • OFF: 停用 RBAC。

  • ON: 为网格中的所有服务启用 RBAC。

  • ON_WITH_INCLUSION: 只对 inclusion 字段中包含的命名空间和服务启用 RBAC。

  • ON_WITH_EXCLUSION: 对网格内的所有服务启用 RBAC,除 exclusion 字段中包含的命名空间和服务之外。

下面的例子为 default 命名空间开启 RBAC:

apiVersion: "config.istio.io/v1alpha2"
kind: RbacConfig
metadata:
  name: default
  namespace: istio-system
spec:
  mode: ON_WITH_INCLUSION
  inclusion:
    namespaces: ["default"]

访问控制

Istio RBAC 提供了 ServiceRole 和 ServiceRoleBinding 两种资源对象,并以 CustomResourceDefinition (CRD) 的方式管理。

  • ServiceRole 定义了一个可访问特定资源(namespace 之内)的服务角色,并支持以前缀通配符和后缀通配符的形式匹配一组服务

  • ServiceRoleBinding 定义了赋予指定角色的绑定,即可以指定的角色和动作访问服务

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRole
metadata:
  name: products-viewer
  namespace: default
spec:
  rules:
  - services: ["products.default.svc.cluster.local"]
    methods: ["GET", "HEAD"]

---
apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRoleBinding
metadata:
  name: test-binding-products
  namespace: default
spec:
  subjects:
  - user: "service-account-a"
  - user: "istio-ingress-service-account"
    properties:
    - request.auth.claims[email]: "a@foo.com"
    roleRef:
    kind: ServiceRole
    name: "products-viewer"

双向 TLS

双向 TLS 为服务间通信提供了 TLS 认证,并提供管理系统自动管理密钥和证书的生成、分发、替换以及撤销。

实现原理

Istio Auth 由三部分组成:

  • 身份(Identity):Istio 使用 Kubernetes service account 来识别服务的身份,格式为 spiffe://<*domain*>/ns/<*namespace*>/sa/<*serviceaccount*>

  • 通信安全:端到端 TLS 通信通过服务器端和客户端的 Envoy 容器完成

  • 证书管理:Istio CA (Certificate Authority) 负责为每个 service account 生成 SPIFEE 密钥和证书、分发到 Pod(通过 Secret Volume Mount 的形式)、定期轮转(Rotate)以及必要时撤销。对于 Kuberentes 之外的服务,CA 配合 Istio node agent 共同完成整个过程。

这样,一个容器使用证书的流程为

  • 首先,Istio CA 监听 Kubernetes API,并为 service account 生成 SPIFFE 密钥及证书,再以 secret 形式存储到 Kubernetes 中

  • 然后,Pod 创建时,Kubernetes API Server 将 secret 挂载到容器中

  • 最后,Pilot 生成一个访问控制的配置,定义哪些 service account 可以访问服务,并分发给 Envoy

  • 而当容器间通信时,Pod 双方的 Envoy 就会基于访问控制配置来作认证

最佳实践

  • 为不同团队创建不同 namespace 分别管理

  • 将 Istio CA 运行在单独的 namespace 中,并且仅授予管理员权限

参考文档

Istio Security 文档
Istio Role-Based Access Control (RBAC)
Istio 双向 TLS 文档
image-20180423202459184