Assignment1 leepeihui22004781: Secure Externalized Configuration & System Decoupling

[PeiHui369]

Pull Request: Secure Externalized Configuration & System Decoupling

1. Addressed Issues

The Dean's Crisis Management System suffered from critical Security and Maintainability flaws that directly impacted system stability and developer workflow.

• High-Severity Startup Failure (Tightly Coupled DB): The deployment setup failed to initialize the PostgreSQL database locally because the docker-compose.yaml did not define the required POSTGRES_PASSWORD. This issue made the repository non-functional out-of-the-box and prevented local development.

• High-Risk Secret Exposure: The Django Core API's SECRET_KEY was hardcoded in plaintext within deans-api/settings.py, which is a severe security vulnerability that exposes private credentials in the public version control history.

• Tightly Coupled Communication: Inter-service communication, specifically the scheduled report delivery in deans-api/api/cron.py, relied on a hardcoded URL (http://notification:8000/reports/). This tightly coupled the application logic to a specific network address, hindering flexibility and maintenance.

2. What Was Reengineered

The task focused on restructuring the configuration management by moving away from hardcoded secrets and values and into a secure, externalized system, adhering to the 12-Factor App methodology for configuration. This constituted a significant refactoring of the application's configuration spine.

• Files Reengineered:

File / Component	Repository	Reengineering Action Implemented
.env and .gitignore	deans-deploy (Root)	Created the .env file to serve as the secure, local source for secrets (DJANGO_SECRET_KEY) and dynamic parameters (POSTGRES_*, NOTIFICATION_SERVICE_URL). Updated .gitignore to prevent commitment, eliminating the plaintext exposure risk.
docker-compose.yaml	deans-deploy (Root)	Fixed Startup Failure: Added the environment block to the db service with environment variables (e.g., ${POSTGRES_PASSWORD}). Enabled Injection: Added env_file: .env to the web, db, and cron services to securely inject configurations from the uncommitted file.
settings.py	deans-api	Secret Decoupling: Replaced the hardcoded, plaintext SECRET_KEY string with a dynamic call to os.environ.get('DJANGO_SECRET_KEY'). Credential Decoupling: Refactored the DATABASES configuration block to read all connection parameters (NAME, USER, PASSWORD) from the environment, ensuring the API consumes its credentials securely.
api/cron.py	deans-api/api	Inter-Service Decoupling: Replaced the hardcoded URL string (url = "http://notification:8000/reports/") with a dynamic reference to f"{settings.NOTIFICATION_SERVICE_URL}/reports/". This abstracts the network address, completing the decoupling of the Core API's scheduling mechanism.

Configuration Decoupling:

The system's architecture was formally decoupled by establishing environment variables as the single source of truth for dependencies. This transition is essential for making the system production-ready and scalable.

Component	Old Configuration Source	New Configuration Source (Externalized)	Value of Change
Django SECRET_KEY	Hardcoded plaintext string in settings.py	DJANGO_SECRET_KEY in .env	Security: Eliminates high-risk exposure in VCS.
DB Credentials	Hardcoded/missing in settings.py and docker-compose.yaml	POSTGRES_DB/USER/PASSWORD in external .env	Stability: Fixes initialization failure and ensures credentials are never hardcoded.
Notification URL	Hardcoded string in api/cron.py	NOTIFICATION_SERVICE_URL in settings.py (read from .env)	Maintainability: Decouples API logic from network topology.

3. Reengineering Strategy/Approach Used

3.1 Reverse Engineering

• Analysis: Systematically inspected docker-compose.yaml and deans-opi/settings.py to pinpoint the hardcoded values (A: SECRET_KEY string, B: missing POSTGRES_PASSWORD) and locate the tightly coupled network call in deans-opi/api/cron.py.

• Diagnosis: Confirmed that the startup failure stemmed from a deployment configuration flaw (missing environment variable) and not an application bug.

3.2 Alteration/Restructuring

• Design Shift: The core configuration model was restructured from Insecure, Tightly-Coupled Configuration to Secure, Decoupled Environment Configuration.

• Decoupling Contract: Formalized a contract mandating all services must consume secrets and dynamic parameters (DJANGO_SECRET_KEY, POSTGRES_*, NOTIFICATION_SERVICE_URL) from the external environment, thereby eliminating the reliance on committed code for connection details.

3.3 Forward Engineering

The implementation involved modular, targeted changes to replace the flawed configuration logic:

• deans-deploy/env/.gitignore: Created .env (stores secrets) and ensured it is listed in .gitignore to implement the security fix.

• docker-compose.yaml: Implemented Fix A: Added the environment block to the db service using ${POSTGRES_PASSWORD} and added env_file: .env to inject secrets across all services.

• settings.py: Implemented Fix B: Replaced the hardcoded SECRET_KEY and database credentials with os.environ.get() calls.

• api/cron.py: Implemented Fix C: Replaced the hardcoded URL string with f"{settings.NOTIFICATION_SERVICE_URL}/reports/", completing the decoupling of interservice communication.

4. Impact of Changes

The changes provide immediate, measurable improvements across stability, security, and maintainability.

Aspect	Before Reengineering	After Reengineering
System Stability	Failure to launch locally due to DB initialization error.	System launches reliably; DB initializes using secure credentials.
Security	SECRET_KEY exposed in plaintext in settings.py.	Secrets are secured; loaded from an uncommitted .env file via environment injection.
Maintainability	Network changes (e.g., Notification service port change) required modifying Python code in cron.py.	Highly decoupled; network changes only require updating the external .env file.
Architectural Quality	Tight coupling between application code and deployment/network details.	Adherence to 12-Factor App principles for externalized configuration.

Summary and Conclusion

This reengineering task, Secure and Decouple API Configuration, successfully converted a brittle, insecure application startup process into a stable, modern one. By rigorously applying Reverse Engineering to diagnose the plaintext secrets and startup failures, followed by Alteration/Restructuring to mandate environment-based configuration, the final Forward Engineering implementation fixed critical flaws in the deployment (docker-compose.yaml) and application code (settings.py, cron.py). This work significantly raised the system's security posture and its maintainability index.