stackabletech · adwk67 · Nov 30, 2023 · Sep 1, 2023 · Sep 4, 2023 · Sep 25, 2023
diff --git a/modules/ROOT/pages/release-notes.adoc b/modules/ROOT/pages/release-notes.adoc
diff --git a/modules/tutorials/examples/ldap-auth/superset-auth-snippet.yaml b/modules/tutorials/examples/ldap-auth/superset-auth-snippet.yaml
@@ -1,7 +1,8 @@
 ---
 # tag::snippet[]
 spec:
-  authenticationConfig:            # <1>
-    authenticationClass: openldap  # <2>
-    userRegistrationRole: Admin    # <3>
+  clusterConfig:
+    authentication:                    # <1>
+      - authenticationClass: openldap  # <2>
+        userRegistrationRole: Admin    # <3>
 # end::snippet[]
diff --git a/modules/tutorials/examples/ldap-auth/trino-auth-snippet.yaml b/modules/tutorials/examples/ldap-auth/trino-auth-snippet.yaml
@@ -1,8 +1,7 @@
 ---
 # tag::snippet[]
 spec:
-  authentication:
-    method:
-      ldap:                            # <1>
-        authenticationClass: openldap  # <2>
+  clusterConfig:
+    authentication:
+    - authenticationClass: openldap  # <1>
 # end::snippet[]
diff --git a/modules/tutorials/examples/ldap-auth/trino-opa-bundle-snippet.yaml b/modules/tutorials/examples/ldap-auth/trino-opa-bundle-snippet.yaml
@@ -2,12 +2,32 @@ data:
   trino.rego: |
     package trino
 
+    import future.keywords.in
+
     default allow = false
 
     allow {
+      is_alice
+    }
+    extended[i] {
+      some i
+      input.action.filterResources[i]
+      is_alice
+    }
+
+    is_alice() {
       input.context.identity.user == "alice"
     }
 
     allow {
+      is_bob
+    }
+    extended[i] {
+      some i
+      input.action.filterResources[i]
+      is_bob
+    }
+
+    is_bob() {
       input.context.identity.user == "bob"
-    }
+    }
diff --git a/modules/tutorials/examples/verify-signatures/kyverno-policy.yaml b/modules/tutorials/examples/verify-signatures/kyverno-policy.yaml
@@ -16,11 +16,11 @@ spec:
                 - Pod
       verifyImages:
         - imageReferences:
