Update README.md

Author: iru

use_cases/org-k8s/README.md

@@ -17,7 +17,7 @@
 
 ## Suggested building-blocks
 
-1. **Compliance setup** on Sysdig backend and AWS Accounts
+### 1. **Compliance setup** on Sysdig backend and AWS Accounts
 
 On each member-account where compliance wants to be checked, we need to provide a role for Sysdig to be able to impersonate and
 perform `SecurityAudit` tasks.
@@ -35,7 +35,7 @@ Perform the following steps.
 and using the values gathered in previous step.
 <br/><br/>
 
-2. Prepare **EKS SysdigComputeRole**
+### 2. Prepare **EKS SysdigComputeRole**
 
 In further steps, we will deploy Sysdig compute workload inside an EKS cluster.
 We are going to need a `SysdigComputeRole`, to configure some permissions to be able to fetch the required data.
@@ -45,7 +45,7 @@ QuickTest Notes:
 - If your EKS cluster has no specific authentication setup, you can get the `eks_nodes` role generated by default in EKS.
 
 <br/><br/>
-3. **Cloudtrail SQS**
+### 3. **Cloudtrail SQS**
 
 In order to ingest cloudtrail events we will need a queue endpoint.
 Access your cloudtrail and activate SNS notification if it's not already available.
@@ -74,7 +74,7 @@ Use following snipped if required
 <br/><br/>
 
 
-4. **Cloudtrail-S3 Account AssumeRole**
+### 4. **Cloudtrail-S3 Account AssumeRole**
 
 This step is required when Cloudtrail-S3 bucket is stored in a different account than the cluster where we will deploy Sysdig workload.
 We will need to create a role to assume from our workload, due to cross-account S3 restrictions.
@@ -119,7 +119,7 @@ Now we will need to perform same **permissions setup on the S3 bucket**. Add fol
 <br/><br/>
 
 
-5. **Sysdig Compute** Workload deployment in **K8s**
+### 5. **Sysdig Compute** Workload deployment in **K8s**
 
 First let's review permission schema.
 ![permission schema](./diagram.png)