mirror of https://github.com/istio/istio.io.git
[Release 1.3] Temporarily disable the user guide of Istio Vault integration for release 1.3 (#4904)
* Temporarily disable the user guide of Istio Vault integration for release 1.3 Istio release 1.3 uses new k8s JWT (https://github.com/istio/istio/pull/16147), which breaks the user guide of Istio Vault CA integration for release 1.3. This PR temporarily disables the user guide of Istio Vault CA integration for release 1.3.
This commit is contained in:
lei-tang
Martin Taillefer
parent
05c692b820
commit
dc7acb1b18
|
|
@ -83,7 +83,6 @@ The `Sidecar` runtime is considered Beta. However, its API is still subject to
|
|||
| [End User (JWT) Authentication](/docs/concepts/security/#authentication) | Alpha
|
||||
| [OPA Checker](/docs/reference/config/policy-and-telemetry/adapters/opa/) | Alpha
|
||||
| [TCP Authorization (RBAC)](/docs/tasks/security/authz-tcp) | Alpha
|
||||
| [Vault integration](/docs/tasks/security/vault-ca) | Alpha
|
||||
| [SDS Integration](/docs/tasks/security/auth-sds/) | Alpha
|
||||
|
||||
The 'Authorization (RBAC)' runtime is considered Beta. However, its API is still subject to a backwards incompatible change. Due to this, we advertise it as Alpha.
|
||||
|
|
|
|||
|
|
@ -112,8 +112,6 @@ concise list of things you should know before upgrading your deployment to Istio
|
|||
|
||||
- **Custom PKI Integration**. Added Vault PKI integration with support for
|
||||
Vault-protected signing keys and ability to integrate with existing Vault PKIs.
|
||||
See [Istio Vault CA Integration](/docs/tasks/security/vault-ca)
|
||||
for more information.
|
||||
|
||||
- **Customized (non `cluster.local`) Trust Domains**. Added support for
|
||||
organization- or cluster-specific trust domains in the identities.
|
||||
|
|
|
|||
|
|
@ -1,156 +0,0 @@
|
|||
---
|
||||
title: Istio Vault CA Integration
|
||||
description: This task shows you how to integrate a Vault Certificate Authority with Istio for mutual TLS.
|
||||
weight: 10
|
||||
keywords: [security,certificate]
|
||||
---
|
||||
|
||||
This task shows you how to integrate a [Vault Certificate Authority (CA)](https://www.vaultproject.io/) with Istio to issue certificates
|
||||
for workloads in the mesh. This task includes a demo of Istio mutual TLS using certificates issued by a Vault CA.
|
||||
|
||||
## Before you begin
|
||||
|
||||
* Create a new Kubernetes cluster to run the example in this tutorial.
|
||||
|
||||
## Certificate request flow
|
||||
|
||||
At high level, an Istio proxy (i.e., Envoy) requests a certificate from Node Agent
|
||||
through SDS. Node Agent sends a CSR (Certificate Signing Request), with the Kubernetes service
|
||||
account token of the Istio proxy attached, to Vault CA. Vault CA authenticates and authorizes
|
||||
the CSR based on the Kubernetes service account token and returns the signed certificate
|
||||
to Node Agent, which returns the signed certificate to the Istio proxy.
|
||||
|
||||
## Install Istio with mutual TLS and SDS enabled
|
||||
|
||||
1. Install Istio with mutual TLS and SDS enabled using [Helm](/docs/setup/install/helm/#prerequisites)
|
||||
and Node Agent sending certificate signing requests to a testing Vault CA:
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl create clusterrolebinding cluster-admin-binding --clusterrole=cluster-admin --user="$(gcloud config get-value core/account)"
|
||||
$ kubectl create namespace istio-system
|
||||
$ helm template install/kubernetes/helm/istio-init --name istio-init --namespace istio-system | kubectl apply -f -
|
||||
$ helm template \
|
||||
--name=istio \
|
||||
--namespace=istio-system \
|
||||
--set global.mtls.enabled=true \
|
||||
--values install/kubernetes/helm/istio/example-values/values-istio-example-sds-vault.yaml \
|
||||
install/kubernetes/helm/istio > istio-auth.yaml
|
||||
$ kubectl apply -f istio-auth.yaml
|
||||
{{< /text >}}
|
||||
|
||||
The yaml file [`values-istio-example-sds-vault.yaml`]({{< github_file >}}/install/kubernetes/helm/istio/example-values/values-istio-example-sds-vault.yaml)
|
||||
contains the configuration that enables SDS (secret discovery service) in Istio.
|
||||
The Vault CA related configuration is set as environmental variables:
|
||||
|
||||
{{< text yaml >}}
|
||||
env:
|
||||
- name: CA_ADDR
|
||||
value: "https://34.83.129.211:8200"
|
||||
- name: CA_PROVIDER
|
||||
value: "VaultCA"
|
||||
- name: "VAULT_ADDR"
|
||||
value: "https://34.83.129.211:8200"
|
||||
- name: "VAULT_AUTH_PATH"
|
||||
value: "auth/kubernetes/login"
|
||||
- name: "VAULT_ROLE"
|
||||
value: "istio-cert"
|
||||
- name: "VAULT_SIGN_CSR_PATH"
|
||||
value: "istio_ca/sign/istio-pki-role"
|
||||
{{< /text >}}
|
||||
|
||||
1. The testing Vault server used in this tutorial has the IP
|
||||
address `34.83.129.211`. Create a service entry with the address of the testing
|
||||
Vault server:
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl apply -f - <<EOF
|
||||
apiVersion: networking.istio.io/v1alpha3
|
||||
kind: ServiceEntry
|
||||
metadata:
|
||||
name: vault-service-entry
|
||||
spec:
|
||||
hosts:
|
||||
- vault-server
|
||||
addresses:
|
||||
- 34.83.129.211/32
|
||||
ports:
|
||||
- number: 8200
|
||||
name: https
|
||||
protocol: HTTPS
|
||||
location: MESH_EXTERNAL
|
||||
EOF
|
||||
{{< /text >}}
|
||||
|
||||
## Deploy workloads for testing
|
||||
|
||||
This section deploys the `httpbin` and `sleep` workloads for testing. When the sidecar of a
|
||||
testing workload requests a certificate through SDS, Node Agent will send
|
||||
certificate signing requests to Vault.
|
||||
|
||||
1. Generate the deployments for the `httpbin` and `sleep` backends:
|
||||
|
||||
{{< text bash >}}
|
||||
$ istioctl kube-inject -f @samples/httpbin/httpbin-vault.yaml@ > httpbin-injected.yaml
|
||||
$ istioctl kube-inject -f @samples/sleep/sleep-vault.yaml@ > sleep-injected.yaml
|
||||
{{< /text >}}
|
||||
|
||||
1. Create the `vault-citadel-sa` service account for the Vault CA:
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl create serviceaccount vault-citadel-sa
|
||||
{{< /text >}}
|
||||
|
||||
1. Since the Vault CA requires the authentication and authorization of Kubernetes service accounts,
|
||||
you must edit the `vault-citadel-sa` service account to use the example JWT configured
|
||||
on the testing Vault CA.
|
||||
To learn more about configuring a Vault CA for Kubernetes authentication and authorization,
|
||||
visit the [Vault Kubernetes `auth` method reference documentation](https://www.vaultproject.io/docs/auth/kubernetes.html).
|
||||
The [Integration Kubernetes with Vault - auth](https://evalle.xyz/posts/integration-kubernetes-with-vault-auth/) post includes
|
||||
detailed examples of configuring Vault to authenticate and authorize Kubernetes service accounts.
|
||||
|
||||
{{< text bash >}}
|
||||
$ export SA_SECRET_NAME=$(kubectl get serviceaccount vault-citadel-sa -o=jsonpath='{.secrets[0].name}')
|
||||
$ kubectl patch secret ${SA_SECRET_NAME} -p='{"data":{"token": "ZXlKaGJHY2lPaUpTVXpJMU5pSXNJbXRwWkNJNklpSjkuZXlKcGMzTWlPaUpyZFdKbGNtNWxkR1Z6TDNObGNuWnBZMlZoWTJOdmRXNTBJaXdpYTNWaVpYSnVaWFJsY3k1cGJ5OXpaWEoyYVdObFlXTmpiM1Z1ZEM5dVlXMWxjM0JoWTJVaU9pSmtaV1poZFd4MElpd2lhM1ZpWlhKdVpYUmxjeTVwYnk5elpYSjJhV05sWVdOamIzVnVkQzl6WldOeVpYUXVibUZ0WlNJNkluWmhkV3gwTFdOcGRHRmtaV3d0YzJFdGRHOXJaVzR0TnpSMGQzTWlMQ0pyZFdKbGNtNWxkR1Z6TG1sdkwzTmxjblpwWTJWaFkyTnZkVzUwTDNObGNuWnBZMlV0WVdOamIzVnVkQzV1WVcxbElqb2lkbUYxYkhRdFkybDBZV1JsYkMxellTSXNJbXQxWW1WeWJtVjBaWE11YVc4dmMyVnlkbWxqWldGalkyOTFiblF2YzJWeWRtbGpaUzFoWTJOdmRXNTBMblZwWkNJNklqSmhZekF6WW1FeUxUWTVNVFV0TVRGbE9TMDVOamt3TFRReU1ERXdZVGhoTURFeE5DSXNJbk4xWWlJNkluTjVjM1JsYlRwelpYSjJhV05sWVdOamIzVnVkRHBrWldaaGRXeDBPblpoZFd4MExXTnBkR0ZrWld3dGMyRWlmUS5wWjhTaXlOZU8wcDFwOEhCOW9YdlhPQUkxWENKWktrMndWSFhCc1RTektXeGxWRDlIckhiQWNTYk8yZGxoRnBlQ2drbnQ2ZVp5d3ZoU2haSmgyRjYtaUhQX1lvVVZvQ3FRbXpqUG9CM2MzSm9ZRnBKby05alROMV9tTlJ0WlVjTnZZbC10RGxUbUJsYUtFdm9DNVAyV0dWVUYzQW9Mc0VTNjZ1NEZHOVdsbG1MVjkyTEcxV05xeF9sdGtUMXRhaFN5OVdpSFFneXpQcXd0d0U3MlQxakFHZGdWSW9KeTFsZlNhTGFtX2JvOXJxa1JsZ1NnLWF1OUJBalppREd0bTl0ZjNsd3JjZ2ZieGNjZGxHNGpBc1RGYTJhTnMzZFc0TkxrN21GbldDSmEtaVdqLVRnRnhmOVRXLTlYUEswZzNvWUlRMElkMENJVzJTaUZ4S0dQQWpCLWc="}}'
|
||||
{{< /text >}}
|
||||
|
||||
1. Deploy the `httpbin` and `sleep` backends:
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl apply -f httpbin-injected.yaml
|
||||
$ kubectl apply -f sleep-injected.yaml
|
||||
{{< /text >}}
|
||||
|
||||
## Istio mutual TLS with Vault CA integration
|
||||
|
||||
This section demos the use of mutual TLS with the Vault CA integration. In the previous steps,
|
||||
you enabled mutual TLS for the Istio mesh and the `httpbin` and `sleep` workloads. These workloads receive
|
||||
certificates from a testing Vault CA. When you send a `curl` request from the `sleep` workload
|
||||
to the `httpbin` workload, the request goes through a mutual TLS protected channel constructed
|
||||
with the certificates the Vault CA issued.
|
||||
|
||||
1. Send a `curl` request from the `sleep` workload to the `httpbin` workload.
|
||||
The request succeeds with a `200` response code if it goes through the
|
||||
mutual TLS protected channel constructed with the certificates issued by the Vault CA.
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl exec -it $(kubectl get pod -l app=sleep -o jsonpath='{.items[0].metadata.name}') -c sleep -- curl -s -o /dev/null -w "%{http_code}" httpbin:8000/headers
|
||||
200
|
||||
{{< /text >}}
|
||||
|
||||
1. To verify that not all requests are successful, send a `curl`
|
||||
request from the `sleep` Envoy sidecar to the `httpbin` workload.
|
||||
The request fails because the request from the sidecar to the `httpbin` workload did not use mutual TLS.
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl exec -it $(kubectl get pod -l app=sleep -o jsonpath='{.items[0].metadata.name}') -c istio-proxy -- curl -s -o /dev/null -w "%{http_code}" httpbin:8000/headers
|
||||
000command terminated with exit code 56
|
||||
{{< /text >}}
|
||||
|
||||
**Congratulations!** You successfully integrated a Vault CA with Istio to use mutual TLS
|
||||
between workloads using the certificates the Vault CA issued.
|
||||
|
||||
## Cleanup
|
||||
|
||||
After completing this tutorial, you may delete the testing cluster created
|
||||
at the beginning of this tutorial.
|
||||
|
||||
|
|
@ -74,7 +74,7 @@
|
|||
|
||||
- **Ingress 网关控制器的外部证书管理**：加入一个控制器，用于为外部证书提供动态加载和轮转支持。
|
||||
|
||||
- **自定义 PKI 集成**：加入了 Vault PKI 集成，支持 Vault 保护下的签署密钥以及现存 Vault PKI 的集成能力。[Istio Vault CA 集成](/zh/docs/tasks/security/vault-ca)一节中包含更多详细信息。
|
||||
- **自定义 PKI 集成**：加入了 Vault PKI 集成，支持 Vault 保护下的签署密钥以及现存 Vault PKI 的集成能力。
|
||||
|
||||
- **自定义域（非 `cluster.local`）**：支持组织或者集群特定的域名。
|
||||
|
||||
|
|
|
|||
|
|
@ -1,98 +0,0 @@
|
|||
---
|
||||
title: Istio Vault CA 集成
|
||||
description: 有关如何整合 Vault CA 到 Istio 中颁发证书的教程。
|
||||
weight: 10
|
||||
keywords: [security,certificate]
|
||||
---
|
||||
|
||||
本教程将向您介绍如何在 Istio 中整合 Vault CA 颁发证书的示例。
|
||||
|
||||
## 开始之前{#before-you-begin}
|
||||
|
||||
* 创建一个新的 Kubernetes 集群以运行本教程中的示例。
|
||||
|
||||
## 安装启用 SDS 的 Istio
|
||||
|
||||
1. 使用 [Helm](/docs/setup/install/helm/#prerequisites) 安装 Istio 启用 SDS 和向节点代理发送证书签名请求来测试 Vault CA ：
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl create clusterrolebinding cluster-admin-binding --clusterrole=cluster-admin --user="$(gcloud config get-value core/account)"
|
||||
$ helm dep update --skip-refresh install/kubernetes/helm/istio
|
||||
$ cat install/kubernetes/namespace.yaml > istio-auth.yaml
|
||||
$ cat install/kubernetes/helm/istio-init/files/crd-* >> istio-auth.yaml
|
||||
$ helm template \
|
||||
--name=istio \
|
||||
--namespace=istio-system \
|
||||
--set global.proxy.excludeIPRanges="35.233.249.249/32" \
|
||||
--values install/kubernetes/helm/istio/example-values/values-istio-example-sds-vault.yaml \
|
||||
install/kubernetes/helm/istio >> istio-auth.yaml
|
||||
$ kubectl create -f istio-auth.yaml
|
||||
{{< /text >}}
|
||||
|
||||
本教程中使用的测试 Vault 服务器的 IP 地址为 `35.233.249.249`。配置 `global.proxy.excludeIPRanges ="35.233.249.249/32"` 将测试 Vault 服务器的 IP 地址列入白名单，以便 Envoy 不会拦截从 Node Agent 到 Vault 的流量。
|
||||
|
||||
这个 yaml 文件 [`values-istio-example-sds-vault.yaml`]({{< github_file >}}/install/kubernetes/helm/istio/example-values/values-istio-example-sds-vault.yaml)
|
||||
包含 Istio 中启用 SDS（密钥发现服务）的配置。
|
||||
Vault CA 相关配置设置为环境变量：
|
||||
|
||||
{{< text yaml >}}
|
||||
env:
|
||||
- name: CA_ADDR
|
||||
value: "https://35.233.249.249:8200"
|
||||
- name: CA_PROVIDER
|
||||
value: "VaultCA"
|
||||
- name: "VAULT_ADDR"
|
||||
value: "https://35.233.249.249:8200"
|
||||
- name: "VAULT_AUTH_PATH"
|
||||
value: "auth/kubernetes/login"
|
||||
- name: "VAULT_ROLE"
|
||||
value: "istio-cert"
|
||||
- name: "VAULT_SIGN_CSR_PATH"
|
||||
value: "istio_ca/sign/istio-pki-role"
|
||||
{{< /text >}}
|
||||
|
||||
## 部署测试工作负载{#deploy-a-testing-workload}
|
||||
|
||||
本节部署测试工作负载 `httpbin`。当测试工作负载的 sidecar 通过 SDS 请求证书时，Node Agent 将向 Vault 发送证书签名请求。
|
||||
|
||||
1. 生成示例 `httpbin` 后端的部署：
|
||||
|
||||
{{< text bash >}}
|
||||
$ istioctl kube-inject -f @samples/httpbin/httpbin.yaml@ > httpbin-injected.yaml
|
||||
{{< /text >}}
|
||||
|
||||
1. 部署示例后端：
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl apply -f httpbin-injected.yaml
|
||||
{{< /text >}}
|
||||
|
||||
1. 列出节点代理的 pod：
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl get pod -n istio-system -l app=nodeagent -o jsonpath={.items..metadata.name}
|
||||
{{< /text >}}
|
||||
|
||||
1. 查看每个节点代理的日志。驻留在与测试工作负载相同的节点上的节点代理将包含与 Vault 相关的日志。
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl logs -n istio-system THE-POD-NAME-FROM-PREVIOUS-COMMAND
|
||||
{{< /text >}}
|
||||
|
||||
1. 因为在此示例中，Vault 未配置为从 `httpbin` 工作负载接受 Kubernetes JWT 服务帐户，您应该看到 Vault 使用以下日志拒绝签名请求：
|
||||
|
||||
{{< text plain >}}
|
||||
2019-01-16T19:42:19.274291Z info SDS gRPC server start, listen "/var/run/sds/uds_path"
|
||||
2019-01-16T19:42:22.015814Z error failed to login Vault: Error making API request.
|
||||
URL: PUT https://35.233.249.249:8200/v1/auth/kubernetes/login
|
||||
Code: 500. Errors:
|
||||
* service account name not authorized
|
||||
2019-01-16T19:42:22.016112Z error Failed to sign cert for "default": failed to login Vault at https://35.233.249.249:8200: Error making API request.
|
||||
{{< /text >}}
|
||||
|
||||
1. 生成上述日志后，您已完成本文中的教程，该教程将整合外部 Vault CA 并将证书签名请求路由到 Vault。
|
||||
|
||||
## 清理{#cleanup}
|
||||
|
||||
完成本教程后，您可以删除在本教程开头创建的测试集群。
|
||||
|
||||
Loading…
Reference in New Issue