DEV Community: Arpan

Reusable AWS iam role for service-accounts (IRSA for k8s ) terraform module

Arpan — Sat, 19 Feb 2022 06:23:54 +0000

AWS supports authenticating your pods using an identity provider that your account is configured to trust.

This tutorial will guide you through the process of creating an IAM role that your kubernetes pods will be able to assume.

Pre-requisites:

Familiarity with oidc provider in AWS
Have an oidc provider setup in AWS
Have a kubernetes cluster running in AWS (of course!)

Creating oidc provider for AWS is beyond the scope of this tutorial.

Now that that's out of the way,
Let's start with some terraform variables:

#variables.tf

# this is the url of the oidc_issuer
variable "oidc_issuer" {
  default = "oidc-example-irsa.s3.ap-southeast-2.amazonaws.com/subdomain.example.com"
}
# role arn of the oidc provider
variable "oidc_arn" {
  default = "arn:aws:iam:01234567898:oidc-provider/oidc-example-irsa.s3.ap-southeast-2.amazonaws.com/subdomain.example.com"
}

variable "cluster_name" {
  default = "cluster.example.com"
}

# service account variables
variable "service_accounts" {
  default = [
    {
      name = "blabladefault",
      namespace = "blablans"
      statements = [
        {
          Action   = ["*:*"]
          Effect   = "Deny"
          Resource = "*"
        }
      ]
    }
  ]
}

I've prefilled all defaults here because we're going to rely on these defaults. You can also set them to null and pass your variables separately.

Next, we'll need a resource block for the iam role.

#main.tf
resource "aws_iam_role" "service_accounts" {
  for_each = {for service_account in (var.service_accounts) : service_account.name => service_account }
    name = "${each.value.name}.${each.value.namespace}.sa.${var.cluster_name}"

    #allow federated role assumption using webIdentity(oidc)
    assume_role_policy = jsonencode({
      Version = "2012-10-17"
      Statement = [
        {
          Action = "sts:AssumeRoleWithWebIdentity",
          Condition = {
            StringEquals = {
                "${var.oidc_issuer}:sub" = "system:serviceaccount:${each.value.namespace}:${each.value.name}"
            }
          }
          Effect = "Allow"
          Principal = {
            Federated = "${var.oidc_arn}"
          }
        },
      ]
    })

    #generate multiple inline_policy resources 
    dynamic "inline_policy" {
      for_each = "${each.value.statements}"
      content {
        name = "policy-${inline_policy.key}"
        policy = jsonencode({
          Version = "2012-10-17"
          Statement = [{
            Action = inline_policy.value.Action
            Effect = inline_policy.value.Effect
            Resource = inline_policy.value.Resource
          }]
        })
      }
    }

  tags = {
    tag-key = "tag-value"
  }
}

What's happening here?

We're using terraform's for_each meta argument to create multiple iam roles. The resource aws_iam_role.service_accounts is thus a list of iam roles.

We're then using terraform's dynamic block to create multiple inline_policy resources within each iam role.

Using a dynamic block inside a for_each argument allows us to render nested configurations like above.

The beauty of this type of configuration is that you can reuse this as much as you'd like.

Let's see an example,

I've updated the variables.tf to add one more service account to the service_accounts variable:

#variables.tf
# ...
# ...
# [updated] service account variables with two service-accounts
variable "service_accounts" {
  default = [
    {
      name = "blabladefault",
      namespace = "blablans"
      statements = [
        {
          Action   = ["*:*"]
          Effect   = "Deny"
          Resource = "*"
        }
      ]
    },
    {
      name = "blabladefault2",
      namespace = "blablans2"
      statements = [
        {
          Action   = ["*:*"]
          Effect   = "Deny"
          Resource = "*"
        }
      ]
    }
  ]
}

Let's run terraform plan on this configuration.

We see that it's now creating two service accounts:

