DEV Community: Lays Rodrigues

How to create a temporary token for your GitHub Actions pipeline to deploy into AWS

Lays Rodrigues — Fri, 30 Jun 2023 21:41:20 +0000

TLDR;
Terraform Gist

Most often that I would like to admit, I learn to do a thing, and I do that thing in that way for the rest of my life. I don’t search for better ways to do it.

Until yesterday, my way to deploy to AWS was to create IAM users and save the access and secret key as environment secrets and go in that way.

The major issue for me with that process is that I don’t rotate the secrets as I should to protect my application and infrastructure. And this is clearly a security issue, even using IAM policies to get the minimum access configuration right.

A couple of days ago, I was trying to deploy an app to AWS App Runner and using ECR as the source for the service. So, I needed a GitHub Actions pipeline to build and push the image to my private ECR, where App Runner could use it.

And, while reading the docs (what was the last time that you have done this? properly hahaha) of the configure aws credentials action, I noticed that there are 5 ways to authenticate in AWS and the recommended one is using temporary tokens and OIDC:

And I’ve got curious about how to use the recommended path for authentication.

With OIDC and an Assume Role, I can generate temporary tokens that only live for one hour to make everything that I require in AWS.

The next step was to read GitHub and AWS docs and translate that into Terraform code. The step by step using the AWS console are in the mentioned docs, so from here I’ll show to you how I translated those 10 steps into a couple terraform files.

GitHub OIDC AWS auth with Terraform

I’m going to set up a locals with some variables to help us out with this process:

In the screenshot (I’ll put a gist with all this code in the end), I set up the github_oidc_domain with the URL from GitHub token provider as shown in the GitHub docs.

The next step is to create and register GitHub as an Identity Provider on AWS with this code:

To configure this resource, we need to fill 3 variables: the URL from the OIDC that we get from the locals, the client id that is the AWS Security Token Service and the thumbprint.

The next step now is to create the IAM role and the Assume Role configuration, so this role can properly authenticate in AWS when used in our pipeline:

Now I’ll update the locals to have the URL from my GitHub repository to authenticate:

As always, I’ll use my good old friend the data resource from terraform the aws_iam_policy_document:

Now in there are plenty of things to uncouple:

The Principal to assume the role is the ARN of the OpenID connect that we created in the previous step;
- The action is to AssumeRoleWithWebIdentity, that allows the STS service to issue the temporary tokens that we need;
- We have two sets of conditions:
  - The first ensures that the audience is the STS service
  - The second ensures that the subjectsub is the GitHub repository that is trying to push the image to ECR.
    - This one is a little tricky to configure to specific GitHub tags, branches, etc. The configuration that I have made only allows the authentication from pipelines triggered by releases and tags. Check these docs to see how you can build your URL.

Presently, that it’s just a policy that needs to be created and attached somewhere, let’s create the IAM Role and attach that:

Now we have our OIDC configuration, and the IAM Role configured. Now we should only configure our Action in our GitHub pipeline, right? Wrong. What we did so far only allows the authentication, but the IAM Role does not have permission to use the ECR service. Let’s fix that:

Now we attach this policy to our IAM Role:

Now we can run our traditional terraform plan and apply and we are ready to go.

Configuring our pipeline

For the GitHub Actions pipeline, we have the following configuration:

Note that when configuring the configure-aws-credentials action that I don’t pass the Access and Secret key, I just pass the ARN of the IAM Role (as a secret in my pipeline) that was created and attached to the OIDC in our previous section. In the next step, it authenticates to ECR and then builds and pushes the image to ECR with double tagging.

And now we are done. But a question remains:

How can I do that for multiple repositories? It isn’t possible to create an OIDC for each of them (because they are unique). And I can’t add many repositories in the IAM Role because that breaks the minimum responsibility for the Role. Apparently, the solution is to create an IAM Role for each repository and attach the OIDC as the principal. But does that create a security issue?

