Intents v2

docs/_common/cluster-setup.md

@@ -132,7 +132,7 @@ managedNodeGroups:
       team: "eks"
 ```
 
-For guides that deploy the larger set of services, Kafka and ZooKeeper are also deployed, and you will also need the EBS CSI driver to accommodate their storage needs. [Follow the AWS guide for the EBS CSI add-on to do so.](https://docs.aws.amazon.com/eks/latest/userguide/managing-ebs-csi.html)
+For guides that deploy the larger set of workloads, Kafka and ZooKeeper are also deployed, and you will also need the EBS CSI driver to accommodate their storage needs. [Follow the AWS guide for the EBS CSI add-on to do so.](https://docs.aws.amazon.com/eks/latest/userguide/managing-ebs-csi.html)
 If you're not using the VPC CNI, you can set up the Calico network policy controller using the following instructions:
 
 <a href="https://docs.aws.amazon.com/eks/latest/userguide/calico.html">Visit the official documentation</a>, or follow the instructions below:

docs/faq/README.mdx

@@ -21,7 +21,7 @@ authenticates, is allowed to perform any requested operation.
 
 There are many variations on authorization and authentication. For example, when Otterize is used with Kubernetes
 network policies, the Otterize intents operator first establishes pod identity using
-[a certain algorithm](/reference/service-identities). To authorize pod-to-pod access, it then creates labels and configures
+[a certain algorithm](/reference/workload-identities). To authorize pod-to-pod access, it then creates labels and configures
 network policies in the Kubernetes cluster such that only client pods that are authorized to access the server pod
 are allowed network access to those servers. At runtime, the authorized client pods can simply send requests
 to the server pods, and unless other enforcement mechanisms are in place, no authentication is needed. (Effectively,
@@ -33,8 +33,9 @@ the labels which Otterize configured Kubernetes to put on the pod serve as a kin
 
 <summary>What is IBAC?</summary>
 
-IBAC is short for intent-based access control, which is **a new paradigm** for configuring service-to-service access
-control based on the client service declaring what server calls (or operations) it intends to make.
+IBAC is short for intent-based access control, which is essentially a declarative approach to access control where each workload declares its intended access, and the system uses that information to automatically configure policies where appropriate.
+
+If you are familiar with the Android or iOS systems of permissions, where the app developer declares the access that the app _needs_, and the system uses that information to prompt the user for permission, you have a good analogy for IBAC. In IBAC, the client declares the access it _needs_, and the system uses that information to grant it after the access is reviewed by the user, then this is a similar concept.
 
 For more information, see the [IBAC documentation page](/overview/intent-based-access-control).
 
@@ -58,10 +59,6 @@ according to client intents that have been applied in a particular context -- sa
 an environment (when using Otterize Cloud). With Otterize Cloud, you can also set rules on how to process intents
 before they're used to configure access controls, or even to set access controls directly.
 
-Otterize also provides an optional server SDK (coming soon) that you can embed in your code as an inline access control.
-It provides a layer of authentication and authorization that can be standalone or can be used in addition to
-other access controls such as network policies, API gateways, or proxies.
-
 </details>
 
 <details>
@@ -76,7 +73,7 @@ Otterize also provides a cloud-based, SaaS offering called Otterize Cloud that i
 paid tiers. More information is available at [otterize.com/product](https://otterize.com/product)
 
 In general, **all** Otterize components that run on the user side ("on prem") are open sourced. These include the Kubernetes operators
-and the network mapper that are part of Otterize OSS, as well as the Otterize CLI, the Otterize SDK (coming soon), and components
+and the network mapper that are part of Otterize OSS, as well as the Otterize CLI, and components
 to integrate with your infrastructure, e.g. for integrating with Kafka outside of Kubernetes.
 
 </details>
@@ -117,11 +114,9 @@ topics from clients not having an ACL on it. In that case, intents not only enab
 
 But there may well be cases in which access should still require some other approval before it's granted. For example,
 intents might automatically turn into access only in certain environments, or only for certain services, while others
-require approval or some other check. For such cases, Otterize Cloud (coming soon) provides automation rules that
-intermediate between application of intents and granting of access. Even within Otterize OSS, platform teams can
-manage when access is granted by managing when `kubectl apply` executes within a CI/CD pipeline.
+require approval or some other check. You can achieve this by using [Kyverno validation policies](/reference/validating-clientintents) or the native [Kubernetes ValidatingAdmissionPolicies](https://kubernetes.io/docs/reference/access-authn-authz/validating-admission-policy/) available since v1.30.
 
-For more information on IBAC and security, see the [security documentation](/security).
+Otterize Cloud will also soon support native approval flows for intents, so that you can approve or reject intents -- either manually or through a set of rules, before they're used to affect actual access.
 
 </details>
 

docs/features/aws-iam/index.mdx

@@ -6,6 +6,8 @@ hide_title: true
 ---
 
 import DocsLinkCard from "@site/src/components/LinkCard";
+import Tabs from "@theme/Tabs";
+import TabItem from "@theme/TabItem";
 
 export const tutorials = [
     {
@@ -36,24 +38,25 @@ To learn how to use the Intents Operator and Credentials Operator to manage just
 1. First, the EKS cluster must have [Otterize installed](/overview/installation).
 2. To have a role created for a pod, label the pod with `credentials-operator.otterize.com/create-aws-role: "true"`
 3. The credentials operator will create a role and an `AssumeRolePolicy` (trust relationship) bound to the pod's ServiceAccount. The ServiceAccount will be annotated automatically.
-4. At this point, the pod is able to assume the role, but role does not have the ability to perform any actions. We will need to create a ClientIntents YAML for the access the service requires and apply it to our cluster. Below is an example of a ClientIntents file for accessing an S3 bucket. View the [reference](/features/aws-iam/reference) to learn more about the AWS IAM ClientIntents syntax.
-5. Once the intent is applied, the intents operator will create a new policy, which will be attached to the service’s role with the appropriate access.
+4. At this point, the pod is able to assume the role, but role does not have the ability to perform any actions. We will need to create a ClientIntents YAML for the access the workload requires and apply it to our cluster. Below is an example of a ClientIntents file for accessing an S3 bucket. View the [reference](/features/aws-iam/reference) to learn more about the AWS IAM ClientIntents syntax.
+5. Once the intent is applied, the intents operator will create a new policy, which will be attached to the workload’s role with the appropriate access.
 6. Done!
 
 ```yaml
