In this post, we will configure AWS CloudFront distribution to provide restricted access to S3 bucket private contents so that objects can only be accessed through CloudFront Signed URL.

A signed URL includes additional information such as expiration date, that provide user applications to have better control over access to the content.

Prerequisite

1. AWS account with console access.
2. Any Java IDE to generate signed URL code
3. OpenSSL utility to generate public/Private Key

Now let’s start with the steps for the workflow.

Create S3 Bucket

Login to AWS console search for S3 service or go to https://s3.console.aws.amazon.com

Click on S3 that leads to S3 console and follow the Create bucket button that lands to create bucket form.

Choose a globally unique and valid name for the bucket, choose AWS region for which logged in user have persimmon to create bucket. Make sure the “Block all public access” checkbox is checked. Left rest of the settings to default and click on create bucket.

Create a key pair

In following steps, OpenSSL is used to create key pair to make a trusted key pair group for CloudFront.

There are other tools as well to create public/private key pairs.

• Use the following command to generate RSA key pair and save it in a file named private_key.pem.

openssl genrsa -out private_key.pem 2048

• The following command will extract the public key from the generated file and save it in public_key.pem.

openssl rsa -pubout -in private_key.pem -out public_key.pem

• Later this post will use java to generate signed URLs so the private key pair file cannot be used directly, instead PEM to DER conversion is required. Use the following command to do so.

openssl pkcs8 -topk8 -nocrypt -in private_key.pem -inform PEM -out private_key.der -outform DER

Keep aside the files created as these will be required later while creating CloudFront Distribution to be used as signers to create signed URLs.

Creating the signers in CloudFront

Use the following steps to create a signer in cloud front,

• Open CloudFront Console and from the left hamburger menu, navigate to public keys under key management section.

• Go to Public keys and create one by providing appropriate name and paste the contents of public_key.pem file in Key section.
• In the same key management section, go to key groups and create a key group with the public key created in previous step.

Now let’s move on and create cloud front distribution.

Create CloudFront Distribution

Search for CloudFront in AWS console.

Open CloudFront console and click on “Create a CloudFront distribution” that opens the create CloudFront distribution form.

From the origin dropdown, select the bucket created in previous step as Origin domain.

For Origin access, choose from options given,

1. Origin access control settings, which is recommended where you need to update the bucket policy, to allow access to IAM service principal, provided when distribution is created, or

2. Legacy access identities where an option to update the bucket policy is provided. This will update the S3 bucket policy so that the bucket can be accessible using the cloud front distribution.

Choose the recommended one and create control setting and use the same.

Choose Allowed HTTP methodsas required.

In Restrict viewer access, select yes and keep Trusted authorization type as Trusted key groups. In Add key groups section, select the key group from the drop down created in previously.

This will bind the key pair created in previous section so that one must need to create CloudFront Signed URL to access S3 Bucket content associated with distribution.

In cache and Origin Request, select CachingDisabled so that any update in s3 object will immediately reflected while fetching it.

Now create CloudFront distribution keeping other options as default.

On success distribution detail page will open where on top of the page, copy the policy statement.

Update access policy in S3 bucket

