Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: analogous AuthorizationPolicies to NetworkPolicies for (Istio) multi-cluster access #342

Merged
merged 7 commits into from
Oct 28, 2024

Conversation

schahal
Copy link
Contributor

@schahal schahal commented Oct 25, 2024

What this change does

In essence:

  • If service has Istio enabled, adds AuthorizationPolicy that is analogous to the existing NetworkPolicy that we already create (this should be a no-op).
  • If service also enables .Values.network.multiCluster.allowFromRemote .Values.network.allowAll, we open up the NetworkPolicy to allow the AuthorizationPolicies above to take over its enforcement wholly.

Why

To enable services in a multi-primary (Istio mesh), mult-cluster setup to be accessed from services in a different cluster (because NetworkPolicies can't enforce Ingress from outside the Kubernetes cluster without getting to CIDR ranges - i.e., it only knows about cluster-local namespaces. So, we allow all and instead restrict with Istio's AuthorizationPolicy)

@schahal schahal requested a review from a team as a code owner October 25, 2024 23:52
charts/nd-common/templates/_authorizationpolicy.tpl Outdated Show resolved Hide resolved
charts/nd-common/templates/_authorizationpolicy.tpl Outdated Show resolved Hide resolved
charts/nd-common/templates/_networkpolicy.tpl Outdated Show resolved Hide resolved
charts/nd-common/templates/_networkpolicy.tpl Outdated Show resolved Hide resolved
@schahal schahal requested a review from diranged October 28, 2024 19:56
Copy link
Contributor

@diranged diranged left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a few notes on bumping the versions up.. thats it!

@schahal schahal requested a review from diranged October 28, 2024 23:26
@schahal schahal merged commit cd25ae5 into main Oct 28, 2024
2 checks passed
@schahal schahal deleted the feat/multi-cluster-comms branch October 28, 2024 23:37
schahal added a commit that referenced this pull request Oct 30, 2024
#344)

Ref: #342

## Motivation

We have an `AuthorizationPolicy` where users can set allowedNamespaces.
However, it's easy to miss the namespace of the ingress gateway that
users may want their VirtualService tied to.

## What This Does

This parses the namespace of the istio gateways that users provide and
~creates a new list by appending it to the allowedNamespaces-provided
list~ adds a separate rule for it

This is a safe assumption due to our checks of its format:
https://github.com/Nextdoor/k8s-charts/blob/ca85ca6dedd25eb979e4f3f8240bd53cc424fa45/charts/simple-app/templates/istio/virtualservice.yaml#L19

## Test

Updated set `network.allowAll` and `virtualService.enabled` in
values.local.yaml to `true...

Resulting relevant diff of `make template`:

### First Commit

```diff
--- /tmp/simple-app-orig.yaml	2024-10-29 19:55:03
+++ /tmp/simple-app-new.yaml	2024-10-29 19:57:33
...
@@ -424,7 +424,7 @@
 metadata:
   name: simple-app
   labels:
-    helm.sh/chart: simple-app-1.12.1
+    helm.sh/chart: simple-app-1.12.2
     app.kubernetes.io/version: "latest"
     app.kubernetes.io/managed-by: Helm
     tags.datadoghq.com/service: "simple-app"
@@ -466,6 +466,7 @@
         namespaces:
         - foo
         - bar
+        - istio-gateways
     to:
     - operation:
         ports:
...
```

### Updated Commit

```diff
...
@@ -471,6 +471,15 @@
         ports:
         - "80"
         - "8443"
+  - from:
+    - source:
+        namespaces:
+        - "istio-gateways"
+    to:
+    - operation:
+        ports:
+        - "80"
+        - "8443"
 ---
...
```
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants