Istio安全-证书管理(实操一)

Istio安全-证书管理

注:本章更新至1.8版本

插入现有CA证书

本节展示了管理员如何使用现有的根证书来授权istio证书,签发证书和密钥,不使用Istio自动生成的证书。

默认情况下,istio的CA会生成一个自签的根证书和密钥,并使用它们签发负载证书。istio的CA也可以使用管理员指定的证书和密钥,以及管理员指定的根证书来签发负载证书。

根CA是网格中所有负载信任的根证书。每个Istio CA会使用一个中间CA来签发密钥和证书,该CA由根CA签发。当一个网格中存在多个Istio CA时,会在CA之间建立起信任层级。

本节展示如何将这些证书和密钥插入Istio的CA。

插入现有证书和密钥

在istio的samples/certs目录下有一套证书,可以比较好地解释istio的证书交互原理。

  • root-cert.pem: root CA certificate.
  • ca-[cert|key].pem: Citadel intermediate certificate and corresponding private key.
  • cert-chain.pem: certificate trust chain.
  • workload-foo-[cert|key].pem: workload certificate and key for URI SAN spiffe://trust-domain-foo/ns/foo/sa/foo signed by ca-cert.key.
  • workload-bar-[cert|key].pem: workload certificate and key for URI SAN spiffe://trust-domain-bar/ns/bar/sa/bar signed by ca-cert.key.

假如希望使用现有的CA证书ca-cert.pemca-key.pem(root-cert.pem签发了ca-cert.pem,因此root-cert.pem作为所有负载的根证书)。由于ca-cert.pem不同于root-cert.pem,因此无法直接通过根证书进行校验,此时需要通过一个cert-chain.pem来指定信任链,包含负载到根CA的所有中间CAs。在上述例子中,仅包含了istio的CA签名证书,因此cert-chain.pemca-cert.pem相同。注意:如果 ca-cert.pemroot-cert.pem是相同的,那么 cert-chain.pem文件应该是空的。

上述证书例子中的证书链为:root-cert.pem-->cert-chain.pem(含ca-cert.pem)-->workload-foo-cert.pem/workload-bar-cert.pem,可以使用如下方式进行校验:

# openssl verify -CAfile <(cat ca-cert.pem root-cert.pem) workload-bar-cert.pem
workload-bar-cert.pem: OK

对于生产环境,最好在一台离线机器上执行如下步骤,确保将根密钥暴露给尽可能少的人

  1. 创建一个保存证书和密钥的目录

    $ mkdir -p certs
    $ pushd certs
    
  2. 生成根证书和密钥

    $ make -f ../tools/certs/Makefile.selfsigned.mk root-ca
    

    上述命令将生成如下文件:

    • root-cert.pem: 根证书
    • root-key.pem: 根密钥
    • root-ca.conf: openssl 使用该配置来生成根证书
    • root-cert.csr: 为根证书生成的CSR
  3. 生成中间证书和密钥

    $ make -f ../tools/certs/Makefile.selfsigned.mk cluster1-cacerts
    

    执行如上命令会生成一个名为cluster1的目录,包含如下文件,root-cert.pem签发了ca-cert.pem

    • ca-cert.pem: 中间证书
    • ca-key.pem: 中间密钥
    • cert-chain.pem: Istiod使用的证书链
    • root-cert.pem: 根证书
    • intermediate.conf: openssl 使用该配置来生成中间证书
    • cluster-ca.csr: 为中间证书生成的CSR

    可以将cluster1替换为任何字符串。例如make mycluster-certs将会生成名为mycluster的目录

    为了配置其他Istio CA,可以重复执行上述步骤来生成不同名称的证书目录

  4. 创建一个cacerts secret,包含如下输入文件ca-cert.pem,ca-key.pem,root-cert.pemcert-chain.pem。需要注意的是创建出来的secret的名称必须是cacerts,这样才能被istio正确挂载。

    $ kubectl create namespace istio-system
    $ kubectl create secret generic cacerts -n istio-system \
          --from-file=cluster1/ca-cert.pem \
          --from-file=cluster1/ca-key.pem \
          --from-file=cluster1/root-cert.pem \
          --from-file=cluster1/cert-chain.pem
    
  5. 返回Istio安装的顶层目录

    $ popd
    

部署Istio

使用demo profile,Istio会从挂载的secret文件中读取证书

$ istioctl install --set profile=demo

