Forem: sent2020

AWS deployment from GitHub Actions with OIDC

sent2020 — Sun, 16 Oct 2022 16:49:45 +0000

GitHub Actions is a continuous integration and continuous delivery (CI/CD) platform that allows you to automate your build, test, and deployment pipeline. Until AWS provided supported for OIDC, access and secret keys were used to make deployments in the Github Actions.

Configuring OpenID Connect in AWS and role creation

Create Github as an identity provider in AWS provider with the below values.

Provider URL as https://token.actions.githubusercontent.com
Audience as sts.amazonaws.com

Configure the role with the below trust policy. Replace GitHub org repo details with the details of your organization. Replace AWS account id also

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::123456123456:oidc-provider/token.actions.githubusercontent.com"
            },
            "Action": "sts:AssumeRoleWithWebIdentity",
            "Condition": {
                "StringLike": {
                    "token.actions.githubusercontent.com:sub": "repo:git-org/git-repo:*"
                },
                "ForAllValues:StringEquals": {
                    "token.actions.githubusercontent.com:iss": "https://token.actions.githubusercontent.com",
                    "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
                }
            }
        }
    ]
}

Policy for the role can be assigned based on the action which is performed on the AWS account. S3 permissions is assigned for demo purpose.

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "s3:ListBucket",
    "Resource": "*"
  }
}

GitHub Actions workflow

Below permissions needs to be added in the GitHub yaml for use in GitHub Actions

permissions:
  id-token: write # required to use OIDC authentication
  contents: read # This is required for actions/checkout@v2

Below is the Github Actions file which will list buckets in an AWS account and also list in the another account using cross account access

In the step Assume execution role cross account access is achieved by assuming the previous role as environmental variables.

name: Hello from AWS
on:
  push:
permissions:
  id-token: write
  contents: read
jobs:
  greeting:
    runs-on: ubuntu-latest
    steps:
    - name: Configure AWS credentials
      uses: aws-actions/configure-aws-credentials@v1
      with:
        aws-region: us-east-1
        role-to-assume: arn:aws:iam::123456789:role/github-actions
    - name: Print assumed role
      run: aws sts get-caller-identity
    - name: s3 list 
      run: aws s3 ls
    - name: Assume execution role
      uses: aws-actions/configure-aws-credentials@v1
      with:
        aws-access-key-id: ${{ env.AWS_ACCESS_KEY_ID }}
        aws-region: us-east-1
        aws-secret-access-key: ${{ env.AWS_SECRET_ACCESS_KEY }}
        aws-session-token: ${{ env.AWS_SESSION_TOKEN }}
        role-duration-seconds: 3000
        role-skip-session-tagging: true
        role-to-assume: arn:aws:iam::123456789:role/github-cross-role
    - name: Print assumed role
      run: aws sts get-caller-identity
    - name: s3 list 
      run: aws s3 ls

Reference workflow can be found in the repo https://github.com/sent2020/aws-oidc

Crossplane on Amazon EKS with IRSA

sent2020 — Sat, 15 Oct 2022 17:36:50 +0000

In this post we are going to setup Crossplane on AWS EKS Cluster with IRSA and provision the AWS Cloud Services.

IRSA is leveraged to launch the AWS Cloud Services

Amazon EKS

Amazon EKS is a managed Kubernetes service to run Kubernetes in the AWS cloud

Crossplane

Crossplane is a framework for building cloud native control planes without needing to write code.

https://github.com/crossplane/crossplane

## Launch EKS Cluster with IRSA for Crossplane
Leverage EKSCTL to launch the EKS Cluster using the below configuration, provided yaml leverages existing VPC to launch the Cluster. Substitute subnet ids before creating the cluster.

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: crossplane-demo
  region: us-east-1
  version: '1.21'
vpc:
  subnets:
    private:
      us-east-1a: { id: subnet-1234}
      us-east-1b: { id: subnet-1234}
  clusterEndpoints:
    publicAccess:  true
