istio
/
istio.io
mirror of https://github.com/istio/istio.io.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Best-Practices: Remove reference to Citadel. (#7398) 

Citadel is no longer a standalone component of Istio by default.  Also,
this method won't work properly if istiod is using self-signed
certificates, so remove the warning entirely.
This commit is contained in:
Justin Pettit 2020-05-26 12:15:19 -07:00 committed by GitHub
parent 23a4f5df4a
commit f27566cc16
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 4 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
content/en/docs/ops/best-practices/security/index.md
View File

@ -15,12 +15,6 @@ deploying different services in a medium- or large-size cluster, we recommend cr
For example, you can create a `team1-ns` namespace for `team1`, and `team2-ns` namespace for `team2`, such
that both teams cannot access each other's services.
{{< warning >}}
If Citadel is compromised, all its managed keys and certificates in the cluster may be exposed.
We **strongly** recommend running Citadel in a dedicated namespace (for example, `istio-citadel-ns`), to restrict access to
the cluster to only administrators.
{{< /warning >}}
Let us consider a three-tier application with three services: `photo-frontend`,
`photo-backend`, and `datastore`. The photo SRE team manages the
`photo-frontend` and `photo-backend` services while the datastore SRE team
@ -28,8 +22,8 @@ manages the `datastore` service. The `photo-frontend` service can access
`photo-backend`, and the `photo-backend` service can access `datastore`.
However, the `photo-frontend` service cannot access `datastore`.
In this scenario, a cluster administrator creates three namespaces:
`istio-citadel-ns`, `photo-ns`, and `datastore-ns`. The administrator has
In this scenario, a cluster administrator creates two namespaces:
`photo-ns` and `datastore-ns`. The administrator has
access to all namespaces and each team only has access to its own namespace.
The photo SRE team creates two service accounts to run `photo-frontend` and
`photo-backend` respectively in the `photo-ns` namespace. The datastore SRE

10
content/pt-br/docs/ops/best-practices/security/index.md
View File

@ -15,12 +15,6 @@ deploying different services in a medium- or large-size cluster, we recommend cr
For example, you can create a `team1-ns` namespace for `team1`, and `team2-ns` namespace for `team2`, such
that both teams cannot access each other's services.
{{< warning >}}
If Citadel is compromised, all its managed keys and certificates in the cluster may be exposed.
We **strongly** recommend running Citadel in a dedicated namespace (for example, `istio-citadel-ns`), to restrict access to
the cluster to only administrators.
{{< /warning >}}
Let us consider a three-tier application with three services: `photo-frontend`,
`photo-backend`, and `datastore`. The photo SRE team manages the
`photo-frontend` and `photo-backend` services while the datastore SRE team
@ -28,8 +22,8 @@ manages the `datastore` service. The `photo-frontend` service can access
`photo-backend`, and the `photo-backend` service can access `datastore`.
However, the `photo-frontend` service cannot access `datastore`.
In this scenario, a cluster administrator creates three namespaces:
`istio-citadel-ns`, `photo-ns`, and `datastore-ns`. The administrator has
In this scenario, a cluster administrator creates two namespaces:
`photo-ns` and `datastore-ns`. The administrator has
access to all namespaces and each team only has access to its own namespace.
The photo SRE team creates two service accounts to run `photo-frontend` and
`photo-backend` respectively in the `photo-ns` namespace. The datastore SRE