That question already has an answer thanks to Ana Cunha <3 from AWS:

Regarding the security issue question, it seems that by scoping the IAM Role's audience to your GitHub account/repo/branch combination, you are guaranteeing that workflows in a different GitHub account/repo/branch won't be able to assume that role, even if they use the same OIDC identity provider.

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-idp_oidc.html#idp_oidc_Create_GitHub

https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#defining-trust-conditions-on-cloud-roles-using-oidc-claims

Please let me know in the comments what you think.

Check the full code here :)

That’s all folks!

AWS Networking 101

Lays Rodrigues — Wed, 28 Dec 2022 16:04:44 +0000

Last week I gave a training to my team about AWS Networking. And I realized that this training would be perfect for a post here. So, grab your coffee and let’s start it.

Agenda

Reviewing the Basics

    IP's – How do we define a network

    CIDR

    Private and Public networks

AWS

    VPC

    Subnets

    Routing Table

    Internet Gateway

    Elastic IP

    Nat Gateway

    Security Groups and ACL’s

Reviewing the basics

IP’s - How do we define a network

An IP (Internet Protocol) is an internet address that we attach to a resource. Quoting a definition by NordVPN:

Your internet service provider assigns a numeric label, called the Internet Protocol (IP) address, to identify your device among billions of others. In a way, an IP address functions as an online home address because devices use IPs to find and communicate with each other.

There are two formal definitions for an IP: IPv4 and IPv6.

IPv4 is the most common format that you will find around, and you may already see it in the format of 192.168.0.1 on your house network, for example. An IPv4 is defined by a set of 32 bits divided in 4 groups of 8 bits each.

The second format is IPv6, that was created to complement (or substitute) the IPv4 because the latest was reaching its limit in the available addresses that could be used. It is defined by a set of 64 bits, divided in 8 groups of 4 hexadecimals digits: 2804:3d28:12:4438:5ecd:5bff:febc:b862

CIDR → Classless Inter-Domain Routing

A CIDR goes hand by hand with IP’s. A CIDR number defines the size and the addresses available in a network. With the following screenshot, we can see that this network has a mask of /16 where it translates to the network mask. The network mask defines how many bits of the IPv4 address will be frozen and also defines the size of the network.

We can see that a /16 mask, gives the number of 65,536 IPs to be used in the network.

The network mask can go in a range of /8 to /32, where /16 or /24 or /28 can be the most common values used in private networks. You can play with CIDR definition at this website.

Public and Private Networks

A Public Network is reachable by any user on the internet. An example is the github.com website:

A Private Network is a restricted access network most commonly used for house and enterprise networks. Here is an example on how I connect to a VPN using the Pritunl service:

The “Server Address” is a public address that I connect to jump to the private network defined in the “Client Address”, where now I’m able to access my private resources through it.

Let’s build our AWS Network?

What is a VPC?

A VPC represents your private network inside AWS. It’s totally isolated and nobody can access it besides (Except with the use of VPC Peering.) your account.

In AWS, we can define a VPC’s using a CIDR’s number with a network mask between /16 to /28. It is suggested that you create your VPC using the most known private CIDR’s that are:

The network mask is up to you.

Subnets

A Subnet is a subnetwork inside your VPC and is defined by another CIDR, with a different network mask. In other words, we divide the addresses available in the VPC in groups that we call subnets.

Let’s take a small detour and talk about :

Regions and Availability Zones

A Region in AWS is defined by a state where AWS provides its services, for example:

us-east-1 represents the state of Virginia in the US
sa-east-1 represents the state of São Paulo in Brazil

An Availability Zones is the redundancy that AWS provides in different datacenters in the same state, for example:

us-east-1 {a to f} (6 datacenters)
sa-east-1 {a to c} (3 datacenters)

Going back to Subnets:

Good practices to create Subnets

We should create a subnet for each type of resource that we will deploy in our Network:

One for databases
One for caching services
One for containers, etc.