iam:
  withOIDC: true
  serviceAccounts:
  - metadata:
      name: provider-aws-f78664a342f1
      namespace: crossplane-system
    attachPolicyARNs:
    - "arn:aws:iam::aws:policy/AdministratorAccess"
managedNodeGroups:
  - name: crossplane-nodegroup
    labels: { role: workers }
    instanceType: t3a.medium
    desiredCapacity: 1
    volumeSize: 30
    privateNetworking: true

Save the above contents in cluster.yaml and use the below command to create the cluster

eksctl create cluster -f cluster.yaml

Install Crossplane

Install the Crossplane using the helm chart by using the below commands

kubectl create namespace crossplane-system

helm repo add crossplane-stable https://charts.crossplane.io/stable
helm repo update

helm install crossplane --namespace crossplane-system crossplane-stable/crossplane

Install Crossplane AWS provider

Provider contains the CRDs to launch the AWS Cloud Services. Apply the below configuration yamls to install the provider. Replace AWS_PROVIDER_ARN with the ARN of the role created during cluster creation

apiVersion: pkg.crossplane.io/v1alpha1
kind: ControllerConfig
metadata:
  name: aws-config
  annotations:
    eks.amazonaws.com/role-arn: <AWS_PROVIDER_ARN>
spec:
  podSecurityContext:
    fsGroup: 2000
---
apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
  name: provider-aws
spec:s
  package: crossplane/provider-aws:v0.24.1
  controllerConfigRef:
    name: aws-config

Apply the below config which will allow Crossplane to use the IRSA role for launching the AWS Cloud Services.

apiVersion: aws.crossplane.io/v1beta1
kind: ProviderConfig
metadata:
  name: aws-provider
spec:
  credentials:
    source: InjectedIdentity

Create a S3 bucket using Crossplane

Apply the below yaml to test Crossplane setup with IRSA. Once this yaml is applied a S3 bucket will be created in the name s3-demo.

apiVersion: s3.aws.crossplane.io/v1beta1
kind: Bucket
metadata:
  name: s3-demo
spec:
  deletionPolicy: Delete
  forProvider:
    acl: private
    locationConstraint: us-east-1
    serverSideEncryptionConfiguration:
      rules:
        - applyServerSideEncryptionByDefault:
            sseAlgorithm: AES256
    versioningConfiguration:
      status: Enabled
  providerConfigRef:
    name: aws-provider

Notes:

In the EKS Cluster creation Admin policy is used for service account. This policy can be restricted to the particular service like S3, SQS based on the services created through Crossplane.

EKS Security Best Practices

sent2020 — Fri, 15 Oct 2021 17:22:41 +0000

In this blog we are going to see the security best practices for EKS cluster related to IRSA roles and service account tokens.

Restrict IRSA Trust policy to Service Account Name Scope and Don't use *.

Sample Trust policy for the IRSA role.

{ "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::CI_ACCOUNT_ID:oidc-provider/OIDC_PROVIDER" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "<OIDC_PROVIDER>:sub": "system:serviceaccount:<namespace>:<serviceaccount>" } } }] }

Assume a demo namespace has two IRSA roles create with trust policy system:serviceaccount:demo:*

IAM Role 1 - ServiceAccount01 - access to S3
IAM Role 2 - ServiceAccount02 - access to S3 and DynamoDB

Pod1 with ServiceAccount01 can access Role 2 just by exporting the AWS_ROLE_ARN = <ARN OF IAM ROLE 2> so that it will get access to S3 and DynamoDB .

Enable IRSA role for aws-node daemonset.

EKS supports IRSA roles for the aws-node daemonset, it is security best practice to use IRSA role instead of system node role.

Disable auto-mounting of service account tokens

Update the pod spec with automountServiceAccountToken=false attribute if there is no need for the application to access EKS Control plane API.