-apiVersion: k8s.otterize.com/v1alpha3
+apiVersion: k8s.otterize.com/v2alpha1
 kind: ClientIntents
 metadata:
   name: server
 spec:
-  service:
+  workload:
     name: server
-  calls:
-    - name: arn:aws:s3:::example-bucket-*/*
-      type: aws
-      awsActions:
-        - "s3:PutObject"
-        - "s3:GetObject"
+    kind: Deployment
+  targets:
+    - aws:
+        arn: arn:aws:s3:::example-bucket-*/*
+        actions:
+          - "s3:PutObject"
+          - "s3:GetObject"
 ```
 
 ### Automatically generating ClientIntents for AWS IAM

docs/features/aws-iam/reference.mdx

@@ -5,49 +5,51 @@ title: Reference
 
 ### ClientIntents example (YAML)
 
+
 ```yaml
-apiVersion: k8s.otterize.com/v1alpha3
+apiVersion: k8s.otterize.com/v2alpha1
 kind: ClientIntents
 metadata:
   name: server
 spec:
-  service:
-    # The name of the pod that will be granted access
+  workload:
+    # The name & kind of the workload that will be granted access
     name: server
-  calls:
-      # The AWS ARN or ARN wildcard that references the resource(s) for the authorization
-    - name: arn:aws:s3:::example-bucket-*/*
-      type: aws
-      # one or more AWS Actions or Action wildcards that will be provided to the specified resources
-      awsActions:
-        - "s3:PutObject"
-        - "s3:GetObject"
+    kind: Deployment
+  targets:
+    - aws:
+        # The AWS ARN or ARN wildcard that references the resource(s) for the authorization
+        arn: arn:aws:s3:::example-bucket-*/*
+        # one or more AWS Actions or Action wildcards that will be provided to the specified resources
+        actions:
+          - "s3:PutObject"
+          - "s3:GetObject"
     # Multiple call definitions can be defined for a single service.