-            - docker.stackable.tech/*-operator:23.7.*
+            - docker.stackable.tech/*
           attestors:
             - entries:
                 - keyless:
                     issuer: "https://token.actions.githubusercontent.com"
-                    subject: "https://github.com/stackabletech/*-operator/.github/workflows/build.yml@refs/tags/23.7.*"
+                    subject: "https://github.com/stackabletech/*/.github/workflows/build.yml@refs/*"
                     rekor:
-                      url: https://rekor.sigstore.dev
+                      url: https://rekor.sigstore.dev
diff --git a/modules/tutorials/pages/authentication_with_openldap.adoc b/modules/tutorials/pages/authentication_with_openldap.adoc
@@ -150,8 +150,8 @@ metadata:
   ...
 spec:
   version: ...
-  statsdExporterVersion: ...
-  credentialsSecret: superset-credentials
+  clusterConfig:
+    credentialsSecret: superset-credentials
   nodes:
     roleGroups:
       default:
@@ -170,7 +170,7 @@ Modify your `superset.yaml` to include this new `authenticationConfig` property
 [source,yaml]
 include::example$ldap-auth/superset-auth-snippet.yaml[tag=snippet]
 
-<1> The new `authenticationConfig` section which configures how Superset is authenticating users
+<1> The new `authentication` section which configures how Superset is authenticating users
 <2> The `authenticationClass` property is referencing the AuthenticationClass `openldap` you created earlier
 <3> The default Superset role that users should be assigned to when they log in. Any user will be an Admin
 
@@ -186,12 +186,11 @@ metadata:
   name: superset
   ...
 spec:
-  version: ...
-  statsdExporterVersion: ...
-  credentialsSecret: superset-credentials
-  authenticationConfig:
-    authenticationClass: openldap
-    userRegistrationRole: Admin
+  clusterConfig:
+    credentialsSecret: superset-credentials
+    authentication:
+      - authenticationClass: openldap
+        userRegistrationRole: Admin
   nodes:
     roleGroups:
       default:
@@ -213,7 +212,7 @@ Connect to superset as before, and try logging in again with username _admin_ an
 
 Trino is configured very similarly to Superset.
 
-Fetch the existing TrinoCluster defintion from the Kubernetes API server and save it into a `trino.yaml` file:
+Fetch the existing TrinoCluster definition from the Kubernetes API server and save it into a `trino.yaml` file:
 
 [source,bash]
 include::example$ldap-auth/60-modify-trino.sh[tag=get-yaml]
@@ -230,16 +229,17 @@ metadata:
   name: trino
   ...
 spec:
-  version: 396-stackable0.1.0
-  authentication:
-    method:
-      multiUser:
+  clusterConfig:
+    authentication:
+    - authenticationClass: trino-users
+    authorization:
+      opa:
+        configMapName: opa
+        package: trino
+    catalogLabelSelector:
+      matchLabels:
+        trino: trino
         ...
-  opa:
-    configMapName: opa
-    package: trino
-  catalogLabelSelector:
-    ...
   workers:
     ...
   coordinators:
@@ -258,8 +258,7 @@ Replace the `multiUser` authentication method in your `trino.yaml` with an `ldap
 [source,yaml]
 include::example$ldap-auth/trino-auth-snippet.yaml[tag=snippet]
 
-<1> The new `ldap` authentication method replaces the previous `multiUser` authentication method
-<2> The `authenticationClass` property is referencing the AuthenticationClass `openldap` you created earlier
+<1> The `authenticationClass` property is referencing the AuthenticationClass `openldap` you created earlier
 
 .Your `trino.yaml` should now look similar to this
 [%collapsible]
@@ -273,15 +272,13 @@ metadata:
   name: trino
   ...
 spec:
-  version: 396-stackable0.1.0
-  authentication:
-    method:
-      ldap:
-        authenticationClass: openldap
-  opa:
-    configMapName: opa
-    package: trino
-  catalogLabelSelector:
+  clusterConfig:
+    authentication:
+    - authenticationClass: openldap
+    authorization:
+      opa:
+        configMapName: opa
+        package: trino
     ...
   workers:
     ...

diff --git a/modules/tutorials/pages/enabling_verification_of_image_signatures.adoc b/modules/tutorials/pages/enabling_verification_of_image_signatures.adoc
@@ -1,8 +1,10 @@
 = Enabling verification of image signatures
 
-Image signing is a security measure that helps ensure the authenticity and integrity of container images. Starting with SDP 23.7, all our operator images are signed https://docs.sigstore.dev/cosign/openid_signing/["keyless"] (signing of product images and Helm charts will follow). By verifying these signatures, cluster administrators can ensure that the operator images pulled from Stackable's container registry are authentic and have not been tampered with.
+Image signing is a security measure that helps ensure the authenticity and integrity of container images. Starting with SDP 23.7, all our images are signed https://docs.sigstore.dev/cosign/openid_signing/["keyless"]. By verifying these signatures, cluster administrators can ensure that the images pulled from Stackable's container registry are authentic and have not been tampered with.
 Since Kubernetes does not have native support for verifying image signatures yet, we will use a tool called https://kyverno.io/[Kyverno] in this tutorial.
 
+IMPORTANT: Releases prior to SDP 23.7 do not have signed images. If you are using an older release and enforce image signature verification, Pods with Stackable images will be prevented from starting.
+
 == Installing Kyverno
 Kyverno can be easily installed via Helm:
 
@@ -17,7 +19,7 @@ Other installation methods and options to run Kyverno in a highly-available fash
 
 == Creating a policy to verify image signatures
 
-Now that Kyverno is installed, we can create a policy that verifies that all operator images that are part of the SDP 23.7 releases are signed by Stackable's CI pipeline (Github Actions):
+Now that Kyverno is installed, we can create a policy that verifies that all images provided by Stackable are signed by Stackable's CI pipeline (Github Actions):
 
 [source,yaml]
 include::example$verify-signatures/kyverno-policy.yaml[]
@@ -28,6 +30,6 @@ Apply this policy to the cluster by saving it as `kyverno-policy.yaml` and runni
 kubectl apply -f kyverno-policy.yaml
 ----
 
-The policy will be applied to all namespaces in the cluster. It checks all newly created Pods that run any image matching the expression `docker.stackable.tech/+++*+++-operator:23.7.+++*+++` (all Stackable operators version 23.7.+++*+++) and ensures that these images have been signed by a Stackable Github Action from the release 23.7 (`https://github.com/stackabletech/+++*+++-operator/.github/workflows/build.yml@refs/tags/23.7.+++*+++`). If the signature of an operator image is invalid or missing, the policy will deny the pod creation.
+The policy will be applied to all namespaces in the cluster. It checks all newly created Pods that run any image matching the expression `docker.stackable.tech/+++*+++` (all images provided by Stackable) and ensures that these images have been signed by a Stackable Github Action (`https://github.com/stackabletech/+++*+++/.github/workflows/build.yml@refs/+++*+++`). If the signature of an image is invalid or missing, the policy will deny the pod creation.
 For a more detailed explanation of the policy options, please refer to the https://kyverno.io/docs/writing-policies/verify-images/sigstore/#keyless-signing-and-verification[Kyverno documentation].
-If the `subject` field in the policy is changed to something like `https://github.com/test/+++*+++`, the policy will deny the creation of operator pods because the signature is no longer valid.
+If the `subject` field in the policy is changed to something like `https://github.com/test/+++*+++`, the policy will deny the creation of pods with Stackable images because the signature is no longer valid.