Configure

In this part, you will:

• Create an IAM Role for Service Accounts (IRSA) so that pods have the necessary permissions to write to the OpenSearch domain
• Create the necessary role in OpenSearch granting permissions to write cluster logs to the appropriate indices
• Apply the newly created blueprint to the EKS cluster

---

Step 1: IRSA

In this step, you will create an IRSA so that pods on the EKS cluster will have the necessary permissions to access your AWS OpenSearch service. In AWS, it is a recommended best practice to use IAM roles for service accounts (IRSA) to access AWS services outside the EKS cluster because of the following benefits:

Benefit	Description
Least Privilege	No longer need to provide extended permissions to the node IAM role so that pods on that node can call AWS APIs. You can scope IAM permissions to a service account, and only pods that use that service account have access to those permissions. This feature also eliminates the need for third-party solutions such as kiam or kube2iam.
Credential Isolation	A container can only retrieve credentials for the IAM role that is associated with the service account to which it belongs. A container never has access to credentials that are intended for another container that belongs to another pod.
Auditability	Access and event logging is available through CloudTrail to help ensure retrospective auditing.

---

Create IRSA

To create the IRSA we will define a policy that will allow access to our OpenSearch domain.

• We will use the following policy which we will supply during the IAM Service Account creation
• Enter the Resource ARN for your OpenSearch domain

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "es:ESHttp*"
            ],
            "Resource": "arn:aws:es:us-west-2:123456789:domain/rafay-logging",
            "Effect": "Allow"
        }
    ]
}

Create IAM Service Account

• Click on Infrastructure -> Clusters
• Click on the cluster tile we will be adding the IRSA to
• Click on the "IAM Service Accounts" tab
• Click on "NEW IAM SERVICE ACCOUNT"
• Enter the name of the service account we defined in the values file such as "opensearch-logging", select the namespace "logging", and supply the policy above. Policies can be supplied as an ARN if created previously, uploaded as an IAM Inline Policy Document, or supplied as input
• Copy the above policy as an IAM Inline Policy Document
• Select "SAVE"

---

Verify IRSA

Creation of the IRSA can take a few minutes. You can verify the status of the IRSA by doing the following:

• Click on the "IAM Service Accounts" tab for the cluster

You can also verify that the k8s service account was created in the EKS cluster in the logging namespace.

• Click on the Zero Trust Kubectl Shell on the web console for the cluster where the IRSA was created and run the following kubectl command

kubectl get sa -n logging opensearch-logging

NAME                        SECRETS   AGE
opensearch-logging          1         2m29s

kubectl describe sa -n logging opensearch-logging
Name:                opensearch-logging
Namespace:           logging
Labels:              app.kubernetes.io/managed-by=eksctl
Annotations:         eks.amazonaws.com/role-arn: arn:aws:iam::123456789:role/rafay-docs-eks-clusters-addon-iamserviceacco-Role1-1JQK5EEX0KIE4
Image pull secrets:  <none>
Mountable secrets:   opensearch-logging-token-xpqbt
Tokens:              opensearch-logging-token-xpqbt
Events:              <none>

As you can see in this example, the "opensearch-logging" service account was successfully created in the "logging" namespace.

Important

• Note the ARN defined in the Annotations, we will use this in the next step

---

Step 2: Mapping Roles to Users in OpenSearch

Backend roles allow you to map roles to users. Backend roles can be IAM roles or arbitrary strings that you can specify. We will add the ARN for the IRSA we created in Step 1 to a custom role. This custom role will grant us the necessary permissions to interact with the OpenSearch domain based on least restrictive access.

• Login to OpenSearch and go to Security -> Roles
• Click on "Create role" and give it a name
• Under Index permissions enter "fluent-bit*"
• For Index permissions select "write", "indices:data/write/update", and "read"
• For Tenant permissions select "global_tenant"
• Select "Create"

• Select the "Mapped users" tab and click on "Manage mapping"
• Add the user we are currently utilizing to login
• Add the ARN of the IRSA to the Backend role for the "fluentbit-logging" role

• Click on "Map"

OpenSearch is now configured with the appropriate permissions for the fluentbit pods to write to the indices.

---

Step 3: Apply Blueprint

Now, we are ready to apply the newly created custom blueprint to our EKS cluster.

• Select Infrastructure -> Clusters
• Click on the gear icon on the far right of the EKS cluster
• Update blueprint and select the new blueprint and version

In a few minutes, all the k8s resources matching the custom cluster blueprint will become operational on the cluster.

Notice that the cluster's blueprint name and version match what you created in the prior step.

Next Steps

You are now ready to move on to the next part of the recipe where you will verify cluster logs are being streamed to your OpenSearch instance.

---