From baf3c2f4bcce04217b4024d751e70ef117704e2a Mon Sep 17 00:00:00 2001 From: Ori Shoshan Date: Sun, 20 Aug 2023 15:47:20 +0300 Subject: [PATCH 1/3] Update shadow mode docs to explain how ProtectedService works with Istio and Kafka --- docs/shadow-vs-active-enforcement/README.mdx | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/docs/shadow-vs-active-enforcement/README.mdx b/docs/shadow-vs-active-enforcement/README.mdx index 9516757e7..0c3e80b52 100644 --- a/docs/shadow-vs-active-enforcement/README.mdx +++ b/docs/shadow-vs-active-enforcement/README.mdx @@ -56,9 +56,11 @@ To unlock these insights, the Otterize OSS components (the intents operator, the ## Protected services -To override the default non-enforcing shadow mode for a service, enforcing access controls for it, and in fact protecting it with a default-deny against unauthorized access, you simply create a `ProtectedService` resource. +To override the default non-enforcing shadow mode for a service, when the operator is in `defaultShadow` mode, enforcing access controls for it, you simply create a `ProtectedService` resource. -*Currently, this is only supported for network policies. Support for Kafka ACLs and Istio policies is coming shortly.* +For network policies, this also creates a default-deny policy and protects the service. +For Istio, no default-deny policy is created, the setting enables enforcement, causing Istio authorization policies to be created when ClientIntents resources are created. +For Kafka, no default-deny policy or equivalent is created, the setting enables enforcement, causing Kafka ACLs to be created, when either ClientIntents or KafkaServerConfig resources are created. First, you would want to make sure all the intents of all this service's clients are declared, so Otterize enables their access while protecting the service. One easy way to do that, if you have a cluster where those clients are making their expected calls, is to build a network map with the Otterize network mapper, and export just this service's clients' intents: From 102ba21854d2119aa705efc361ce39457dde9486 Mon Sep 17 00:00:00 2001 From: Uri Sarid Date: Wed, 23 Aug 2023 19:00:59 -0700 Subject: [PATCH 2/3] Update README.mdx Language tweaks. --- docs/shadow-vs-active-enforcement/README.mdx | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/shadow-vs-active-enforcement/README.mdx b/docs/shadow-vs-active-enforcement/README.mdx index 0c3e80b52..6140b579e 100644 --- a/docs/shadow-vs-active-enforcement/README.mdx +++ b/docs/shadow-vs-active-enforcement/README.mdx @@ -59,8 +59,8 @@ To unlock these insights, the Otterize OSS components (the intents operator, the To override the default non-enforcing shadow mode for a service, when the operator is in `defaultShadow` mode, enforcing access controls for it, you simply create a `ProtectedService` resource. For network policies, this also creates a default-deny policy and protects the service. -For Istio, no default-deny policy is created, the setting enables enforcement, causing Istio authorization policies to be created when ClientIntents resources are created. -For Kafka, no default-deny policy or equivalent is created, the setting enables enforcement, causing Kafka ACLs to be created, when either ClientIntents or KafkaServerConfig resources are created. +For Istio, no default-deny policy is created, so this just enables enforcement: Istio authorization policies are created for this service when ClientIntents resources are created. +For Kafka, no default-deny policy or equivalent is created, so this just enables enforcement: Kafka ACLs are created when either ClientIntents or KafkaServerConfig resources are created. First, you would want to make sure all the intents of all this service's clients are declared, so Otterize enables their access while protecting the service. One easy way to do that, if you have a cluster where those clients are making their expected calls, is to build a network map with the Otterize network mapper, and export just this service's clients' intents: From e365519fe75b9299458127198ffa0e5cf90624a1 Mon Sep 17 00:00:00 2001 From: Uri Sarid Date: Wed, 23 Aug 2023 19:03:36 -0700 Subject: [PATCH 3/3] Update README.mdx More language tweaks. --- docs/shadow-vs-active-enforcement/README.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/shadow-vs-active-enforcement/README.mdx b/docs/shadow-vs-active-enforcement/README.mdx index 6140b579e..19107ce28 100644 --- a/docs/shadow-vs-active-enforcement/README.mdx +++ b/docs/shadow-vs-active-enforcement/README.mdx @@ -56,7 +56,7 @@ To unlock these insights, the Otterize OSS components (the intents operator, the ## Protected services -To override the default non-enforcing shadow mode for a service, when the operator is in `defaultShadow` mode, enforcing access controls for it, you simply create a `ProtectedService` resource. +When the operator is in `defaultShadow` mode, to override the default non-enforcing shadow mode for a service and enforce access controls for it, you simply create a `ProtectedService` resource. For network policies, this also creates a default-deny policy and protects the service. For Istio, no default-deny policy is created, so this just enables enforcement: Istio authorization policies are created for this service when ClientIntents resources are created.