As AWS have redundancy, our network must have too. It is recommended that we have at least 4 subnets(2 public and 2 private) in two different Availability Zones. The ideal is 3 or 4 subnets per public and private networks.

Tip: The Terraform AWS VPC module will help you to create a VPC and all the required resources without sweat, following all the best practices that we have mentioned here.

State of our Network so far:

Routing Tables

A Routing Table represents a group of one or more subnets. It is the router created based on the groups that will handle where the traffic in our VPC will go.

Subnets aren’t the only resource that we can attach to the table. Now let’s learn about them.

Internet Gateway

An Internet Gateway allows your VPC to connect to the Internet and vice-versa. We create an Internet Gateway and attach to a Routing Table. Attaching an Internet Gateway to a Routing Table makes the subnets that are attached to it public.

Elastic IP

An Elastic IP, it’s a public IP address that you can attach to a resource. This resource can be a EC2 or a Nat Gateway, for example. It’s only available for IPv4 addresses, since IPv6 addresses are public. One of the most common uses of an Elastic IP is to attach to a Nat Gateway, that is our next topic.

Nat Gateway

A Nat Gateway is a resource that allows our instances that are in the private subnets to connect to the internet, but the “internet” cannot connect to the instances in our VPC. We create the Nat Gateway in a public subnet and attach it to the routing table related to the private subnets.

How can we discover if a subnet is public or private?
If the routing table has an Internet Gateway attached the subnets on it are public, if the routing table has a Nat Gateway attached instead, is a private group of subnets.

Now that we covered the base of AWS Networking, let’s talk about security.

Security Groups

A Security Group is created to control the traffic that is allowed to leave or reach the resources associated with it. In this case resources mean: EC2 instances, Containers, Elastic Load Balancers, etc.

In a security group configuration, we can set up Inbound and Outbound rules. For example: If we have an EC2 instance that we want to ssh into it, we need to have an inbound rule that allows connection through the port 22. Or, if our containers need to access a Postgres RDS instance, we have to create an outbound rule that allows the container to reach the instance in the port 5432. It can be attached to one or more resources in our VPC. We can only create “allow” rules for the security groups. When you create an inbound rule, the same port is automatically available for the outbound, removing the need to create an outbound rule for the same port. Everything else is “denied” by default. Check the Security Group documentation for more of the default configuration of this resource.

In other words, the security groups allow us to control what can and cannot access our AWS compute resources, and what our resource can access in or out of the AWS Cloud.

ACL’s

The last resource that we will learn today is the Network Access Control List (NACL’s or ACL’s).

The ACL’s works similar to the security groups, but at the subnet level. By default, the rules of an ACL allows all the traffic to reach the networks. The main difference from a security group, besides the attachment to the subnet, is the ability to create deny rules. For example, we can create a rule where we do not allow connections to the port 22(ssh) or 3389(rdp) in our subnets, giving us an extra layer of security, preventing insecure connections to the resources available in the subnets.

Takeaway: The security groups are associated with the AWS resources available in our VPC, and the ACL’s are associated with one or more subnets in our VPC.

Let’s review the resources that we created on this diagram:

→ We have a VPC with the CIDR 10.0.0.0/16, divided in four subnets, where two are public, and two are private divided in two availability zones, with its CIDR’s containing the network mask /24 size.

→ We also have an Internet Gateway associated with our VPC that allows our resources to access the internet, and a Nat Gateway that allows our private subnets to access the internet, deployed in one of the public subnets.

→ Furthermore, we also have 3 security groups: 2 of them for a group of instances and one for an RDS instance. The instances associated with the security-group-02 is allowed to reach the RDS instance by a rule added to the outbound of its security group. And an inbound rule was added to the security-group-3 related to the RDS to allow the instances to access it. The security-group-01 does not have any inbound and outbound rules associated.

→ Finally, we have a router representing our routing tables, managing the connections between our resources in the subnets.

That’s all folks!