Terraform will perform the following actions:

  # aws_iam_role.service_accounts["blabladefault"] will be created
  + resource "aws_iam_role" "service_accounts" {
      + arn                   = (known after apply)
      + assume_role_policy    = jsonencode(
            {
              + Statement = [
                  + {
                      + Action    = "sts:AssumeRoleWithWebIdentity"
                      + Condition = {
                          + StringEquals = {
                              + oidc-example-irsa.s3.ap-southeast-2.amazonaws.com/subdomain.example.com:sub = "system:serviceaccount:blablans:blabladefault"
                            }
                        }
                      + Effect    = "Allow"
                      + Principal = {
                          + Federated = "arn:aws:iam:01234567898:oidc-provider/oidc-example-irsa.s3.ap-southeast-2.amazonaws.com/subdomain.example.com"
                        }
                    },
                ]
              + Version   = "2012-10-17"
            }
        )
      + create_date           = (known after apply)
      + force_detach_policies = false
      + id                    = (known after apply)
      + managed_policy_arns   = (known after apply)
      + max_session_duration  = 3600
      + name                  = "blabladefault.blablans.sa.cluster.example.com"
      + name_prefix           = (known after apply)
      + path                  = "/"
      + tags                  = {
          + "tag-key" = "tag-value"
        }
      + tags_all              = {
          + "tag-key" = "tag-value"
        }
      + unique_id             = (known after apply)

      + inline_policy {
          + name   = "policy-0"
          + policy = jsonencode(
                {
                  + Statement = [
                      + {
                          + Action   = [
                              + "*:*",
                            ]
                          + Effect   = "Deny"
                          + Resource = "*"
                        },
                    ]
                  + Version   = "2012-10-17"
                }
            )
        }
    }

  # aws_iam_role.service_accounts["blabladefault2"] will be created
  + resource "aws_iam_role" "service_accounts" {
      + arn                   = (known after apply)
      + assume_role_policy    = jsonencode(
            {
              + Statement = [
                  + {
                      + Action    = "sts:AssumeRoleWithWebIdentity"
                      + Condition = {
                          + StringEquals = {
                              + oidc-example-irsa.s3.ap-southeast-2.amazonaws.com/subdomain.example.com:sub = "system:serviceaccount:blablans2:blabladefault2"
                            }
                        }
                      + Effect    = "Allow"
                      + Principal = {
                          + Federated = "arn:aws:iam:01234567898:oidc-provider/oidc-example-irsa.s3.ap-southeast-2.amazonaws.com/subdomain.example.com"
                        }
                    },
                ]
              + Version   = "2012-10-17"
            }
        )
      + create_date           = (known after apply)
      + force_detach_policies = false
      + id                    = (known after apply)
      + managed_policy_arns   = (known after apply)
      + max_session_duration  = 3600
      + name                  = "blabladefault2.blablans2.sa.cluster.example.com"
      + name_prefix           = (known after apply)
      + path                  = "/"
      + tags                  = {
          + "tag-key" = "tag-value"
        }
      + tags_all              = {
          + "tag-key" = "tag-value"
        }
      + unique_id             = (known after apply)

      + inline_policy {
          + name   = "policy-0"
          + policy = jsonencode(
                {
                  + Statement = [
                      + {
                          + Action   = [
                              + "*:*",
                            ]
                          + Effect   = "Deny"
                          + Resource = "*"
                        },
                    ]
                  + Version   = "2012-10-17"
                }
            )
        }
    }

Plan: 2 to add, 0 to change, 0 to destroy.

This plan was generated from the example above. If it doesn't work for you, please leave a comment and I'll try and help you out.

Using 'dynamic' block to generate IAM policy statements in Terraform

Arpan — Thu, 27 Jan 2022 14:01:17 +0000

Terraform has a cool resource block called the 'dynamic' block that allows generating multiple nested blocks for a resource.

This tutorial will show you how to generate multiple IAM policy statements using this dynamic block.

In this example we have a list of AWS Principals that we want to allow access to our bucket named dev-to-multi-account-bucket.

# variables.tf
variable "aws_accounts" {
  type        = map(list(string))
  description = "A map of lists of AWS Principals"
  default     = {
    "mgmt" = ["arn:aws:iam::123456789876:root"]
    "prod" = ["arn:aws:iam::098765432123:root"]
  }
}

# bucket_policy.tf
resource "aws_s3_bucket_policy" "cross_account_policy" {
    bucket = "dev-to-multi-account-bucket"
    policy = data.aws_iam_policy_document.allow_access_from_another_account.json
}

# dynamic policy statement block for each account specified
data "aws_iam_policy_document" "allow_access_from_another_account" {
    dynamic "statement" {
        for_each = var.aws_accounts
        content {
            actions   = ["s3:*"]
            resources = [
                "arn:aws:s3:::dev-to-multi-account-bucket/${statement.key}*",
                ]
            principals {
                type = "AWS"
                identifiers = "${flatten(statement.value)}"
            } 
        }
    }
}

Explaination

So what's really happening here? Let's look at the aws_iam_policy_document.allow_access_from_another_account "data" resource block.

We are leveraging the dynamic block within this resource to iterate through the aws_accounts variable. This generates multiple statements inside the policy allowing us to rely on the variable's length.

The variable statement has two important attributes: key and value. These allow you to target the respective section of the key-value map.

We can access these attributes through the statement variable. Terraform automatically assigns this variable name from the dynamic block's configuration. In this case, it's named statement.

After running terraform plan, we see a plan that looks something like this:

  # aws_s3_bucket_policy.cross_account_policy will be created
  + resource "aws_s3_bucket_policy" "cross_account_policy" {
      + bucket = "dev-to-multi-account-bucket"
      + id     = (known after apply)
      + policy = jsonencode(
            {
              + Statement = [
                  + {
                      + Action    = "s3:*"
                      + Effect    = "Allow"
                      + Principal = {
                          + AWS = "arn:aws:iam::123456789876:root"
                        }
                      + Resource  = [
                          + "arn:aws:s3:::dev-to-multi-account-bucket/mgmt*",
                        ]
                      + Sid       = ""
                    },
                  + {
                      + Action    = "s3:*"
                      + Effect    = "Allow"
                      + Principal = {
                          + AWS = "arn:aws:iam::098765432123:root"
                        }
                      + Resource  = [
                          + "arn:aws:s3:::dev-to-multi-account-bucket/prod*",
                        ]
                      + Sid       = ""
                    },
                ]
              + Version   = "2012-10-17"
            }
        )
    }

Nice!

Find more about dynamic blocks in Terraform's official documentation page.

My take on GitHub co-pilot's Terraform skills

Arpan — Thu, 20 Jan 2022 13:42:39 +0000

Introduction

So after a long wait in the waiting list, I've finally been able to get my hands on GitHub's co-pilot.

If you're not familiar with co-pilot, check it out here.

It's been a couple of weeks since copilot's been setup on my VSCode and I must say, this looks really promising!

Since working with Terraform is part of my day job, I was curious to see how it would perform as my co-pilot declaring resources through it on my personal device. So this article focuses on its Terraform prowess.

Terraform and Co-pilot

It was impressive to see the bot recognise my coding style and immediately infer what I was trying to do. However, it didn't fully understand my intentions until I was a little further into the code.

The gif below shows copilot trying to guess what I'm trying to do:

Below is where it truly shines by making meaningful suggestions to my output resource.

While not mind-blowing, it can save time by suggesting something you would either type yourself anyway of copy from somewhere else.

Here's another example; I added some extra variables to the module to test whether co-pilot would detect those and try to suggest them as outputs. To (or not, at this stage) my surprise, it did!

What about Makefiles?
My quick test with a go-project makefile seems shows fruitful results.The co-pilot made a great suggestion for a makefile target to release the binary with version and platform suffixes! Well done co-pilot ;)

Final thoughts

Is co-pilot more than just a copy-paste bot? Well, I think so. It's impressive that it understands and makes mostly good suggestions for Terraform, I can imagine how good it would be for other more widely available languages on GitHub.