Vault.md

Here are some best practices for managing secrets in applications using a centralized secrets management system: - Compliance - Implement policies to ensure secrets meet regulatory and compliance requirements such as PCI DSS, HIPAA, GDPR, etc. Require encryption of secrets both at rest and in transit. - Rotation - Rotate secrets regularly, such as every 90 days for credentials and annually for certificates. Set shorter rotation periods for highly privileged secrets. Automate rotation where possible. - Length - Set minimum length requirements for secrets, such as at least 16 characters for passwords and 32 characters for API keys. The longer the better. - Complexity - Require secrets to have a complex composition of upper and lowercase letters, numbers, and symbols. Do not allow dictionary words or personal information. - Lifetime - Set secret expiration policies. Credentials could expire after 90 days. Certificates could be valid for 365 days. Temporary secrets could expire in hours or days. - Access management - Use least privilege principles to restrict access to secrets. Limit applications and infrastructure to only the secrets needed. - Auditing - Log and audit access to and changes made to secrets. Send alerts on suspicious activity. - Backups - Ensure secrets are properly backed up for disaster recovery, and backup systems are hardened. - Testing - Scan for exposed secrets and weak or default passwords in code and systems. Test rotation procedures. - Documentation - Document secrets management policies and procedures for applications teams to follow. With thoughtful policies, automation, and central management, organizations can securely implement secrets in applications while meeting compliance obligations.

Here is a table outlining requirements for different types of secrets: | Secret Type | Length | Complexity | Rotation | Access | |-|-|-|-|-| | Passwords | 12+ characters | Mixed case letters, numbers, symbols | 90 days | Restrict to service accounts | | API keys | 32+ characters | Random alphanumerics | 180 days | Restrict to calling applications | | SSH keys | 2048+ bit key | Securely generated | 365 days | Restrict to user accounts | | Certificates | 2048+ bit key | Generated by CA | 365 days | Restrict to required hosts | | Encryption keys | 256+ bit key | Cryptographically secure | 180 days | Restrict to required services | | Access tokens | 32+ characters | Random alphanumerics + symbols | 24 hours | Code generates, destroys tokens | | Database credentials | Auto-generated | Configured by DBA | 180 days | Restrict to app databases | | Admin credentials | 16+ characters | Complex composition | 60 days | Restrict to designated admins | | Application secrets | 32+ characters | Auto-generated | 90 days | Load via secure config | The table covers common secret types with general recommendations for: - Minimum length and complexity - How frequently secrets should rotate - Strict access controls and least privilege - Automated generation and management where possible Policies should be tailored to your specific compliance, security and operational requirements.

Here is the table updated to include how the different secret types could be handled in Hashicorp Vault:

Secret Type	Length	Complexity	Rotation	Access	Vault Usage
Passwords	12+ characters	Mixed case letters, numbers, symbols	90 days	Restrict to service accounts	Dynamic Secret
API keys	32+ characters	Random alphanumerics	180 days	Restrict to calling applications	Dynamic Secret
SSH keys	2048+ bit key	Securely generated	365 days	Restrict to user accounts	Manage SSH Keys
Certificates	2048+ bit key	Generated by CA	365 days	Restrict to required hosts	Manage Certificates
Encryption keys	256+ bit key	Cryptographically secure	180 days	Restrict to required services	Manage Encryption Keys
Access tokens	32+ characters	Random alphanumerics + symbols	24 hours	Code generates, destroys tokens	Dynamic Secret
Database credentials	Auto-generated	Configured by DBA	180 days	Restrict to app databases	Dynamic Secret
Admin credentials	16+ characters	Complex composition	60 days	Restrict to designated admins	Dynamic Secret
Application secrets	32+ characters	Auto-generated	90 days	Load via secure config	Static Secret

• Passwords, API keys, database credentials, etc. are well suited for dynamic secrets in Vault.

• SSH keys, certificates, encryption keys benefit from dedicated management and rotation in Vault.

