API with NestJS #101. Managing sensitive data using the AWS Secrets Manager

March 27, 2023

This entry is part 101 of 121 in the API with NestJS

When managing the architecture of our system, we often deal with sensitive data. It’s our job to ensure they don’t fall into the wrong hands. An excellent example of confidential information is the database password and the Json Web Token secret key. In this article, we explore how we can use the AWS Secrets Manager to increase the security of our NestJS application.

Defining environment variables

It’s tough to hide a piece of information when it is included in the source code of our application.

database.module.ts

import { Module } from '@nestjs/common';

import { TypeOrmModule } from '@nestjs/typeorm';

import { ConfigModule, ConfigService } from '@nestjs/config';

@Module({

imports: [

TypeOrmModule.forRootAsync({

imports: [ConfigModule],

inject: [ConfigService],

useFactory: () => ({

type: 'postgres',

host: 'postgres',

port: 5432,

username: 'admin',

password: 'myStrongPassword',

database: 'nestjs',

autoLoadEntities: true,

}),

})

export class DatabaseModule {}

With the above approach, everyone with access to our code has full access to our database. This is a significant security issue that might lead to compromising our database. This might be especially apparent if we write open-source software, but it is not limited to it. For example, we might have teammates we trust enough to provide them with the code, but we wouldn’t want them tinkering with the production database.

Besides that, our testing environment will surely use a different database than the production environment. When we include environment-specific details in our code, we don’t have a straightforward way of reusing our code across different environments.

We can solve the above problems by externalizing specific values in the form of environment variables. The NestJS application we’ve created during this series has a bunch of them. A good example is the password of our PostgreSQL database. A good way of introducing an environment variable is to add it to our validationSchema. When doing that, we force NestJS to check if all necessary environment variables are provided. If we forget to provide a specific variable we marked as required, the application won’t start.

app.module.ts

import { Module } from '@nestjs/common';

import { ConfigModule } from '@nestjs/config';

import * as Joi from 'joi';

@Module({

imports: [

ConfigModule.forRoot({

validationSchema: Joi.object({

POSTGRES_HOST: Joi.string().required(),

POSTGRES_PORT: Joi.number().required(),

POSTGRES_USER: Joi.string().required(),

POSTGRES_PASSWORD: Joi.string().required(),

POSTGRES_DB: Joi.string().required(),

JWT_SECRET: Joi.string().required(),

JWT_EXPIRATION_TIME: Joi.string().required(),

PORT: Joi.number(),

}),

// ...

controllers: [],

providers: [],

})

export class AppModule {}

Using environment variables, we can now improve our DatabaseModule and avoid hardcoding sensitive information in our code.

database.module.ts

import { Module } from '@nestjs/common';

import { TypeOrmModule } from '@nestjs/typeorm';

import { ConfigModule, ConfigService } from '@nestjs/config';

import Address from '../users/address.entity';

@Module({

imports: [

TypeOrmModule.forRootAsync({

imports: [ConfigModule],

inject: [ConfigService],

useFactory: (configService: ConfigService) => ({

type: 'postgres',

host: configService.get('POSTGRES_HOST'),

port: configService.get('POSTGRES_PORT'),

username: configService.get('POSTGRES_USER'),

password: configService.get('POSTGRES_PASSWORD'),

database: configService.get('POSTGRES_DB'),

entities: [Address],

autoLoadEntities: true,

}),

})

export class DatabaseModule {}

Providing the values for the environment variables

When we develop and run our application locally on our machine, we can provide the values for our environment variables by creating a dedicated file called .env.

It is a good practice to avoid commiting the .env file to the repository.

.env

POSTGRES_HOST=postgres

POSTGRES_PORT=5432

POSTGRES_USER=admin

POSTGRES_PASSWORD=admin

POSTGRES_DB=nestjs

JWT_SECRET=K@%96e86Dnkp2Zye

JWT_EXPIRATION_TIME=21600

PORT=3000

Since our application runs in Docker, we need to point it to the file containing our environment variables.

docker-compose.yml

services:

nestjs-api:

build:

context: .

target: install-dependencies

env_file:

- .env

# ...

If you want to know more about running NestJS using Docker, check out API with NestJS #91. Dockerizing a NestJS API with Docker Compose

Environment variables values in ECS

In one of the previous parts of this series, we learned how to deploy our NestJS application using Amazon Elastic Container Service. One of the important parts of it was providing the environment variables for our application running in the cluster.

So far, we’ve been doing that by putting the values directly into the task definition.

Unfortunately, this has some downsides. First, we need to acknowledge that in real-life scenarios, a web application is managed by a whole team of people. Each person might have their own AWS account and access to certain parts of our configuration.

With the above approach, everyone who can access our task definition has access to all of our environment variables, including sensitive data. To deal with this issue, we can use the AWS Secrets Manager.

Introducing AWS Secrets Manager

With AWS Secrets Manager, we can control access to sensitive information, such as database credentials and private keys. We can also rotate them by configuring AWS to change the passwords automatically.

Integration with RDS

Let’s start by opening the Secrets Manager dashboard and going to the secrets page. When we do that, we notice that we might already have some secrets defined.

This is because Relational Database Service (RDS) is integrated with the Secrets Manager. When we created our database, AWS stored our credentials in the Secrets Manager.

If you want to read morea bout using the Relational Database Service, check out API with NestJS #93. Deploying a NestJS app with Amazon ECS and RDS

When we click on the name of our secret, we can access all of the associated values.

To be able to refer to the secret values in the Elastic Container Service, we need the Amazon Resource Name (ARN) of our secret. You can find it at the top of the page.

Creating new secrets

Besides the database, we also have other sensitive information in our environment variables, such as the JWT secret key. Therefore, let’s create a new secret to hold it.

To do that, we need to click the “Store a new secret” button on the secrets page. Then, we must choose the right secret type and define key/value pairs. In the case of our JWT token, the only thing we want to store for now is the secret key.

We also need to provide our secret with a name.

Allowing the service to use our secrets

By default, our services can’t access any of our secrets. To allow that, we need to create an IAM policy with the correct permissions.

Make sure to put the correct resource names in the resources part of the above interface. You can find the Amazon Resource Name (ARN) of each secret on its page in the Secrets Manager.

We also need to give a name to our policy.

By default, AWS uses the ecsTaskExecutionRole IAM role when executing our ECS tasks.

We can create our custom IAM role containing the permissions in the ecsTaskExecutionRole and our new ReadSecretsForNestjsApp policy. When doing that, it’s important to select the correct use case.

We also need to provide our new role with the required permissions.

Thanks to doing the above, we can choose our new role when defining the task definition. If we do that, our service will be able to use the secrets we’ve created.

Using the secret values

The last step is to modify our task definition to use the values from the secrets manager.

To use a value from the secrets manager, we must choose ValueFrom as the value type. The most crucial thing is using the right resource name as values in our environment variables.

The resource name consists of the following parts: arn:aws:secretsmanager:[region]:[aws_account_id]:secret:[secret_name]. By adding :[key_name]:: at the end of the resource name, we can refer to one of the keys of our secret, for example, postgres_database-mDO5Z7:password::.

Therefore, in our case, we use the following values:

arn:aws:secretsmanager:eu-central-1:[aws_account_id]:secret:nestjs-api/jwt-jnN3CB:secret::
arn:aws:secretsmanager:eu-central-1:[aws_account_id]:secret:postgres_database-mDO5Z7:username::
arn:aws:secretsmanager:eu-central-1:[aws_account_id]:secret:postgres_database-mDO5Z7:host::
arn:aws:secretsmanager:eu-central-1:[aws_account_id]:secret:postgres_database-mDO5Z7:password::
arn:aws:secretsmanager:eu-central-1:[aws_account_id]:secret:postgres_database-mDO5Z7:port::

Summary

In this article, we’ve increased the security of our architecture. To do that, we stored sensitive data necessary for our NestJS application to run in the AWS Secrets Manager. While doing that, we also had to create additional policies and roles so that our service would have access to the secrets. Thanks to all of the above, we’ve improved our workflow and learned more about AWS.

Series Navigation<< API with NestJS #100. The HTTPS protocol with Route 53 and AWS Certificate ManagerAPI with NestJS #102. Writing unit tests with Prisma >>