-    - name: arn:aws:s3:::read-only-bucket-*/*
-      type: aws
-      awsActions:
-        - "s3:GetObject"
+    - aws:
+        arn: arn:aws:s3:::read-only-bucket-*/*
+        actions:
+          - "s3:GetObject"
 ```
 
 Otterize supports templating AWS resource names by AWS region & account ID.
 The templates `$(AWS_REGION)` & `$(AWS_ACCOUNT_ID)` in AWS resource ARNs will be automatically replaced with the EKS cluster's region & account ID:
 
 ```yaml
-apiVersion: k8s.otterize.com/v1alpha3
+apiVersion: k8s.otterize.com/v2alpha1
 kind: ClientIntents
 metadata:
   name: server
 spec:
-  service:
+  workload:
     name: server
-  calls:
-    # $(AWS_REGION) & $(AWS_ACCOUNT_ID) will be replaced with the EKS cluster's region & account ID
-    - name: arn:aws:sqs:$(AWS_REGION):$(AWS_ACCOUNT_ID):queue1
-      type: aws
-      awsActions:
-        - "sqs:*"
+    kind: Deployment
+  targets:
+    - aws:
+        # $(AWS_REGION) & $(AWS_ACCOUNT_ID) will be replaced with the EKS cluster's region & account ID
+        arn: arn:aws:sqs:$(AWS_REGION):$(AWS_ACCOUNT_ID):queue1
+        actions:
+          - "sqs:*"
 ```
-
 ### Annotations
 
 | Key                                                        | Description                                                                                                                                                                                  | Default  |

docs/features/azure-iam/index.mdx

@@ -32,39 +32,40 @@ To learn how to use the Intents Operator and Credentials Operator to manage just
 2. To have a workload identity created for a pod, label the pod with `credentials-operator.otterize.com/create-azure-workload-identity: "true"`
 3. The credentials operator will create an Azure workload identity and federated identity credential bound to the pod's ServiceAccount. The ServiceAccount will be annotated automatically.
 4. At this point, the pod is able to assume the identity, but it does not have the permissions to perform any actions.
-We will need to create a ClientIntents YAML for the access the service requires and apply it to our cluster.
+We will need to create a ClientIntents YAML for the access the workload requires and apply it to our cluster.
 Below is an example of a ClientIntents file for accessing an Azure Storage Blobs bucket.
 View the [reference](/features/azure-iam/reference) to learn more about the Azure IAM ClientIntents syntax.
 5. Once the intent is applied, the intents operator will create a new role assignment, which will be attached to the workload identity with the appropriate access.
 6. Done!
 
 ```yaml
-apiVersion: k8s.otterize.com/v1alpha3
+apiVersion: k8s.otterize.com/v2alpha1
 kind: ClientIntents
 metadata:
   name: client
   namespace: otterize-tutorial-azure-iam
 spec:
-  service:
+  workload:
     name: client
