Kafka Security Posture Audit

Audits Kafka security configuration across the codebase and infrastructure. Kafka clusters often start as PLAINTEXT in dev and never get properly secured for production.

Target environment: $ARGUMENTS

Workflow

Copy this checklist and track your progress:

Security Audit Progress:
- [ ] Step 1: Check environment health and tier
- [ ] Step 2: Scan codebase for security configuration
- [ ] Step 3: Audit authentication
- [ ] Step 4: Audit encryption
- [ ] Step 5: Audit secrets management
- [ ] Step 6: Generate report

1. Check environment health and tier via Lenses MCP
2. Scan codebase for security-related configuration (see references/security-properties.md)
3. Audit authentication (SASL mechanism)
4. Audit encryption (SSL/TLS)
5. Audit secrets management (hardcoded credentials)
6. Report findings with severity calibrated to environment tier

Step 1: Environment Context

Use Lenses MCP tools to understand the environment:

• check_environment_health - verify environment is healthy and agent is connected
• get_environment - get environment tier (development, staging, production) to calibrate severity levels. A PLAINTEXT connection in dev is a suggestion; in production it's critical.

Expected output: Environment tier (development/staging/production) and health status.

Validation: If the environment tier cannot be determined, default to production-level severity - it is safer to over-report.

Step 2: Codebase Inspection

Search the codebase for Kafka security configuration. Consult references/security-properties.md for the full list of authentication properties, encryption properties and files to scan.

Step 3: Audit Authentication

Apply the authentication audit rules from references/security-properties.md. Key checks:

• PLAINTEXT protocol in production (critical)
• PLAIN SASL without TLS (critical)
• No authentication configured in production (critical)
• Weak SASL mechanisms (warning)

Step 4: Audit Encryption

Apply the encryption audit rules from references/security-properties.md. Key checks:

• No SSL/TLS in production (critical)
• Disabled hostname verification (warning)
• Plaintext keystore passwords (warning)

Step 5: Audit Secrets Management

Apply the secrets audit rules from references/security-properties.md. Key checks:

• Hardcoded credentials in source files (critical)
• Credentials tracked by git (critical)
• Missing .gitignore entries (warning)

Step 6: Environment Tier Mismatch

Cross-reference findings with the environment tier from Lenses:

• Production/Staging: All findings at full severity
• Development: Downgrade encryption/auth findings to suggestions (acceptable for local dev)
• Flag any development environment configs that might accidentally be used in production

Success Criteria

Quantitative

• Triggers on 90% of security-related queries (test with 10-20 varied phrasings)
• Completes audit in under 12 tool calls (MCP + codebase search)
• 0 failed MCP calls per run

Qualitative

• Severity is correctly calibrated to environment tier (dev vs production)
• Secrets findings have zero false negatives (never misses a hardcoded credential)
• Every finding includes a risk description and remediation step

Examples

Example 1: Pre-production security review

User says: "Audit Kafka security for the production environment"

Actions:

1. Get environment tier (production) from Lenses MCP
2. Scan codebase for all security properties
3. Apply full-severity rules for production

Result: Complete security audit report with all findings at production severity

Example 2: Development environment check

User says: "Is my dev Kafka cluster secure enough?"

Actions:

1. Get environment tier (development) from Lenses MCP
2. Scan codebase for security properties
3. Downgrade auth/encryption findings to suggestions for dev
4. Keep secrets findings at full severity (credentials should never be hardcoded)

Result: Report calibrated to development environment

Example 3: Secrets-focused audit

User says: "Check if there are any hardcoded Kafka credentials in the codebase"

Actions:

1. Search for secret patterns (passwords, tokens, API keys)
2. Check .env files tracked by git
3. Verify .gitignore includes credential files

Result: Focused report on secrets management only

Troubleshooting

Environment tier is unknown

Cause: Lenses get_environment returns no tier or a custom tier value. Solution: Default to production-level severity. It is safer to over-report than under-report security issues.

Cannot determine if .env files are tracked by git

Cause: Not running inside a git repository. Solution: Check for .env files and report their presence. Note that git tracking could not be verified.

False positives in secrets scan

Cause: Words like "password" appear in documentation or comments rather than actual credentials. Solution: Report all findings but note the confidence level. Flag inline values as high confidence and reference-only mentions as low confidence.

Output Format

## Security Audit Report

### Environment: {name} (tier: {development|staging|production})

### Critical (must fix)
- [file:line] Description of the security issue
  Risk: {what could go wrong}
  Remediation: {how to fix}

### Warning (should fix)
- [file:line] Description of the issue
  Risk: {what could go wrong}
  Remediation: {how to fix}

### Suggestion (consider improving)
- [file:line] Description of the issue
  Recommendation: {how to improve}

### Summary
- X critical issues found
- Y warnings found
- Z suggestions found
- Environment tier: {tier}
- Authentication: {configured|missing}
- Encryption: {configured|missing}
- Secrets exposed: {yes|no}