安全方面的常见问题

安装 Istio 之后如何启用或者禁用双向 TLS?

可以利用认证策略目标规则随时为服务设置双向 TLS 认证。请阅读认证策略任务以获取更多相关细节。

如何检查服务是否启动了双向 TLS?

istioctl 工具为此提供了一个选项,你可以像下面那样做:

$ istioctl authn tls-check httpbin.default.svc.cluster.local
HOST:PORT                                  STATUS     SERVER     CLIENT     AUTHN POLICY        DESTINATION RULE
httpbin.default.svc.cluster.local:8080     OK         mTLS       mTLS       default/            default/default

更多详细信息,请参见检查双向 TLS 配置

同一集群中是否可以仅对部分服务启用双向 TLS ?

认证策略可以是网格范围的(对网格中的所有服务都有效)、命名空间范围的(对同一命名空间中的所有服务都有效)或者是针对特定服务的。在集群中可以用任何需要的方式来为服务设置双向 TLS 策略。

如果全局启用了双向 TLS,非 Istio 服务可以访问 Istio 服务吗?

非 Istio 服务无法与 Istio 服务进行通信,除非它们可以提供有效证书,而这种证书也很难提供。这正是双向 TLS 功能的目的。但是,你可以覆盖特定命名空间或服务的全局标志 (global flag)。有关详细信息,请参阅任务

如何使用 Istio 的服务访问非 Istio 服务?

当全局启用双向 TLS 时,全局目标规则 (global destination rule) 匹配群集中的所有服务,无论这些服务是否具有 Istio sidecar。 这包括 Kubernetes API 服务器,以及集群中的任何非 Istio 服务。 要让这些非 Istio 服务与有 Istio sidecar 的服务进行通信,你需要设置目标规则以免除服务。 例如:

cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
 name: "api-server"
spec:
 host: "kubernetes.default.svc.cluster.local"
 trafficPolicy:
   tls:
     mode: DISABLE
EOF

这个目标规则已作为 Istio 安装的一部分添加到系统中,并具有默认的双向 TLS

同样,您可以为其他非 Istio 服务添加目标规则。 有关更多示例,请参阅任务

当启用双向 TLS 认证时应该如何使用 Kubernetes liveness 和 readiness 对服务进行健康检查?

如果启用了双向 TLS 认证,则来自 kubelet 的 http 和 tcp 健康检查将不能正常工作,因为 kubelet 没有 Istio 颁发的证书。

从 Istio 1.0 开始,针对服务新增了 PERMISSIVE 模式 ,因此当这个模式打开时他们可以接受 http 和双向 TLS 流量。这可以解决健康检查问题。 请记住,双向 TLS 没有强制执行,因为其他服务可以使用 http 流量与该服务进行通信。

您可以使用单独的端口进行健康检查,并只在常规服务端口上启用双向 TLS。请参阅 Istio 服务的健康检查了解更多信息。

另一种解决方法是对健康检查使用 liveness 命令,例如,可以在服务 Pod 中安装 curl 并在 Pod 内对自身执行 curl 操作。

一个 readiness 探针的例子:

livenessProbe:
exec:
  command:
  - curl
  - -f
  - http://localhost:8080/healthz # Replace port and URI by your actual health check
initialDelaySeconds: 10
periodSeconds: 5
Istio 是否支持授权和鉴权?

是的。Istio 为网格内的服务提供了授权和鉴权的支持。请参考相关概念文档获取更多这方面的信息。

Istio 权限认证是否使用了 Kubernetes secrets?

是的。Istio 权限认证中密钥和证书的分发是基于 Kubernetes secrets

Secrets 有已知的 安全风险。Kubernetes 团队正在开发 几个功能特性 来提高 Kubernetes secret 的安全性,从 secret 的加密到节点级别的访问控制。并且 Kubernetes 从 1.6 版本引入了 RBAC authorization ,提供了细力度的 secrets 管理。

工作负载中的密钥和证书是加密存储的么?

缺省情况下,这些数据会进行 Base64 编码,但是并没有加密。然而 Kubernetes 中的 Secret 资源加密功能是可以用来进行加密的。

注意 Google 容器引擎(GKE)中这一功能还未启用。因此 Master 节点上运行 ETCD 中的数据可能未被加密,而 Master 节点自身是加密的,请阅读 GKE 相关文档了解更多相关细节。

Istio 中如何配置 Ingress 令其仅接受 TLS 连接?

依照用 HTTPS 加密 Gateway 任务中的陈述进行配置,能够让 Istio Ingress 只接受 TLS 流量。

我可以为 HTTPS 服务安装 Istio sidecar 吗?

是的,你可以这么做。它可以在启用和禁用双向 TLS 的情况下工作。更多详细信息,请参阅双向 TLS 如何与 HTTPS 服务配合使用