Add AWS IAM on EKS tutorial

docs/intent-based-access-control/README.mdx

@@ -3,30 +3,17 @@ sidebar_position: 7
 title: 'IBAC: Intent-based access control'
 ---
 
-At Otterize, we believe service-to-service access control should become not only *easy* but actually *transparent* to service developers. We believe that access should not only be self-serve — that it should happen without needing to go through any extra steps beyond what developers are already doing. And we believe that access control enforcement should be completely decoupled from the functional development of the software: that as the organization improves its security and compliance posture, developers should not need to revisit their working code.
+At Otterize, we believe workload IAM should become not only *easy* but actually *transparent* to  developers. We believe that access should not only be self-serve — that it should happen without needing to go through any extra steps beyond what developers are already doing. And we believe that access control enforcement should be completely decoupled from the functional development of the software: that as the organization improves its security and compliance posture, developers should not need to revisit their working code.
 
-These are the principles of **intent-based access control (IBAC)**, a modern, declarative approach to granting access automatically, responsibly, and scalably. **The developer simply declares, in a *client intents file* alongside their code, what other services the code intends to call.** If the code passes review, so does its intents file, and access is granted automatically to make those calls, regardless of the type of call, the target infrastructure and location, and the enforcement mechanism. Credentials for declared access are automatically managed and supplied to the developer for use in their code, if needed. Any undeclared access is automatically blocked.
+These are the principles of **intent-based access control (IBAC)**, a modern, declarative approach to granting access automatically, responsibly, and scalably. **The developer simply declares, in a `ClientIntents` custom resource alongside their code, what other services the code intends to call.** If the code passes review, so does its intents, and access is granted automatically to make those calls, regardless of the type of call, the target infrastructure and location, and the enforcement mechanism. Credentials for declared access are automatically managed and supplied to the service for use in their code, if needed. Any undeclared access is automatically blocked.
 
 Here is an example of the client intents file for the `checkoutservice`.
 It declares that it will call the `emailservice`, the `orderservice`, and the `ecomm-events` Kafka service.
-It also provides more granular information for some of the calls:
-```yaml
-{@include: ../../static/resources/example-intents.yaml}
-```
-
-<details>
-<summary>Intents file as a Kubernetes resource file</summary>
-<div>
-
-Here is the same intents file, now formatted as a Kubernetes custom resource file,
-so it can be applied directly via `kubectl apply`:
-
+It also provides more granular information for some of the calls, which you can optionally specify, like `HTTPResources`:
 ```yaml
 {@include: ../../static/resources/example-intents-resource.yaml}
 ```
 
-</div>
-</details>
 
 Intent-based access control realizes shift-left for access control. The necessary access is defined by the developer themselves declaring, when the code is created, what calls will be made. Nobody knows better than them what their code needs. And those declarations, living in source control as client intents files along with the code, stay in sync with the code — as opposed to access permissions that live elsewhere, e.g. on a server, where they’re likely to get stale rapidly. Intents are approved along with the code: if it makes sense to approve the code that makes the calls, it should make sense to approve access to what’s being called.
 
@@ -72,8 +59,7 @@ To implement IBAC across heterogeneous environments, IBAC must also solve for th
 
 ### IBAC and security
 
-Security controls that don't get implemented don't help. By building service-to-service access
-control concerns into the building of the software &mdash; capturing the intent at design time,
+Security controls that don't get implemented don't help. By shifting-left the access controls - &mdash; capturing the intent at design time,
 *streamlining* for developers the access to secured services, integrating access reviews into existing
 code review processes, and automating access control configuration at deploy time &mdash; IBAC drives adoption
 of security controls and a zero-trust architecture within the engineering team.
@@ -86,7 +72,7 @@ It captures and makes explicit the *intents* of developers and their the code,
 enables processes for acting on those intents to allow or deny access,
 and makes explicit the enforcement that's actually put in place.
 One org might decide that it's best to automatically approve all intents once they undergo code review and apply
-them to a staging environment so they can be tested, but require explicit secops approval on any new intent before
+them to a staging environment so they can be tested, but require explicit SecOps approval on any new intent before
 it's applied to production. Another org might decide to require approvals only on some servers (i.e. intents targeted
 at those servers), and to track them by filing issues against the server teams' ticketing system.
 And a third org might decide to enforce access controls on certain servers in staging to make sure intents are declared,

docs/quickstart/access-control/aws-eks-cni-mini.mdx

@@ -51,9 +51,9 @@ addons:
   - name: kube-proxy
 
 managedNodeGroups:
-  - name: x86-al2-on-demand
+  - name: small-on-demand
     amiFamily: AmazonLinux2
-    instanceTypes: [ "m6i.xlarge", "m6a.xlarge" ]
+    instanceTypes: [ "t3.large" ]
     minSize: 0
     desiredCapacity: 2
     maxSize: 6
@@ -66,7 +66,7 @@ managedNodeGroups:
       team: "eks"
 ```
 
-Then run the following command to create your AWS cluster:
+Then run the following command to create your AWS cluster. [Don't have eksctl? Install it now.](https://eksctl.io/installation/)
 
 ```shell
 eksctl create cluster -f cluster-config.yaml