@syntropysoft/praetorian
Version:
Praetorian CLI – A universal multi-environment configuration validator for DevSecOps teams. Validate, compare, and secure YAML/ENV files with ease.
125 lines (101 loc) • 3.95 kB
Markdown
# Security Rules Example
This example demonstrates how to use Praetorian's built-in security validation rules to ensure your configuration files are secure and follow security best practices.
## Files in this example:
- `praetorian.yaml` - Configuration file with security rules
- `config-dev.yaml` - **SECURE** development configuration (passes all rules)
- `config-prod.yaml` - **SECURE** production configuration (passes all rules)
- `config-insecure.yaml` - **INSECURE** configuration (fails security rules)
## Security Rules Demonstrated:
### 1. Secret Detection Rules
- **Rule ID**: `no-hardcoded-secrets`
- **Purpose**: Detects hardcoded API keys, passwords, and tokens
- **Severity**: Error
- **What it checks**:
- API keys, passwords, secrets, tokens, auth keys
- Excludes example/placeholder values
### 2. Permission Validation Rules
- **Rule ID**: `secure-permissions`
- **Purpose**: Ensures configuration files have secure permissions
- **Severity**: Warning
- **What it checks**:
- File permissions (max 644)
- Sensitive file permissions (600 for keys, secrets)
### 3. Encryption Rules
- **Rule ID**: `encryption-required`
- **Purpose**: Ensures sensitive data is encrypted
- **Severity**: Error
- **What it checks**:
- Required encrypted fields
- Encryption indicators
## Running the Example:
### Validate Secure Configurations:
```bash
# Validate development config (should pass)
praetorian validate config-dev.yaml
# Validate production config (should pass)
praetorian validate config-prod.yaml
```
### Validate Insecure Configuration:
```bash
# Validate insecure config (should fail with security errors)
praetorian validate config-insecure.yaml
```
## Expected Results:
### ✅ Secure Configurations (config-dev.yaml, config-prod.yaml):
- **Result**: SUCCESS
- **Security checks passed**: All security rules pass
- **No hardcoded secrets**: Uses environment variables
- **Proper encryption**: Sensitive data is encrypted
- **Secure permissions**: Files have appropriate permissions
### ❌ Insecure Configuration (config-insecure.yaml):
- **Result**: FAILURE
- **Security violations detected**:
- Hardcoded secrets (API keys, passwords, tokens)
- Forbidden keys (adminPassword, rootPassword)
- Missing encryption
- No SSL configuration
- Weak authentication methods
- Logging sensitive data
## Security Best Practices Demonstrated:
### ✅ DO (Secure Examples):
1. **Use Environment Variables**: `${API_KEY}`, `${DB_PASSWORD}`
2. **Enable Encryption**: `encryption: true`, `algorithm: "AES-256-GCM"`
3. **Use HTTPS**: `https://api.example.com`
4. **Implement SSL**: `ssl: true`, `minTlsVersion: "1.2"`
5. **Secure Logging**: Exclude sensitive fields, use structured logging
6. **Rate Limiting**: `rateLimit: { enabled: true }`
7. **Input Validation**: Validate all inputs
8. **Secure Headers**: HSTS, CSP, X-Frame-Options
### ❌ DON'T (Insecure Examples):
1. **Hardcode Secrets**: `apiKey: "sk-1234567890abcdef"`
2. **Use Weak Encryption**: `algorithm: "DES"`
3. **Disable SSL**: `ssl: false`
4. **Log Sensitive Data**: Include passwords in logs
5. **Use HTTP**: `http://api.example.com`
6. **Skip Authentication**: No auth mechanisms
7. **No Rate Limiting**: `rateLimit: { enabled: false }`
## Customizing Security Rules:
You can customize the security rules in `praetorian.yaml`:
```yaml
rules:
- id: "no-hardcoded-secrets"
enabled: true # Enable/disable the rule
severity: "error" # error, warning, info
config:
patterns:
- "your-custom-pattern" # Add custom patterns
excludePatterns:
- "your-exclude-pattern" # Add exclusions
```
## Integration with CI/CD:
Add to your pipeline:
```yaml
- name: Validate Security Configuration
run: |
praetorian validate config-prod.yaml
if [ $? -ne 0 ]; then
echo "Security validation failed!"
exit 1
fi
```
This ensures that insecure configurations never reach production.