在下面的例子中,istio的CA证书(ca-cert.pem)与根证书(root-cert.pem)不同,因此负载无法通过根证书验证工作负载证书,需要使用一个cert-chain.pem来指定信任的证书链,该证书链包含负载和根CA之间的所有中间CA,在此例子中,它包含了istio的CA签名证书,因此cert-chain.pemca-cert.pem相同的。注意,如果ca-cert.pemroot-cert.pem相同,那么ca-chain.pem文件应该是空的。

配置示例services

  1. 部署httpbin和sleep示例services

    $ kubectl create ns foo
    $ kubectl apply -f <(istioctl kube-inject -f samples/httpbin/httpbin.yaml) -n foo
    $ kubectl apply -f <(istioctl kube-inject -f samples/sleep/sleep.yaml) -n foo
    
  2. 部署一个策略,使得foo命名空间的负载仅接受mutual TLS流量

    $ kubectl apply -n foo -f - <<EOF
    apiVersion: "security.istio.io/v1beta1"
    kind: "PeerAuthentication"
    metadata:
      name: "default"
    spec:
      mtls:
        mode: STRICT
    EOF
    

校验证书

本节中会校验插入到CA中的证书是否签发了负载证书。

  1. sleep 20s,等待mTLS策略下httpbin的证书链生效。由于CA证书是自签的,因此openssl命令会返回verify error:num=19:self signed certificate in certificate chain错误。

    $ sleep 20; kubectl exec "$(kubectl get pod -l app=sleep -n foo -o jsonpath={.items..metadata.name})" -c istio-proxy -n foo -- openssl s_client -showcerts -connect httpbin.foo:8000 > httpbin-proxy-cert.txt
    
  2. 解析证书链中的证书

    $ sed -n '/-----BEGIN CERTIFICATE-----/{:start /-----END CERTIFICATE-----/!{N;b start};/.*/p}' httpbin-proxy-cert.txt > certs.pem
    $ awk 'BEGIN {counter=0;} /BEGIN CERT/{counter++} { print > "proxy-cert-" counter ".pem"}' < certs.pem
    
  3. 校验根证书与管理员指定的证书相同

    $ openssl x509 -in samples/certs/root-cert.pem -text -noout > /tmp/root-cert.crt.txt
    $ openssl x509 -in ./proxy-cert-3.pem -text -noout > /tmp/pod-root-cert.crt.txt
    $ diff -s /tmp/root-cert.crt.txt /tmp/pod-root-cert.crt.txt
    Files /tmp/root-cert.crt.txt and /tmp/pod-root-cert.crt.txt are identical
    
  4. 校验CA证书与管理员指定的相同

    $ openssl x509 -in samples/certs/ca-cert.pem -text -noout > /tmp/ca-cert.crt.txt
    $ openssl x509 -in ./proxy-cert-2.pem -text -noout > /tmp/pod-cert-chain-ca.crt.txt
    $ diff -s /tmp/ca-cert.crt.txt /tmp/pod-cert-chain-ca.crt.txt
    Files /tmp/ca-cert.crt.txt and /tmp/pod-cert-chain-ca.crt.txt are identical
    
  5. 校验从根证书到负载证书的证书链。下面使用中间证书和根证书组成的证书链来校验其签发了负载证书

    $ openssl verify -CAfile <(cat samples/certs/ca-cert.pem samples/certs/root-cert.pem) ./proxy-cert-1.pem
    ./proxy-cert-1.pem: OK
    

卸载

卸载证书cacertfoo以及istio-system命名空间

$ kubectl delete secret cacerts -n istio-system
$ kubectl delete ns foo istio-system

Istio的DNS证书管理

本节展示如何使用 Chiron提供和管理DNS证书,Chiron是一个与istiod相连的轻量型组件,它使用kubernetes的CA API签发证书,无需管理私钥。有如下优势:

  • 与isitod不同,这种方式无需维护签发的私钥,增强了安全性
  • 简化了将根证书分发到TLS客户端。客户端不再需要等待istiod生成并分发其CA证书

首先使用istioctl安装istio,并配置DNS证书,当istiod启动后会读取该配置:

$ cat <<EOF > ./istio.yaml
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    certificates:
      - secretName: dns.example1-service-account
        dnsNames: [example1.istio-system.svc,example1.istio-system]
      - secretName: dns.example2-service-account
        dnsNames: [example2.istio-system.svc,example2.istio-system]
EOF
$ istioctl install -f ./istio.yaml

可以看到在istio-system下生成了两个secret:

# kubectl get secret -n istio-system |grep dns
dns.example1-service-account                       istio.io/dns-key-and-cert             3      81s
dns.example2-service-account                       istio.io/dns-key-and-cert             3      81s

DNS证书的提供和管理

Istio根据用户的配置为DNS证书提供了DNS名字和secret名称。DNS证书由kubernetes CA签发,并根据配置保存到secret中。istio也管理着DNS证书的生命周期,包括证书滚动和重新生成。

配置DNS证书

可以在 istioctl install 命令中使用IstioControlPlane用户资源对istio进行配置。dnsNames字段用于设定证书中的DNS名称,secretName字段指定保存证书和密钥的kubernetes secret的名称。

检查提供的DNS证书

在配置istio生成DNS证书并保存到secret后,需要校验提供的证书是否能够正确运行。

为了校验istio前面例子中生成的dns.example1-service-account的DNS证书,以及校验该证书是否包含配置的DNS名称,需要获取kubernetes的secret,解析并对其解码,查看其具体内容:

$ kubectl get secret dns.example1-service-account -n istio-system -o jsonpath="{.data['cert-chain\.pem']}" | base64 --decode | openssl x509 -in /dev/stdin -text -noout

输出的文本包括:

X509v3 Subject Alternative Name:
    DNS:example1.istio-system.svc,DNS:example1.istio-system

重新生成DNS证书

istio可以在DNS证书被错删的情况下重新生成证书。

  1. 删除前面保存的DNS证书

    $ kubectl delete secret dns.example1-service-account -n istio-system
    
  2. 校验istio重新生成了删除的DNS证书,且证书包含配置的DNS名称。需要从kubernetes获取secret,解析并对其解码,获取其内容:

    $sleep 10; kubectl get secret dns.example1-service-account -n istio-system -o jsonpath="{.data['cert-chain\.pem']}" | base64 --decode | openssl x509 -in /dev/stdin -text -noout
    

输出包括

X509v3 Subject Alternative Name:
    DNS:example1.istio-system.svc,DNS:example1.istio-system

卸载

$ kubectl delete ns istio-system

版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。

相关推荐


