diff --git a/content/en/docs/ops/best-practices/security/index.md b/content/en/docs/ops/best-practices/security/index.md index d37edc1ac0..89d9b8fa87 100644 --- a/content/en/docs/ops/best-practices/security/index.md +++ b/content/en/docs/ops/best-practices/security/index.md @@ -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 diff --git a/content/pt-br/docs/ops/best-practices/security/index.md b/content/pt-br/docs/ops/best-practices/security/index.md index 7179969fbd..6eb46a2685 100644 --- a/content/pt-br/docs/ops/best-practices/security/index.md +++ b/content/pt-br/docs/ops/best-practices/security/index.md @@ -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