-  calls:
-    - name: "/providers/Microsoft.Storage/storageAccounts/otterizetutorialazureiam/blobServices/default/containers/test"
-      type: azure
-      azureRoles:
-        - "Storage Blob Data Contributor"
-    - name: "/providers/Microsoft.KeyVault/vaults/otterizetutorialazureiamkeyvault"
-      type: azure
-      # Optional - Grant Azure Key Vault data plane access by using Key Vault access policy
-      azureKeyVaultPolicy:
-        certificatePermissions:
-          - "all"
-        keyPermissions:
-          - "all"
-        secretPermissions:
-          - "all"
-        storagePermissions:
-          - "get"
-          - "list"
+    kind: Deployment
+  targets:
+    - azure:
+        scope: "/providers/Microsoft.Storage/storageAccounts/otterizetutorialazureiam/blobServices/default/containers/test"
+        roles:
+          - "Storage Blob Data Contributor"
+    - azure:
+        scope: "/providers/Microsoft.KeyVault/vaults/otterizetutorialazureiamkeyvault"
+        # Optional - Grant Azure Key Vault data plane access by using Key Vault access policy
+        keyVaultPolicy:
+          certificatePermissions:
+            - "all"
+          keyPermissions:
+            - "all"
+          secretPermissions:
+            - "all"
+          storagePermissions:
+            - "get"
+            - "list"
 ```
 
 ### Automatically generating ClientIntents for Azure IAM

docs/features/azure-iam/reference.mdx

@@ -6,41 +6,43 @@ title: Reference
 ### ClientIntents example (YAML)
 
 ```yaml
-apiVersion: k8s.otterize.com/v1alpha3
+apiVersion: k8s.otterize.com/v2alpha1
 kind: ClientIntents
 metadata:
   # The name of the pod that will be granted access
   name: client
 spec:
-  service:
+  workload:
     name: client
-  calls:
+    kind: Deployment
+  targets:
     # The Azure resource ID that references the resource(s) for the authorization. Subscription & resource group are automatically appended.
-    - name: "/providers/Microsoft.Storage/storageAccounts/otterizeazureiamtutorial/blobServices/default/containers/otterizeazureiamtutorialcontainer1"
-      type: azure
-      # one or more Azure roles that will be provided to the specified resources
-      azureRoles:
-        - "Storage Blob Data Contributor"
-    - name: "/providers/Microsoft.Storage/storageAccounts/otterizeazureiamtutorial/blobServices/default/containers/otterizeazureiamtutorialcontainer2"
-      # one or more Azure actions that can be performed on the specified resources (cannot be used with azureRoles)
-      azureActions:
-        - "Microsoft.Storage/storageAccounts/blobServices/containers/read"
-      # one or more Azure data actions that can be performed on the specified resources (cannot be used with azureRoles)
-      azureDataActions:
-        - "Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read"
-    - name: "/providers/Microsoft.KeyVault/vaults/otterizetutorialazureiamkeyvault"
-      type: azure
-      # Optional - Grant Azure Key Vault data plane access by using Key Vault access policy
-      azureKeyVaultPolicy:
-        certificatePermissions:
-          - "all"
-        keyPermissions:
-          - "all"
-        secretPermissions:
-          - "all"
-        storagePermissions:
-          - "get"
-          - "list"
+    - azure:
+        scope: "/providers/Microsoft.Storage/storageAccounts/otterizeazureiamtutorial/blobServices/default/containers/otterizeazureiamtutorialcontainer"
+        # one or more Azure roles that will be provided to the specified resources
+        roles:
+          - "Storage Blob Data Contributor"
+    - azure:
+        scope: "/providers/Microsoft.Storage/storageAccounts/otterizeazureiamtutorial/blobServices/default/containers/otterizeazureiamtutorialcontainer2"
+        # one or more Azure actions that can be performed on the specified resources (cannot be used with azureRoles)
+        actions:
+          - "Microsoft.Storage/storageAccounts/blobServices/containers/read"
+        # one or more Azure data actions that can be performed on the specified resources (cannot be used with azureRoles)
+        dataActions:
+          - "Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read"
+    - azure:
+        scope: "/providers/Microsoft.KeyVault/vaults/otterizetutorialazureiamkeyvault"
+        # Optional - Grant Azure Key Vault data plane access by using Key Vault access policy
+        keyVaultPolicy:
+          certificatePermissions:
+            - "all"
+          keyPermissions:
+            - "all"
+          secretPermissions:
+            - "all"
+          storagePermissions:
+            - "get"
+            - "list"
 ```
 
 ### Annotations

docs/features/gcp-iam/index.mdx

@@ -36,24 +36,24 @@ To learn how to use the Intents Operator and Credentials Operator to manage just
 3. The credentials operator will:
    - Annotate the pod ServiceAccount and Namespace with the relevant workload identity and Otterize labels.
    - Create a GCP ServiceAccount and bind it to the pod ServiceAccount.
-4. At this point, the pod is connected to your GCP project through the newly created GCP ServiceAccount but does not have any permissions to perform any action. We will need to create a ClientIntents YAML for the access the service requires and apply it to our cluster. Below is an example of a ClientIntents file for accessing a GCS bucket. View the [reference](/features/gcp-iam/reference) to learn more about the GCP IAM ClientIntents syntax.
-5. Once the intent is applied, the intents operator will create a new GCP IAM policy, which will be attached to the service’s role with the appropriate access.
+4. At this point, the pod is connected to your GCP project through the newly created GCP ServiceAccount but does not have any permissions to perform any action. We will need to create a ClientIntents YAML for the access the workload requires and apply it to our cluster. Below is an example of a ClientIntents file for accessing a GCS bucket. View the [reference](/features/gcp-iam/reference) to learn more about the GCP IAM ClientIntents syntax.
+5. Once the intent is applied, the intents operator will create a new GCP IAM policy, which will be attached to the workload’s role with the appropriate access.
 6. Done!
 
 ```yaml
