[Security] Secrets and Credentials Exposure in Code

## Summary
Sensitive credentials including Django SECRET_KEY, database passwords, and AWS credentials are being passed through environment variables to worker containers and potentially logged in ECS task definitions, creating a credential leakage risk.

## Severity
🟠 **High** - Credential exposure risk, potential for unauthorized access

## Affected Files
- `apps/challenges/aws_utils.py`
- `apps/challenges/task_definitions.py`
- Docker environment files

## Issues Found

### 1. SECRET_KEY Passed to Worker Containers (Line ~85 in aws_utils.py)
```python
COMMON_SETTINGS_DICT = {
# ...
"SECRET_KEY": settings.SECRET_KEY, # ⚠️ Exposed to all workers!
# ...
}
```

**Problem**: Django SECRET_KEY is passed as environment variable to all ECS/EKS worker containers.

**Impact**:
- Visible in task definitions
- May appear in logs
- Accessible to all worker processes
- Increases attack surface

### 2. Database Password in Environment Variables (Line ~82)
```python
"RDS_PASSWORD": settings.DATABASES["default"]["PASSWORD"],
```

**Problem**: Database password passed via environment variables.

**Impact**:
- Visible in process listings
- May be logged
- Exposed in container metadata
- No rotation mechanism

### 3. AWS Credentials with Default Values
Multiple locations have AWS credentials with default value of `"x"`:
```python
aws_keys = {
"AWS_ACCOUNT_ID": os.environ.get("AWS_ACCOUNT_ID", "x"),
"AWS_ACCESS_KEY_ID": os.environ.get("AWS_ACCESS_KEY_ID", "x"),
"AWS_SECRET_ACCESS_KEY": os.environ.get("AWS_SECRET_ACCESS_KEY", "x"),
}
```

**Problem**: Should not have default values for credentials.

### 4. Email Credentials Passed Through
```python
"EMAIL_HOST_PASSWORD": settings.EMAIL_HOST_PASSWORD,
```

**Problem**: Email passwords passed to worker containers unnecessarily.

## Security Impact

### Credential Leakage Vectors
1. **Container logs**: Secrets may appear in stdout/stderr
2. **Process listings**: `ps aux` shows environment variables
3. **Container inspection**: `docker inspect` reveals env vars
4. **Task definitions**: Stored in AWS with full history
5. **Error messages**: May include environment context
6. **Monitoring tools**: May capture environment variables

### Potential Attacks
- Unauthorized database access
- AWS resource compromise
- Email account takeover
- Session token forgery
- Privilege escalation

## Recommended Solution

### Use AWS Secrets Manager

#### Step 1: Store secrets securely
```bash
aws secretsmanager create-secret \
--name evalai/prod/db-password \
--secret-string "actual-password"
```

#### Step 2: Update IAM roles
Grant ECS task execution role access:
```json
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": ["secretsmanager:GetSecretValue"],
"Resource": ["arn:aws:secretsmanager:*:*:secret:evalai/*"]
}]
}
```

#### Step 3: Reference in task definitions
```json
{
"name": "RDS_PASSWORD",
"valueFrom": "arn:aws:secretsmanager:region:account:secret:evalai/prod/db-password"
}
```

### Alternative: AWS Systems Manager Parameter Store
For less sensitive configuration:
```bash
aws ssm put-parameter \
--name /evalai/prod/db-host \
--value "db.example.com" \
--type String
```

Start by reading apps/challenges/aws_utils.py around lines 82-85 and trace COMMON_SETTINGS_DICT into apps/challenges/task_definitions.py and the Docker environment files. Identify where SECRET_KEY, database and email passwords, and default AWS credentials enter worker definitions. Done means sensitive values are no longer exposed as ordinary environment variables or placeholder defaults, with the chosen AWS secret reference and access configuration documented in the affected deployment files.

Written by the indexing model from the issue text.