| name | GitLab Stack Secrets Manager |
| description | Manages Docker secrets for GitLab stack projects, ensuring secrets are never in .env or docker-compose.yml, properly stored in ./secrets directory, and securely integrated with Docker secrets. Use when users need to create secrets, migrate from environment variables, validate secret configuration, audit secret usage, or ensure secrets are never committed to git. |
GitLab Stack Secrets Manager
This skill manages secrets for GitLab stack projects, ensuring secrets are stored securely, never exposed in configuration files, and properly integrated with Docker secrets.
When to Use This Skill
Activate this skill when the user requests:
- Create or manage Docker secrets
- Migrate environment variables to Docker secrets
- Validate secret configuration and permissions
- Audit secret usage and detect leaks
- Ensure secrets aren't in .env or docker-compose.yml
- Check if secrets are exposed in git
- Generate secure random secrets
- Rotate existing secrets
- Fix secret-related security issues
Core Security Principles
CRITICAL RULES - Never violated:
- No Secrets in .env: Secrets MUST NEVER be in .env file
- No Secrets in docker-compose.yml: No plaintext secrets in environment variables
- ./secrets Directory: All secrets in ./secrets with 700 permissions
- Secret Files: Individual files with 600 permissions
- Git Protection: ./secrets/* in .gitignore, never committed
- Proper Ownership: All files owned by Docker user (not root)
- Docker Secrets Only: Use Docker secrets mechanism exclusively
Secret Management Workflow
Phase 1: Understanding User Intent
Step 1: Determine the Operation
Ask yourself what the user wants to do:
- Create new secrets?
- Migrate existing environment variables to secrets?
- Validate current secret configuration?
- Audit secrets for leaks or issues?
- Update or rotate existing secrets?
- Remove secrets?
Step 2: Gather Context
Check current project state:
- Does ./secrets directory exist?
- Does docker-compose.yml exist?
- Does .env file exist?
- Is this part of stack-validator findings?
Review docker-compose.yml:
- Any secrets already defined?
- Any environment variables that look like secrets?
- Which services need secrets?
Scan for security issues:
- Secrets in .env?
- Secrets in docker-compose.yml environment variables?
- Secrets tracked in git?
Phase 2: Secret Creation
When: User wants to create new secrets
Step 1: Validate Prerequisites
- Check if ./secrets directory exists:
ls -ld ./secrets - If missing, create with proper permissions:
mkdir -p ./secrets chmod 700 ./secrets
Step 2: Determine Secret Details
Ask the user (or infer from context):
- Secret name (e.g., db_password, api_key)
- How to generate:
- User provides value
- Generate random value
- Generate from pattern
- Format requirements (alphanumeric, hex, base64, etc.)
- Length requirements
Step 3: Create Secret File
- Generate or accept secret value
- Create file in ./secrets:
echo -n "secret-value" > ./secrets/secret_name - Set proper permissions:
chmod 600 ./secrets/secret_name - Verify ownership (should not be root)
Step 4: Update docker-compose.yml
Add to top-level secrets section:
secrets: secret_name: file: ./secrets/secret_nameAdd to appropriate service:
services: myservice: secrets: - secret_name
Step 5: Verify .gitignore
Ensure ./secrets is excluded:
/secrets/
/secrets/*
!secrets/.gitkeep
Phase 3: Secret Validation
When: User wants to validate secret configuration, or as part of other operations
Step 1: Directory Structure Validation
Check ./secrets exists:
[ -d ./secrets ] && echo "exists" || echo "missing"Check permissions (should be 700):
stat -c "%a" ./secrets # Linux stat -f "%OLp" ./secrets # macOSCheck ownership (not root):
ls -ld ./secrets
Step 2: Secret Files Validation
List all secret files:
find ./secrets -type f ! -name .gitkeepFor each file, check:
- Permissions (should be 600)
- Ownership (not root)
- Not empty
- Readable
Step 3: docker-compose.yml Validation
Parse secrets section:
- List all defined secrets
- Verify files exist for each secret
Check service secret references:
- All referenced secrets are defined
- Services use
secrets:key, not environment vars
CRITICAL: Scan for secrets in environment variables:
- Look for patterns: PASSWORD, SECRET, KEY, TOKEN, API
- Flag any that look like secrets
- These MUST be migrated
Step 4: .env File Validation
CRITICAL: Scan .env for secrets:
- Pattern matching: PASSWORD, SECRET, KEY, TOKEN, API
- Long random-looking strings
- Base64-encoded values
- Any value that should be a secret
If secrets found in .env:
- This is a CRITICAL security issue
- List all detected secrets
- Recommend immediate migration
Step 5: Git Safety Check
Verify .gitignore excludes ./secrets:
grep -q "secrets" .gitignoreCheck if any secrets are staged:
git status --porcelain | grep secrets/Check git history for secrets (if requested):
git log --all --full-history -- ./secrets/
Step 6: Generate Validation Report
🔐 Secrets Validation Report
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📁 Directory Structure
✅ ./secrets exists with 700 permissions
✅ Owned by user (1000:1000)
✅ ./secrets in .gitignore
📄 Secret Files (3)
✅ db_password - 600 permissions, 32 bytes
✅ api_key - 600 permissions, 64 bytes
⚠️ jwt_secret - 644 permissions (should be 600)
🐳 Docker Integration
✅ 3 secrets defined in docker-compose.yml
✅ All secret files exist
⚠️ Service 'worker' uses docker-entrypoint.sh
❌ CRITICAL SECURITY ISSUES
❌ .env contains secrets:
* DB_PASSWORD=supersecret123
* API_KEY=sk_live_abc123
** IMMEDIATE ACTION REQUIRED **
❌ docker-compose.yml environment variables contain secrets:
* Service 'app' - JWT_SECRET in environment
** MUST MIGRATE TO DOCKER SECRETS **
✅ Git Safety
✅ No secrets in git staging
✅ .gitignore properly configured
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Status: FAILED (2 critical issues)
🔧 IMMEDIATE ACTIONS REQUIRED
1. Migrate secrets from .env to Docker secrets
2. Remove secrets from docker-compose.yml environment
3. Fix permissions on jwt_secret file
Phase 4: Secret Migration
When: Secrets found in .env or docker-compose.yml environment variables
CRITICAL: This is a security issue that must be fixed
Step 1: Identify Secrets to Migrate
Scan .env for secret patterns:
grep -E "(PASSWORD|SECRET|KEY|TOKEN|API)" .envScan docker-compose.yml environment sections:
# Look for patterns in environment variablesList all detected secrets with:
- Variable name
- Current location (.env or compose)
- Current value (for migration)
- Suggested secret name
Step 2: Confirm with User
Present findings and ask:
- Which variables should be migrated?
- Confirm secret names
- Confirm it's safe to remove from .env/compose
Step 3: Create Secret Files
For each secret to migrate:
- Extract current value
- Create secret file:
echo -n "$value" > ./secrets/secret_name chmod 600 ./secrets/secret_name - Add to docker-compose.yml secrets section
Step 4: Update Service Configurations
For each service using the secret:
- Add to service secrets list
- Remove from environment variables
- If container supports
_FILEsuffix:environment: DB_PASSWORD_FILE: /run/secrets/db_password - If container doesn't support native secrets:
- Create or update docker-entrypoint.sh
- Document this requirement
Step 5: Clean Up
- Remove secrets from .env:
- Either delete the lines
- Or comment them out with migration note
- Remove from docker-compose.yml environment
- Verify .env.example doesn't have secret values
Step 6: Verification
- Test that services start correctly
- Verify services can access secrets
- Confirm no secrets remain in .env or compose
- Run validation to confirm
Phase 5: Secret Generation
When: Need to generate secure random secrets
Step 1: Determine Format Requirements
Common formats:
- Alphanumeric: Letters and numbers (default)
- Hex: Hexadecimal (0-9, a-f)
- Base64: Base64 encoding
- Numeric: Numbers only
- UUID: UUID v4 format
Step 2: Determine Length
Standard lengths:
- Database passwords: 32-64 characters
- API keys: 32-64 characters
- JWT secrets: 64 characters (or 32 bytes base64)
- Session secrets: 32 characters
- Encryption keys: 32 bytes (256-bit)
Step 3: Generate Secret
Use cryptographically secure methods:
# Alphanumeric (32 chars)
openssl rand -base64 32 | tr -d '/+=' | head -c 32
# Hex (64 chars)
openssl rand -hex 32
# Base64 (32 bytes)
openssl rand -base64 32
# UUID
uuidgen
# Custom (e.g., 16 alphanumeric)
LC_ALL=C tr -dc 'A-Za-z0-9' < /dev/urandom | head -c 16
Step 4: Store Securely
- Write to file (no trailing newline):
echo -n "$secret" > ./secrets/secret_name - Set permissions:
chmod 600 ./secrets/secret_name
Phase 6: Secret Auditing
When: User wants to audit secret usage, find leaks, or review security
Step 1: Secret Inventory
List all secrets with details:
- Name
- File path
- File size
- Permissions
- Owner
- Created date (if available)
- Last modified
Step 2: Usage Analysis
For each secret:
- Check if defined in docker-compose.yml
- List services using it
- Check if file exists
- Verify it's actually used
Step 3: Find Unused Secrets
- Secrets defined but not used in any service
- Secret files that aren't in docker-compose.yml
- Suggest removal or documentation
Step 4: Leak Detection
Check common leak locations:
.env file (CRITICAL):
grep -E "(PASSWORD|SECRET|KEY|TOKEN)" .envdocker-compose.yml environment (CRITICAL):
- Scan all environment sections
- Flag any secrets
Configuration files:
grep -r "password\|secret\|key" ./config/Git history:
git log -p --all -S "secret-pattern"Docker logs:
- Check recent logs for secret exposure
Step 5: Permission Audit
Check all files in ./secrets:
find ./secrets -type f -not -perm 600Check directory permissions:
[ "$(stat -c '%a' ./secrets)" = "700" ]Check ownership:
find ./secrets -user root
Step 6: Generate Audit Report
Include:
- Total secrets count
- Usage statistics
- Security issues found
- Recommendations
- Risk assessment
Phase 7: docker-entrypoint.sh Generation
When: Container doesn't support native Docker secrets
Step 1: Determine Necessity
Check if container supports secrets:
- PostgreSQL, MySQL, MariaDB: Support
_FILEsuffix ✅ - Redis: Native secret support ✅
- MongoDB: Native secret support ✅
- Most modern containers: Check documentation
Only create entrypoint if:
- Container expects environment variables only
- No
_FILEsuffix support - No native /run/secrets/ reading
Step 2: Identify Required Secrets
List secrets that need to be loaded:
- Secret name (in ./secrets/)
- Environment variable name
- Service name
Step 3: Generate Entrypoint Script
#!/bin/bash
set -e
# Function to load secrets from docker secrets into environment
load_secret() {
local secret_name=$1
local env_var=$2
local secret_file="/run/secrets/${secret_name}"
if [ -f "$secret_file" ]; then
export "${env_var}=$(cat "$secret_file")"
echo "Loaded secret: $secret_name -> $env_var"
else
echo "ERROR: Secret file $secret_file not found!" >&2
exit 1
fi
}
# Load all required secrets
load_secret "db_password" "DB_PASSWORD"
load_secret "api_key" "API_KEY"
load_secret "jwt_secret" "JWT_SECRET"
# Execute the main command
exec "$@"
Step 4: Set Permissions
chmod +x docker-entrypoint.sh
Step 5: Update docker-compose.yml
services:
myservice:
entrypoint: /docker-entrypoint.sh
command: ["original-command"]
volumes:
- ./docker-entrypoint.sh:/docker-entrypoint.sh:ro
secrets:
- db_password
- api_key
Step 6: Document
Add comment explaining why entrypoint is needed:
# docker-entrypoint.sh required because this container
# doesn't support Docker secrets natively
Communication Style
When managing secrets:
- Be Security-Focused: Emphasize security at every step
- Be Clear About Risks: Explain why secrets in .env/compose is dangerous
- Be Urgent About Critical Issues: Don't downplay security problems
- Be Helpful: Provide exact commands to fix issues
- Be Thorough: Check all potential leak locations
- Be Educational: Explain why Docker secrets are better
- Never Display Secret Values: Show "[REDACTED]" instead
Critical Validation Points
These are must-pass security criteria:
- ✅ NO secrets in .env file
- ✅ NO secrets in docker-compose.yml environment variables
- ✅ ./secrets directory exists with 700 permissions
- ✅ All secret files have 600 permissions
- ✅ ./secrets/* in .gitignore
- ✅ No secrets tracked in git
- ✅ No root-owned secret files
- ✅ All referenced secrets exist
- ✅ docker-entrypoint.sh only when truly necessary
Integration with Companion Skills
stack-validator
- Stack-validator calls this skill for secret validation
- Validates that secrets follow proper patterns
- Detects secrets in .env and compose files
stack-creator
- Creates ./secrets directory with proper setup
- Generates .gitkeep file
- Sets up .gitignore correctly
- Creates initial secret placeholders
config-generator
- Ensures configs don't contain secrets
- References secrets properly
- Uses environment variables for non-secrets only
Important Notes
- Read-Only for Secrets: NEVER display actual secret values to user
- Security First: Always prioritize security over convenience
- Migration Required: Secrets in .env/compose MUST be migrated
- No Shortcuts: Always follow security best practices
- Verify Everything: Check permissions, ownership, git status
- Companion-Aware: Work with other skills seamlessly
Example Workflow: Complete Secret Setup
User: "Set up secrets for my database"
1. Check current state
- ./secrets missing → create it
- docker-compose.yml has DB_PASSWORD in environment → CRITICAL ISSUE
2. Report findings:
"I found a critical security issue: DB_PASSWORD is in docker-compose.yml
environment variables. I'll migrate this to Docker secrets."
3. Migration:
- Extract password value
- Create ./secrets/db_password
- chmod 600 ./secrets/db_password
- Update docker-compose.yml secrets section
- Update postgres service to use secrets
- Remove from environment
4. Verification:
- Run validation
- Confirm no secrets in compose
- Check .gitignore
- Verify permissions
5. Report:
"✅ Database password now secured with Docker secrets
✅ Removed from docker-compose.yml environment
✅ File permissions set correctly
✅ Added to .gitignore"
This skill ensures secrets are managed securely and never exposed in configuration files or version control.