application_security/secrets

92 notes in this subject, read out of this brain and free to use. This is page 2 of 2.

Container Secrets Injection - Mounted Volumes

Secrets can be provided via mounted volumes (file method). Keep secrets in config/secret files and mount them as volumes to instances. Ensure these mounts are mounted by the orchestrator during deployment, never built-in, to prevent secret leakage with the container definition.

Container Secrets Injection - Fetch from Secret Store

A sidecar app/container can fetch secrets directly from a secret manager service without dealing with docker config. This allows dynamically constructed secrets without secrets being viewable from the file system or Docker environment variables.

Container Secrets Injection - Environment Variables

Secrets can be provided as Docker container environment variables, but this method has significant limitations. Secrets should never be hardcoded using docker ENV or docker ARG commands as these leak with the container definition. Instead, let an orchestrator overwrite environment variables with actual secrets at deployment. Environment variables are generally accessible to all processes and may be included in logs or system dumps. This method is not recommended unless other methods are not possible.

Short-Lived Sidecar Containers for Secrets

Create short-lived sidecar containers that fetch secrets from remote endpoints and store them on shared volumes mounted to the main container. The main container uses secrets from the mounted volume. Benefits: no need to integrate third-party tooling into the main application. Once the sidecar fetches secrets, it terminates. Examples: Vault Agent Sidecar Injector, Conjur Secrets Provider. Secrets mounted to shared pod volumes allow containers to consume secrets without being aware of the secrets manager.

Container Secrets - Internal vs External Access

Secrets should only be exposed to communication mechanisms between container and deployment representation (e.g., Kubernetes Pod). Never expose secrets through external access mechanisms shared among deployments or orchestrators (e.g., shared volumes). When orchestrator stores secrets (e.g., Kubernetes Secrets), ensure the storage backend is encrypted and keys are managed well.

Dynamic vs Static Secrets - Use Cases

Dynamic secrets use cases: short-lived secrets for secondary services (API keys, credentials) expressing intent for connecting primary service to the service; short-lived integrity and encryption controls for guarding in-memory and runtime communication (session-only encryption keys); short-lived credentials for deployment stack building. Dynamic secrets often require long-term static secrets to create them. Static secrets use cases: key material needing longer lifetime due to usage nature in interaction with other service instances (storage encryption keys, TLS PKI keys); credentials for services not supporting temporal roles or credentials.

Secrets Management Access Limitations - Policy and Separation

Secrets should never be retrievable by everyone and everything. Put guardrails in place: Create access policies to limit entities that can read or write secrets, ensuring easy extensibility and understandability; If reducing access within a solution is not possible, separate production and development secrets by using separate secret management solutions with reduced access to production secrets.

Security Event Monitoring for Secrets Access

Continually monitor who/what, from which IP, and what methodology accesses secrets. Pattern detection: Monitor secret access at the management system—is this normal behavior? Alert if CI/CD credentials access from unexpected IP; Monitor the consuming service for expected IP and user agent. Alert and assume compromise if not matching expected patterns.

Usability and Ease of Onboarding for Secrets Management

For secrets management adoption, usability is critical. If too complex, developers resort to insecure practices. Focus on: Clear comprehensive documentation with tutorials, API references, examples, and 'getting started' guides; Developer-friendly SDKs for various languages, CLI tools for local management, IDE plugins and CI/CD integration; Self-service workflows enabling developers to request secrets with minimal intervention; GitOps workflows managing secrets as code alongside application code; Automated approval for low-risk secrets while maintaining controls for sensitive ones; Clear error messages for independent troubleshooting, dedicated support channels; Easy integration with existing applications using sidecars like Vault Agent Sidecar Injector.

Encryption Types for Secrets - Recommended Algorithms

Secrets must be stored encrypted using algorithms providing sufficient security, including resistance against quantum computing-based attacks. Select algorithms providing both encryption and confidentiality: AES-256 using GCM (Galois Counter Mode), or ChaCha20 and Poly1305 combination. Refer to current sources like keylength.com and NSA's Commercial National Security Algorithm Suite 2.0 for quantum-resistant algorithm recommendations.

Convergent Encryption for Secrets Detection

Convergent Encryption ensures that the same plaintext and key results in the same ciphertext. This helps detect possible reuse of secrets (same ciphertext indicates same secret). Challenge: enables attackers to generate cryptographic strings matching secrets, deriving plaintext. Mitigate by ensuring convergent crypto system has sufficient resource challenges during encryption. Additional factor reducing risk is ensuring adequate secret length, hampering guess-iteration time required.

Secrets Encryption Keys - Storage Location

Do not store encryption keys next to the secrets they encrypt, except if those keys are encrypted themselves (envelope encryption). Consult the Key Management Cheat Sheet for where and how to store encryption and HMAC keys.

Automated key rotation for multi-cloud