• Application configuration secrets can be stored as static secrets.

This aligns secret types to appropriate Vault capabilities for secure lifecycle management.

Here is how I would divide LDAP and static passwords in the secrets table:

Secret Type	Length	Complexity	Rotation	Access	Vault Usage
LDAP Passwords	12+ characters	Mixed case letters, numbers, symbols	90 days	Restrict to service accounts	Dynamic Secret
Static Passwords	16+ characters	Complex composition	60 days	Restrict to designated admins	Static Secret

• LDAP passwords that are used for service account authentication should be dynamic secrets with regular rotation.

• Static passwords that are embedded in application code or configs should have longer length and complexity requirements. They can be stored as static secrets since the application expects these to remain static.

• For both types, enforce access controls to only authorized users/services.

• LDAP passwords require more frequent rotation as they are used for ongoing authentication.

• Static passwords can have less frequent rotation, but longer length for additional entropy.

This divides password secrets appropriately based on how they are used - for authentication or as embedded static secrets. Vault usage and rotation aligns to those use cases.

Here is the table updated to include how the different secret types could be handled in Hashicorp Vault:

Secret Type	Length	Complexity	Rotation	Access	Vault Usage
Passwords	12+ characters	Mixed case letters, numbers, symbols	90 days	Restrict to service accounts	Dynamic Secret
API keys	32+ characters	Random alphanumerics	180 days	Restrict to calling applications	Dynamic Secret
SSH keys	2048+ bit key	Securely generated	365 days	Restrict to user accounts	Manage SSH Keys
Certificates	2048+ bit key	Generated by CA	365 days	Restrict to required hosts	Manage Certificates
Encryption keys	256+ bit key	Cryptographically secure	180 days	Restrict to required services	Manage Encryption Keys
Access tokens	32+ characters	Random alphanumerics + symbols	24 hours	Code generates, destroys tokens	Dynamic Secret
Database credentials	Auto-generated	Configured by DBA	180 days	Restrict to app databases	Dynamic Secret
Admin credentials	16+ characters	Complex composition	60 days	Restrict to designated admins	Dynamic Secret
Application secrets	32+ characters	Auto-generated	90 days	Load via secure config	Static Secret

• Passwords, API keys, database credentials, etc. are well suited for dynamic secrets in Vault.

• SSH keys, certificates, encryption keys benefit from dedicated management and rotation in Vault.

• Application configuration secrets can be stored as static secrets.

This aligns secret types to appropriate Vault capabilities for secure lifecycle management.

Here are some key steps in managing secrets for an application squad using HashiCorp Vault:

Define Secrets - The application squad should analyze what secrets are needed for their apps and systems. This could include database passwords, API keys, SSH keys, etc. A secrets management policy should define what kinds of secrets can be stored in Vault.

Establish Vault Infrastructure - Provision and configure a Vault server and storage backend. Set up Vault authentication methods and access control policies. Enable desired secrets engines in Vault like kv, transit, etc.

Create Secrets - Application developers/ops can use the Vault CLI or API to create new secrets in Vault. Secrets are stored encrypted. Vault transit engine can be used to generate dynamic secrets.

Maintain/Rotate Secrets - Secrets should be periodically rotated based on security policy (e.g. every 90 days). Vault has automatic rotation for some engines. Developers retrieve latest secrets when needed.

Revoke Access - When an employee leaves the squad, the Vault administrator can revoke their Vault token to remove access. Tokens can have timed expiration via Vault policies.

Delete Secrets - Old or invalid secrets can be deleted from Vault. Vault has functionality like shred to completely remove secrets.

Audit Logs - All interactions with Vault are logged for auditing and monitoring. Review logs to detect unauthorized access.

In summary, Vault provides a secure and controlled lifecycle for managing an application squad's secrets throughout their definition, creation, use, rotation, and deletion. Proper policies and controls need to be implemented.