​
Introduction

This document provides detailed instructions on setting up IAM roles for the microservices in the Raven platform. It covers both AWS IAM Roles for Service Accounts (IRSA) and GCP Workload Identity Federation, explaining how to assign IAM roles to Kubernetes service accounts using Helm charts. Additionally, it lists the necessary permissions for each microservice.

​
Cloud Provider IAM Integration

​
AWS IAM Roles for Service Accounts (IRSA)

IRSA enables your Kubernetes pods to interact with AWS services using IAM roles. This eliminates the need to manage AWS credentials within pods, enhancing security and simplifying the management of permissions.

​
How IRSA Works

  1. IAM Role Creation: Create an IAM role with a trust policy that allows the Kubernetes service account to assume the role.
  2. Service Account Annotation: Annotate the Kubernetes service account with the IAM role ARN.
  3. IAM Policy Attachment: Attach the necessary IAM policies to the IAM role to grant the required permissions.

​
Setting Up IRSA in Helm Charts

To set the service account roles in your Helm chart, you need to annotate the service account with the appropriate IAM role ARN. Here’s an example of how to do this: 
serviceAccount:
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::<AWS_ACCOUNT_ID>:role/role-name
Replace <AWS_ACCOUNT_ID> with your actual AWS account ID.

​
GCP Workload Identity Federation

Workload Identity Federation allows your Kubernetes pods to authenticate to Google Cloud Platform services using GCP service accounts. This provides a secure way to access GCP resources without managing service account keys.

​
How Workload Identity Works

  1. Service Account Creation: Create a GCP service account with the necessary permissions.
  2. Service Account Binding: Bind the GCP service account to the Kubernetes service account.
  3. IAM Policy Attachment: Attach the necessary IAM policies to the GCP service account to grant the required permissions.

​
Setting Up Workload Identity in Helm Charts

To set up Workload Identity in your Helm chart, you need to annotate the Kubernetes service account with the GCP service account email. Here’s an example of how to do this: 
serviceAccount:
  annotations:
    iam.gke.io/gcp-service-account: <GCP_SERVICE_ACCOUNT_EMAIL>
Replace <GCP_SERVICE_ACCOUNT_EMAIL> with your actual GCP service account email.

​
Required Permissions for Microservices

​
upload-service

The upload-service requires read/write access to the storage buckets. Below are the IAM policies for both cloud providers:

​
AWS IAM Policy

{
  "Statement": [
    {
      "Action": [
        "s3:*",
        "s3-object-lambda:*"
      ],
      "Effect": "Allow",
      "Resource": [
        "arn:aws:s3:::my-platform-nodes-data/*",
        "arn:aws:s3:::my-platform-nodes-data",
        "arn:aws:s3:::my-platform-symbols/*",
        "arn:aws:s3:::my-platform-symbols"
      ],
      "Sid": ""
    },
    {
      "Action": [
        "s3:ListAllMyBuckets",
        "s3:ListAccessPoints",
        "s3:GetBucketPublicAccessBlock",
        "s3:GetBucketPolicyStatus",
        "s3:GetBucketAcl",
        "s3:GetAccountPublicAccessBlock"
      ],
      "Effect": "Allow",
      "Resource": "*",
      "Sid": "S3ConsoleAccess"
    }
  ],
  "Version": "2012-10-17"
}

​
GCP IAM Policy

roles:
  - roles/storage.objectViewer
  - roles/storage.objectCreator
  - roles/storage.objectAdmin

​
ingestion-service

The ingestion-service also requires read/write access to the storage buckets. Below are the IAM policies for both cloud providers:

​
AWS IAM Policy

{
  "Statement": [
    {
      "Action": [
        "s3:*",
        "s3-object-lambda:*"
      ],
      "Effect": "Allow",
      "Resource": [
        "arn:aws:s3:::my-platform-nodes-data/*",
        "arn:aws:s3:::my-platform-nodes-data",
        "arn:aws:s3:::my-platform-symbols/*",
        "arn:aws:s3:::my-platform-symbols"
      ],
      "Sid": ""
    },
    {
      "Action": [
        "s3:ListAllMyBuckets",
        "s3:ListAccessPoints",
        "s3:GetBucketPublicAccessBlock",
        "s3:GetBucketPolicyStatus",
        "s3:GetBucketAcl",
        "s3:GetAccountPublicAccessBlock"
      ],
      "Effect": "Allow",
      "Resource": "*",
      "Sid": "S3ConsoleAccess"
    }
  ],
  "Version": "2012-10-17"
}

​
GCP IAM Policy

roles:
  - roles/storage.objectViewer
  - roles/storage.objectCreator
  - roles/storage.objectAdmin

​
Applying IAM Roles in Helm

Ensure you have created the IAM roles/service accounts with the above policies and have the role ARNs/service account emails. You can then set up your Helm chart as follows:

​
Example Helm Values File (values.yaml)

For AWS: 
upload-service:
  serviceAccount:
    annotations:
      eks.amazonaws.com/role-arn: arn:aws:iam::<AWS_ACCOUNT_ID>:role/upload-service-role

ingestion-service:
  serviceAccount:
    annotations:
      eks.amazonaws.com/role-arn: arn:aws:iam::<AWS_ACCOUNT_ID>:role/ingestion-service-role
For GCP: 
upload-service:
  serviceAccount:
    annotations:
      iam.gke.io/gcp-service-account: upload-service@<GCP_PROJECT_ID>.iam.gserviceaccount.com

ingestion-service:
  serviceAccount:
    annotations:
      iam.gke.io/gcp-service-account: ingestion-service@<GCP_PROJECT_ID>.iam.gserviceaccount.com
Replace <AWS_ACCOUNT_ID>, <GCP_PROJECT_ID>, and the role/service account names with your actual values.

​
Conclusion

Setting up IAM roles/service accounts allows your microservices to securely interact with cloud services without managing credentials within the pods. By annotating your service accounts with the correct IAM role ARNs or GCP service account emails and ensuring the roles have the required permissions, you can effectively manage access control for your microservices. For further assistance, refer to the Raven Documentation or contact support.