-apiVersion: k8s.otterize.com/v1alpha3
+apiVersion: k8s.otterize.com/v2alpha1
 kind: ClientIntents
 metadata:
   name: server
   namespace: my-namespace
 spec:
-  service:
+  workload:
     name: server
-  calls:
-    - name: projects/_/buckets/otterize-demo-bucket*
-      type: gcp
-      gcpPermissions:
-        - "storage.admin"
+  targets:
+    - gcp:
+        resource: projects/_/buckets/otterize-demo-bucket*
+        permissions:
+          - "storage.admin"
 ```
 
 ### Automatically generating ClientIntents for GCP IAM

docs/features/gcp-iam/reference.mdx

@@ -6,27 +6,28 @@ title: Reference
 ### ClientIntents example (YAML)
 
 ```yaml
-apiVersion: k8s.otterize.com/v1alpha3
+apiVersion: k8s.otterize.com/v2alpha1
 kind: ClientIntents
 metadata:
   name: server
 spec:
-  service:
+  workload:
     # The name of the pod that will be granted access
     name: server
-  calls:
+    kind: Deployment
+  targets:
       # The GCP resource name as defined in the linked documentation below
       # Wildcards can be used in the end of the resource name to match multiple and nested resources
-    - name: projects/_/buckets/otterize-demo-bucket*
-      type: gcp
-      # one or more GCP Roles that will be provided to the specified resources
-      gcpPermissions:
-        - "storage.admin"
-      # Multiple call definitions can be defined for a single service.
-	- name: projects/_/buckets/otterize-read-only-bucket*
-      type: gcp
-      gcpPermissions:
-        - "storage.objectViewer"
+    - gcp:
+        resource: projects/_/buckets/otterize-demo-bucket*
+        # one or more GCP Roles that will be provided to the specified resources
+        permissions:
+          - "storage.admin"
+    # Multiple call definitions can be defined for a single service.
+    - gcp:
+        resource: projects/_/buckets/otterize-read-only-bucket*
+        permissions:
+          - "storage.objectViewer"
 ```
 
 ### GCP documentation references