Configuration and Secrets Management

Relevant source files

The following files were used as context for generating this wiki page:

• terraform/infrastructure/variables.tf
• terraform/infrastructure/main.tf
• frontend/next.config.ts
• apps/scratch/craco.config.js
• frontend/src/pages/login/oidc-redirect.tsx

Configuration and secrets management in the Collimator project is handled through a multi-layered approach, tailored to the specific needs of each component: infrastructure, backend, and frontend applications. The core strategy relies on Terraform for provisioning infrastructure and injecting configuration and secrets, while individual applications use standard file-based configurations for build-time and runtime settings.

The infrastructure layer, managed by Terraform, uses input variables to define environment-specific parameters, including sensitive data like API keys and client IDs. These variables are then propagated to the respective AWS services. The backend, running on AWS Fargate, receives its configuration, including database connection strings and secrets, as environment variables. Frontend applications like the main Next.js app and the Scratch app use dedicated configuration files (next.config.ts, craco.config.js) to manage build processes, integrations like Sentry, and webpack customizations.

Infrastructure Configuration (Terraform)

The project's infrastructure is defined and managed using Terraform. Configuration is centralized through input variables, which allows for consistent and repeatable deployments across different environments (e.g., development, production).

Sources: terraform/infrastructure/variables.tf, terraform/infrastructure/main.tf

Input Variables

All configurable parameters for the infrastructure are declared in terraform/infrastructure/variables.tf. This file serves as the single source of truth for inputs into the Terraform modules.

The following table summarizes key configuration variables:

Variable	Description	Type	Default Value
name	The base name for resources.	string	"crt"
environment	The deployment environment (e.g., "dev", "prod").	string	"dev"
region	The AWS region for deployment.	string	"eu-central-1"
domain_name	The domain name for the application.	string	null
open_id_connect_microsoft_client_id	The Client ID for Microsoft OpenID Connect authentication. This is a secret.	string	null
sentry_dsn_backend	The DSN for Sentry error tracking in the backend. This is a secret.	string	null

Sources: terraform/infrastructure/variables.tf:1-35

Configuration Flow

The root main.tf file orchestrates the deployment by initializing various modules (network, frontend, backend, database, etc.) and passing the necessary configuration variables to them. Secrets and configuration values are passed down from the root module to the specialized modules.

This diagram illustrates how variables flow from the root configuration into the different infrastructure modules.

Backend Configuration

The backend service, running as an AWS Fargate task, receives its configuration and secrets as environment variables. These are injected by Terraform during the deployment process.

Sources: terraform/infrastructure/main.tf:52-69

The backend module in main.tf is responsible for setting up the Fargate service and passing runtime configuration.

# terraform/infrastructure/main.tf:52-69
module "backend" {
  source = "./modules/fargate"

  # ... other parameters
  
  open_id_connect_microsoft_client_id = var.open_id_connect_microsoft_client_id
  sentry_dsn                          = var.sentry_dsn_backend 
  database_url                        = module.database.database_url

  tags = var.tags
}

The following environment variables are passed to the backend container:

Environment Variable	Description	Source
DATABASE_URL	The connection string for the PostgreSQL database.	Output from the database module.
SENTRY_DSN	The Sentry DSN for error reporting.	var.sentry_dsn_backend
OPEN_ID_CONNECT_MICROSOFT_CLIENT_ID	The client ID for Microsoft OIDC authentication.	var.open_id_connect_microsoft_client_id

This approach ensures that secrets are not hardcoded in the application's source code and can be managed securely through Terraform's variable management system. The use of AuthenticationProvider.MICROSOFT in the frontend confirms the backend is configured to handle Microsoft OIDC tokens.

Sources: terraform/infrastructure/main.tf:60-62, frontend/src/pages/login/oidc-redirect.tsx:87-91

Frontend Configuration

The frontend applications have their own build and runtime configurations managed in dedicated files.

Main Frontend (Next.js)

The main frontend is a Next.js application, and its configuration is located in frontend/next.config.ts.

Sources: frontend/next.config.ts

Key configuration aspects include:

• Build Output: Configured for static export (output: "export") to the dist directory.
• Sentry Integration: The configuration is wrapped with withSentryConfig to enable Sentry error monitoring. This is conditionally applied and is skipped if BABEL_ENV is set to coverage, likely to avoid conflicts with code instrumentation.
• Webpack Customization: Webpack is configured with resolve.symlinks = false to handle symlinked packages correctly within the monorepo.

Sentry Configuration

Sentry is configured with several options to manage error reporting and source map uploading.

Sentry Option	Value	Description
org	"hep-vaud"	The Sentry organization slug.
project	"crt-frontend"	The Sentry project slug.
silent	!process.env.CI	Suppresses logs unless running in a CI environment.
widenClientFileUpload	true	Uploads a larger set of source maps for better stack traces.
reactComponentAnnotation	{ enabled: true }	Automatically annotates React components for clearer breadcrumbs in Sentry.
disableLogger	true	Tree-shakes Sentry logger statements to reduce bundle size.

Sources: frontend/next.config.ts:30-65

Scratch App (Create React App)

The Scratch application uses craco (Create React App Configuration Override) to customize its webpack configuration, defined in apps/scratch/craco.config.js. This is necessary to integrate the complex build requirements of the Scratch GUI and its related libraries.

Sources: apps/scratch/craco.config.js

Key customizations include:

• Webpack Alias: An alias @scratch-submodule is set to src/scratch for easier imports.
• Plugins: CopyWebpackPlugin is used to copy media assets from scratch-blocks and other modules into the build output.
• Polyfills: Fallbacks for Node.js core modules like buffer and stream are provided to ensure browser compatibility.
• Loader Configuration: CSS and PostCSS loaders are configured to match the requirements of the Scratch project, such as enabling camelCase for CSS module class names.
• Code Coverage: The configuration adds the istanbul babel plugin when process.env.COVERAGE is "true" to instrument code for coverage reports.

Sources: apps/scratch/craco.config.js:22-148