Implement automated key rotation processes to ensure that keys are rotated consistently and securely across all cloud providers. Use tools and scripts to automate the rotation process and reduce the risk of human error.

Encryption as a Service (EaaS)

EaaS is a model where users subscribe to cloud-based encryption services without installing encryption on own systems. Benefits: Encryption at rest; Encryption in transit (TLS); Key handling and cryptographic implementations handled by Encryption Service, not developers; Provider can add services to interact with sensitive data.

Secrets Detection - Yelp Detect Secrets Tool

Yelp Detect Secrets is a mature open-source project with signature matching for around 20 secret types. Used for secrets detection in code repositories and development workflows.

Secrets Detection - General Approaches

Shift-left and DevSecOps principles apply to secrets detection. General approaches: Create standard test secrets for universal organization use, reducing false positives by tracking one test secret per type; Enable secrets detection at developer level (IDE, pre-commit hooks) to prevent check-in before commit/PR; Include secrets in threat modeling attack surface; Evaluate detection utilities and signatures regularly; Use multiple detection utilities and correlate results to identify detection weaknesses; Balance entropy with detection ease—consistent formats easier to detect but may miss human-created passwords.

Types of Secrets to Detect

Common secret types requiring detection signatures: High availability secrets (difficult to rotate tokens); Application configuration files; Connection strings; API keys; Credentials; Passwords; 2FA keys; Private keys (SSH keys); Session tokens; Platform-specific types (AWS, Google Cloud).

Secret Lifecycle Detection Rules

Secrets should exist only as long as necessary (rotate often) with automatic rotation methods. They should only be visible to those needing them (least privilege), be revocable with logging of reuse attempts, and never be logged (use encryption or masking). Create detection rules for each secret lifecycle stage.

Secrets Detection Documentation

Create and regularly update documentation informing the developer community about procedures, available systems, expected secrets management, testing methods, and incident response procedures. Documentation should include: Who has access to the secret; How it gets rotated; Upstream/downstream dependencies for rotation; Incident point of contact; Security impact of exposure; How secrets handling may differ by threat risk or data classification.

Incident Response for Secret Exposure - Documentation

Incident response in event of secret exposure must ensure everyone in the custody chain is aware and understands response procedures. This includes application creators (development team), information security, and technology leadership. Documentation must include: How to test for secrets and handling (especially business continuity reviews); Who to alert when secret is detected; Containment steps; Information to log during the event.

Incident Response for Secret Exposure - Containment Goal

Primary goal of incident response for secret exposure is rapid response and containment.

Secret revocation requirements

Keys that were exposed must undergo immediate revocation. The secret must be able to be de-authorized quickly, and systems must be in place to identify the revocation status.

Secret rotation requirements

A new secret must be able to be quickly created and implemented, preferably via an automated process to ensure repeatability, low rate of implementation error, and least-privilege access without direct human readability of secrets.

Secret deletion after revocation

Secrets that are revoked or rotated must be removed from the exposed system immediately, including secrets discovered in code or logs. Secrets in code may have commit history squashed to before the secret's introduction, but this rewrites git history and breaks links to commits. Secrets in logs must have a process for removal while maintaining log integrity.

Multi-cloud secrets management challenges

Managing secrets in a multi-cloud environment presents challenges including: diverse APIs and interfaces across cloud providers, inconsistent security policies, key rotation mechanisms that vary by provider, different access control mechanisms, and varying logging and monitoring capabilities.

Centralized secrets management for multi-cloud

Implement a centralized secrets management solution that can integrate with multiple cloud providers to standardize the management of secrets and enforce consistent security policies across all environments. Examples include HashiCorp Vault and CyberArk Conjur.

Symfony secrets management system

Symfony provides a secrets management system for storing sensitive values like API keys. Secrets are additionally encoded using cryptographic keys. Environment variables with identical names to secrets will override the secret values.

Generate cryptographic keys for secrets

Generate a pair of cryptographic keys for secrets using: 'bin/console secrets:generate-keys'. This command creates key files in config/secrets/env(dev|prod|etc.). The private key file is highly sensitive and should not be committed to the repository.

Set secret value in Symfony

Set a secret value using: 'bin/console secret:set API_KEY'. This command generates a file for the secret in config/secrets/env(dev|prod|etc.).

Access secret values in Symfony code

Secret values can be accessed in code the same manner as environment variables. Note that if environment variables and secrets have identical names, environment variables will always override secrets.

Protect device signing keys during device pairing

It is critically important to provision and protect device signing keys during device pairing as well as the actual signing protocol itself. Malware may attempt to inject, replace, or steal the signing keys.

Protect signing keys with second factor or secure elements

Signing keys should be protected with a second factor such as passwords or biometrics, or by leveraging secure elements such as Trusted Execution Environment (TEE), Trusted Platform Module (TPM), or Smart cards.

Give your agent this brain