istio的授权功能,也称为基于角色的访问控制(RBAC),它为istio服务网格中的服务提供命名空间级别、服务级别和方法级别的访问控制。基于角色的访问控制具有简单易用、灵活和高性能等特性。本文介绍如何在服务网格中为服务进行授权控制。·前置条件·•安装istio的k8s集群,启用认证功能、
Errorfromserver(Forbidden):errorwhencreating"oot/istio.yaml":configmaps"istio-galley-configuration"isforbidden:unabletocreatenewcontentinnamespaceistio-systembecauseitisbeingterminatedErrorfromserver(Forbid
3.1Istio的核心组件及其功能Istio总体分两部分:控制面和数据面。数据面(sidecar):sidecar通过注入的方式和业务容器共存于一个pod,会劫持业务容器的流量,并接受控制面组件的控制,同时会向控制面输出日志、跟踪以及监控数据。控制面:Istio的核心,管理Istio的所有功能。
在Istio中,双向TLS是传输身份验证的完整堆栈解决方案,它为每个服务提供可跨集群的强大身份、保护服务到服务通信和最终用户到服务通信,以及提供密钥管理系统。本文阐述如何在不中断通信的情况下,把现存Istio服务的流量从明文升级为双向TLS。使用场景 在部署了Istio的集群中,使用人员
在之前的最佳实践中,已经带大家通过一系列的实践任务领略了Istio的无穷魅力。今天,将向大家介绍如何用Istio实现流量熔断。熔断机制是创建弹性微服务应用程序的重要模式。熔断可以帮助您自由控制故障影响的范围、网络延迟的峰值以及抵御其他一些来自外部的恶意***等场景。在接下来
流量镜像流量镜像,也称为影子流量,流量镜像提供一种尽可能低的风险为生产带来变化的强大功能。镜像会将实时流量的副本发送到镜像服务。镜像流量发生在主服务的关键请求路径之外。在非生产或者测试环境中,尝试访问一个服务所有可能的测试用例组合是个非常不现实的任务。在某些情况下
一、负载均衡算法原理与实战负载均衡算法(loadbalancingalgorithm),定义了几种基本的流量分发方式,在Istio中一共有4种标准负载均衡算法。•Round_Robin:轮询算法,顾名思义请求将会依次发给每一个实例,来共同分担所有的请求。•Random:随机算法,将所有的请求随机分发给健康的实例•
本文整理自华为CloudBU技术专家在K8S技术社上关于Istio调用链的分享。前言大家好,我是idouba,来自华为CloudBU,当前在做Istio服务网格在华为云容器服务的产品化工作。今天跟大家分享的主题是Istio调用链相关内容。通过剖析Istio的架构机制与Istio中调用链的工作原理来解答一个大
今天,我们就来谈谈Istio主打功能---保护服务。那么,便引出3个问题:Istio凭什么保护服务?Istio具体如何保护服务?如何告诉Istio发挥保护能力?Istio凭什么保护服务?将单体应用程序分解为一个个服务,为大型软件系统的开发和维护带来了诸多好处,比如更好的灵活性、可伸缩性和可复用性
istio-opentracing链路追踪方案istio-opentracing链路追踪主要是由sidecar(envoy)支持的,istio只是在上层进行配置的修改。envoy链路追踪envoy主要用三个功能来支撑系统范围内的跟踪生成RequestID:envoy会在需要的时候生成UUID,并操作名为[x-request-id]的HTTPHeader。应用可
在前面的文章中,大家都已经熟悉了Istio的故障注入和流量迁移。这两个方面的功能都是Istio流量治理的一部分。今天将继续带大家了解Istio的另一项功能,关于请求超时的管理。首先我们可以通过一个简单的Bookinfo的微服务应用程序来动手实践一下Istio是如何实现请求超时的管理。看过ido
调用链原理和场景正如ServiceMesh的诞生是为了解决大规模分布式服务访问的治理问题,调用链的出现也是为了对应于大规模的复杂的分布式系统运行中碰到的故障定位定界问题。大量的服务调用、跨进程、跨服务器,可能还会跨多个物理机房。无论是服务自身问题还是网络环境的问题导致调用
在Istio中,双向TLS是传输身份验证的完整堆栈解决方案,它为每个服务提供可跨集群的强大身份、保护服务到服务通信和最终用户到服务通信,以及提供密钥管理系统。本文阐述如何在不中断通信的情况下,把现存Istio服务的流量从明文升级为双向TLS。使用场景在部署了Istio的集群中,使用人员刚
前言在Istio的世界里,如果想把外部的请求流量引入网格,你需要认识并会学会配置IstioIngressGateway什么是IngressGateway由于KubernetesIngressAPI只能支持最基本的HTTP路由,使用KubernetesIngress资源来配置外部流量的方式不能满足需求。因此Istiov1alpha3routingAPI引
Istio是什么?使用云平台可以为组织提供丰富的好处。然而,不可否认的是,采用云可能会给DevOps团队带来压力。开发人员必须使用微服务已满足应用的可移植性,同时运营商管理了极其庞大的混合和多云部署。Istio允许您连接、保护、控制和观测服务。在较高的层次上,Istio有助于降低这些
Istio利用k8s的探针对service进行流量健康检查,有两种探针可供选择,分别是liveness和readiness:liveness探针用来侦测什么时候需要重启容器。比如说当liveness探针捕获到程序运行时出现的一个死锁,这种情况下重启容器可以让程序更容易可用。readiness探针用来使容器准备好接收流量。
摘要使用Istio可以很方便地实现微服务间的访问控制。本文演示了使用Denier适配器实现拒绝访问,和Listchecker适配器实现黑白名单两种方法。使用场景有时需要对微服务间的相互访问进行控制,比如使满足某些条件(比如版本)的微服务能够(或不能)调用特定的微服务。访问控制属于策略
导读目前以Kubernetes为基础构建的容器生态逐渐完善,这其中Kubernetes、Istio、Knative三个独立项目被越来越多的人提及,并且已经开始尝试大规模落地实践,它们恰好构成了容器云的未来拼图。今天与大家一起分享下,这三个项目究竟解决了什么问题,为什么它们能够一鸣惊人。随着微服务理念
注:以下讲述的按理环境场景是基于Kubernetes环境基础上部署的Istio环境。涉及到Envoy概念介绍请参考深度解析Istio系列之流量控制篇。本文重点针对Envoy初始化场景进行拆解。Istio-proxy(Envoy)作为Istio数据平面的重要组件,基于sidecar方式与业务应用混合部署到同一pod,为应用提
使用云平台可以为组织提供丰富的好处。然而,不可否认的是,采用云可能会给DevOps团队带来压力。开发人员必须使用微服务以满足应用的可移植性,同时运营商管理了极其庞大的混合和多云部署。Istio允许您连接、保护、控制和观测服务。在较高的层次上,Istio有助于降低这些部署的复杂性,