Go to S3 console (https://s3.console.aws.amazon.com) and select the same bucket used in cloud front distribution as origin.

Move to bucket policy section under Permission tab, edit the bucket policy and paste the contents of bucket policy copied.

For this policy, the allowed action is restricted to read the objects, that can be modified as per requirement. Let’s update the action and add permission to write objects as well. To do so, replace the action line with following.

"Action": ["s3:GetObject","s3:PutObject"],

The resulting statement will look like mentioned below.

Save the changes.

With this configuration part is completed and now let’s move on to create cloud front signed URL.

Generating CloudFront Signed URL

Steps and code to generate cloud front signed URL is explained below.

Create spring boot gradle project and add the below dependencies to it.

implementation 'com.amazonaws:aws-java-sdk-cloudfront:1.12.283'

Here is the code for generating cloud front signed URL.

import java.io.File;
import java.io.IOException;
import java.security.spec.InvalidKeySpecException;
import java.util.Date;

import org.springframework.boot.CommandLineRunner;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

import com.amazonaws.services.cloudfront.CloudFrontUrlSigner;
import com.amazonaws.services.cloudfront.util.SignerUtils;

@SpringBootApplication
public class CloudfrontsignedurlApplication implements CommandLineRunner {

	public static void main(String[] args) {
		SpringApplication.run(CloudfrontsignedurlApplication.class, args);
	}

	@Override
	public void run(String... args) throws Exception {
		String cloudFrontKeyPairId = "<public_key_id>"; // public key id created in cloud front key management section.
		String distributionDomain = "<cloud_front_distribution_name>"; // cloud front distribution domain name.
		String key = "cloudfrontsignedurl/objetc1.txt"; // S3 bucket object path

		Date expirationDate = new Date(System.currentTimeMillis() + 7200000); // Token will be valid for 2 hour
		try {
			File cloudFrontPrivateKeyFile = generateCloudFrontPrivateKeyFile();
			String signedUrl = CloudFrontUrlSigner.getSignedURLWithCannedPolicy(SignerUtils.Protocol.https,
					distributionDomain, cloudFrontPrivateKeyFile, key, cloudFrontKeyPairId, expirationDate);
			System.out.println(signedUrl);

		} catch (IOException | InvalidKeySpecException exception) {
			throw new Exception(exception.getMessage());
		}
	}

	private File generateCloudFrontPrivateKeyFile() {
		File file = new File("<private_key_file>"); // Path to public/private key pair file.
		return file;
	}
}

The generated signed URL will look as mentioned below.

https://d26doxj2i1y97q.cloudfront.net/cloudfrontsignedurl/objetc1.txt?Expires=1661499384&Signature=LabCbO27wL1-ErAEwYU9CBGh1pVdmRY2oQ94QfQP9cGi4vQTNgo7xT3ctbr6lAolcH5AZEe-I79s~spEA6VCnRUIstsvDhLoN4spJHrQxlecapxKK7P0J9U6kXL8V2ucDgwrJmFfdFWpipeGkgTVgKJ~s53Unp76YrTJODYnX-ZZc3RuQ4go5oBYhXU2hRHKlVusV3llhlOyfN58FxytzAZkegECRj6LR6m0WzRI-guCPqHCO7Gir~Ls5ewCw-TZpAyMca-LjKAeTGd~KS4etFgr5Tbt3UrGiDXJVoDkCcc-Z1cu9xu34s9ZQHqSD-t7AHdCszv6sitRcFK9PSJQyg__&Key-Pair-Id=K1HEUAHR3KG1E3

This URL can be used to upload and download the object to S3 bucket.

Note** One also need to set the Access Key ID and Secret Access Key for programmatic access.

Complete code for generating the signed URL can be found at Github.

Argo CD is a declarative Git-Ops continuous delivery tool created for Kubernetes.

k8s application manifests should be version controlled in a git repository. Argo CD uses the git repository as a source of truth which represent the desired state of the application.

Argo CD is implemented as a k8s controller which continuously monitor current or live state with the desired state described in the git repository and automate the deployment of desired state in k8s environment.

Prerequisite

Before moving forward, some tools are required to complete the exercise,

• A local Kubernetes cluster, for example Docker Desktop or Minikube
• kubectl
• Git account and git CLI
• Argo CD

The installation instructions for local Kubernetes cluster can be found in respective links.

Installing Argo CD

As mentioned before, Argo CD is implemented as a custom controller, so it needs to be deployed in k8s.

Let's create a separate namespace for Argo CD installation.

kubectl create ns argocd

Coming back to our main section, now lets install ArgoCD in newly created namespace.

kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

This took around 3-5 minutes, you can check the status of deployment using kubectl get deployment which will give output as follows:

NAME                 READY   UP-TO-DATE   AVAILABLE   AGE
argocd-dex-server    1/1     1            1           5m28s
argocd-redis         1/1     1            1           5m28s
argocd-repo-server   1/1     1            1           5m28s
argocd-server        1/1     1            1           5m28s

Access Argo CD API Server

By default, the Argo CD API server is not exposed with an external IP. To access the API server, choose one of the following techniques to expose the Argo CD API server:

1. kubectl patch svc argocd-server -n argocd -p '{"spec": {"type": "LoadBalancer"}}'
2. kubectl port-forward svc/argocd-server -n argocd 8081:443

Use localhost:8081 to access the API server in browser.

Login to Argo CD

Default username to login to Argo CD server is admin, to get the password there are several ways.

One way is to get the initial admin password using command below. The password is base 64 encoded, so if on windows use Git Bash to use the decode function.

kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d

This will return the decoded password that can be used directly.

Another way is to patch the argocd-secret and update the admin.password field which should be encrypted with Bcrypt password hashing function. One can use the online tools like bcrypt-generator.com to get the hash.

Here the updated password is admin.

kubectl -n argocd patch secret argocd-secret -p '{"stringData": {"admin.password": "$2a$10$aDulNEmKSuPr8rUH7CvMguvkz/x5wRJuiZgXOw4cc4Zzk2RhpRpBi", "admin.passwordMtime": "'$(date +%FT%T)'"}}'

After login, target page will show the list of application. As there are no applications, so this section is blank for now.

Login using Argo CD CLI

First install Argo CD CLI as per the operating system.

For mac or Linux, use the below command to install it.

brew install argocd

For windows, follow the link, download and add the entry in path variable.

To login through CLI, use the command mentioned below:

argocd login localhost:8081 --username admin --password admin --insecure

Argo CD installation and Login part is completed. Now the next step is to create a demo application and update k8s manifest to deploy in cluster.

The Demo Application

As it already discussed that Argo CD uses git repository to automate the deployment, so a git repository is required. Here I am using github repository.

git clone https://github.com/aprabhat/argo-cd-color-app.git

After cloning, switch to dev branch, check for the deploy folder and take a look at deployment and service manifest files.

Now create another namespace in which the demo application will be deployed.

kubectl create ns practice

Create k8s resource of type Argo CD application using the above repo as source. For this create color-app.yaml file with following content. Here, targetRevision represents the branch name and path represents the location from root directory where the k8s manifest resides.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: color-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/aprabhat/argo-cd-color-app.git
    targetRevision: dev
    path: deploy
  destination:
    server: https://kubernetes.default.svc
    namespace: practice

Save and apply this yaml file.

kubectl apply -f app.yaml

This will create a resource of type application. The new application is now available in Argo CD dashboard.

The app list and status can also be fetched by using Argo CD CLI using argocd app list command.

Click on the app tile in UI and check for the resources created for the application.

The app is created but not deployed as the syncPolicy is not set and default to manual. So a manual synchronization is required.

argocd app sync color-app

Once the sync is completed, the application details UI will also be updated with all the resources created for k8s application.

Now let's update the application to be on auto sync mode. To do so, update the color-app.yaml file for syncPolicy and apply it again using kubectl apply -f color-app.yaml.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: color-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/aprabhat/argo-cd-color-app.git
    targetRevision: dev
    path: deploy
  destination:
    server: https://kubernetes.default.svc
    namespace: practice
  syncPolicy:
    automated: {}

To test the auto sync, update the deployment.yaml file for replicas and push the change to git repository. Check the application details in Argo CD UI dashboard for the pods if they scaled to 2.

This time as syncPolicy is set to automated, there is no need to do a manual sync.

Finally you can check for the deployed application. First describe the service from practice namespace using kubectl -n practice describe svc color-service

Name:                     color-service
Namespace:                practice
Labels:                   app.kubernetes.io/instance=color-app
Annotations:              <none>
Selector:                 app=color
Type:                     NodePort
IP Family Policy:         SingleStack
IP Families:              IPv4
IP:                       10.110.20.25
IPs:                      10.110.20.25
LoadBalancer Ingress:     localhost
Port:                     <unset>  3000/TCP
TargetPort:               3000/TCP
NodePort:                 <unset>  30007/TCP
Endpoints:                10.1.0.19:3000,10.1.0.20:3000
Session Affinity:         None
External Traffic Policy:  Cluster
Events:                   <none>

To access the sample application deployed use the localhost:<NodePort>. In this case it is localhost:30007, open this in the browser. The nice UI will appear on the browser window.

In few simple steps, you are able to automate the deployment of k8s application using Argo CD.

Although this post is not covering all the scenarios or production system use cases but it is a good place to have a glimpse of how Argo CD works and to understand how to automate k8s application deployment with Argo CD.

Conclusion

In the era of microservice, as the number of k8s workloads keeps on increasing, deploying the tens or hundred of pods at the same time is a tedious task.

In this situation, Argo CD is a great tool which enable teams  to automate the deployment on multiple environments(testing, staging production). Argo CD will definitely helps the scrum teams to save time by automating the Continuous Delivery process and reduce common errors.

JSON Web Token or JWT or sometimes pronounced as 'jot' is an open standard (RFC-7519) for transferring claims in a compact, printable and secure manner along with a signature that provide its authenticity between two parties as a JSON object.

JWTs can be signed using JSON Web Signature (RFC-7515) and/or encrypted using JSON Web Encryption (RFC-7516) and that provides a powerful and secured solution for transferring information in many different situations.

In this section we will focus on unencrypted JWTs, and will take the encrypted one in next part.

Structure of JWT

JWT's contains 3 different components separated by dots(.)

• Header
• Payload
• Signature/Encryption Data

The header and payload are mandatory and have certain structure(JSON). The third part(not a JSON object itself) which is signature depends upon the algorithm used for signing and can be omitted in case of unsecured/unencrypted JWTs.

JWT usage URL safe base64 encoding where '+' and '/' are substituted by '-' and   '_' characters respectively. The resulting sequence is a string with format header.payload.signature and look like the following,

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

In this example, the base64url decoded header is

{
  "alg": "HS256",
  "typ": "JWT"
}

the decoded payload is

{
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022
}

and the last part is the secret required to verify the signature.

Now lets see the details of mandatory part of JWT which is the header and the payload.

Header

Also known as JOSE(JSON Object Signing and Encryption) Header is the first part of JWT token. There can be several fields in the header depends upon the type of JWT, for example, the only mandatory field for the unencrypted JWT is alg with value as none. For a signed JWTs, some fields can be alg, jku, kid, typ.

The header part is a JSON object and has the following format

{
  "alg": "RS256", // none in case of unencrypted jwt
  "jku": "url to the public key set",
  "kid": "key-id-1", //optional
  "typ": "JWT"
}

It is possible to add additional user defined claims to the header.

Payload

Just like the header, payload is a JSON object. This is the part where all the user related data is added. It can contain claims with specific meaning known as registered claim along with some personal user data, although no claim is mandatory.

There are several reserved claims as per JWT specification that are non mandatory but seven claims are recommended to have for better interoperability. The seven claims are as follows,

• iss (issuer): party that issued the JWT
• sub (subject): Identifies the user
• aud (audience): Recipients of JWT or the application that reading the data from JWT
• exp (expiration time): Time (seconds since epoch) after which the JWT expires
• nbf (not before time): Time (seconds since epoch) from which JWT is considered as valid.
• iat (issued at time): Time at which the JWT was issued
• jti (JWT ID): Unique identifier; can be used to differentiate JWT from similar content.

You can see the complete list of reserved claims here.

Unencrypted JWTs

So far we have learned about the header and the payload part which is enough to construct a unencrypted JWT token.

Unencrypted JWTs formed with simple header

{
  "alg": "none",
  "typ": "JWT"
}

and with payload

{
  "sub": "user108",
  "name": "Shakal",
  "iat": 1629690269
}

now lets create a unencrypted JWT using these two parts. The pseudo code for this would be as follows,

token = base64urlEncode(header) + "." + base64urlEncode(payload) + "."

You can use any coding language to write encode and decode functions. Here I am using java 8 Base64 encoding that is part of JDK

import java.nio.charset.StandardCharsets;
import java.util.Base64;
public String base64urlEncode(String raw) {
    return Base64.getUrlEncoder().withoutPadding().encodeToString(raw.getBytes(StandardCharsets.UTF_8));
}

We also need to remove the trailing equal signs (=), for this we are using the withoutPadding() function. The resulting string will look like

ewogICJhbGciOiAibm9uZSIsCiAgInR5cCI6ICJKV1QiCn0.ewogICJzdWIiOiAidXNlcjEwOCIsCiAgIm5hbWUiOiAiU2hha2FsIiwKICAiaWF0IjogMTYyOTY5MDI2OQp9.

Conclusion

Now we have the basic understanding of structure of JWTs and different parts used to create JWTs. We discussed about the first two parts of JWT which is the header and the payload and created a unsecured JWT.
I real world scenarios, the use of unsecured JWTs is very rare or not at all.

In the next part, we will discuss about encrypted or secured JWTs and have more details on signature part.