Kafka security audit

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}