Secret Management Architectures
•Download as PPTX, PDF•
1 like•618 views
The document discusses recommendations for improving security when secrets are stored in plain text. It provides an overview of different tools that can be used to encrypt and manage secrets, including Git-crypt, KeyBase, AWS KMS, Azure Key Management, and HashiCorp Vault. The document compares different approaches to securing secrets from limited access in plain text to limited access with encryption and encryption with centralized management. It also outlines some common questions around rotating, auditing, and accessing secrets securely across different environments.
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Secret Management Architectures
Similar to Secret Management Architectures (20)
More from Stenio Ferreira
More from Stenio Ferreira (19)
Recently uploaded
Recently uploaded (20)
Secret Management Architectures
- 1. Stenio Ferreira - CrossMarket May 2017
- 2. You are in a project were secrets are kept in plain text Client wants recommendations on how to improve security You want to learn about different tools available to manage secrets
- 3. ● ● ● ● ● ●
- 4. 5 2 4 1 Server instances hosted by Amazon. Works as a virtual computer. Images that can be used to build an AWS EC2. Works as a snapshot of a computer with all configurations and installed apps. Access Control Lists. Defines which users/apps have read/write access to which resources. Time to live. Time before a resource expires and becomes unusable. 54 4 Amazon’s Key Management System 3 Information Security Management System. Set of policies and procedures for systematically managing an organization's sensitive data. 6
- 5. Complexity and robustness impacted not only by specific tools, but also by how they are used together in the architecture. • External threats? • Internal threats? • Multiple Datacenters? • Team skills? • Platform flexibility? • Auditing? Implementation complexity Security robustness
- 6. • What happens when an employee leave? Is it easy to update secrets? • What happens if security breach detected? How fast can we address it? • What happens if external party has access to a secret? For how long is it a threat? • Can we audit who accessed a particular secret last month? • Do different cloud platforms and apps need to access the secret? • What happens if secret is unavailable? • Do we need different access levels for different secret groups? For example outsourced developers do not have access to prod secrets
- 7. 1 Limited Access Plain text secrets 2 Limited Access Encrypted secrets 3 Limited Access Encrypted secrets Management (ACL, TTL, etc)
- 8. 1 1 - Simple - Only one layer of defense against external threats - No defense against internal threats - Hard to rotate secrets - No auditing Limited Access Plain text secrets
- 9. 1 1 - Simple - Two layers of defense against external threats - No defense against internal threats - Hard to rotate secrets - No auditing - Limited options on key sharing Limited Access Encrypted secrets
- 10. 1 1 - ACL, TTL - “Easy” to rotate secrets - Auditing - API access to secrets - Complexity 1 Limited Access Encrypted secrets Managed
- 11. Encryption • Git-crypt: specify files to be encrypted in a git repository. • KeyBase: similar to dropbox, enables easy sharing of secrets. • Encryption at rest (S3 encryption, etc): platform-based. Management ACL Rotation Access TTL Auditing Chef Vault x x Hashicorp Vault x x x x AWS KMS x x Azure Key Managent
- 24. Encryption (can replace “stenio” for file://my-pem.pem for example • aws kms encrypt --key-id 9cb09774-8dc5-4c6d-9942-0459e9864a12 --plaintext "stenio" --query CiphertextBlob -- output text --region us-east-1 | base64 --decode > encrypted.key Decryption • aws kms decrypt --ciphertext-blob fileb://encrypted.key --query Plaintext --output text --region us-east-1 | base64 -- decode
- 25. git fetch <your-master-branch> git checkout --ours -- <conflicting-encrypted-file> git diff origin/master -- <conflicting-encrypted-file> # this will help you 1) restore the original file; # then 2) see the differences - you will have to make manual edits
- 26. Auth Backends - Token - AWS EC2 - LDAP - AppId - Username/password - Github - … Secret Backends - AWS S3 - Consul - MongoDB - Postgres - … Audit Backends • File • Syslog Vault Server
- 27. 1. Install Download CLI Update Config (secret backend) Init as Server Store Unseal & Root Tokens 2. Configure 3. Seed Unseal Vault Login w/ Root Token Seed Vault Configure Enable auth backend Seed Policies Create users w/ policies Seed secrets Enable audit backend
- 28. Where to store source of truth? • What is the source of the secrets? • Potential solution: git-crypt • Allows multiple keys (dev/stg/prod) How to automate seeding? • Official docs describe manual process • Solution: helper script • There are Ruby gems, API endpoints and supporting libraries to make this easier How to authenticate nodes? • How to give credentials to new node? • Potential solution: bootstrap script • AWS cloud-init/ user data How to automate installation? • Unseal operation is challenging to automate • Potential solution: Keybase • Additional complexity
Editor's Notes
- 1- Not deep detail 2- Architecture + workflow 3- Secrets – sensitive strings
- AWS Security Best practices
- If you want to copy these shades into new shapes use the eyedropper tool in the shape or text fill drop down menu
- Encapsulating an encryption key
- Install -> Configure -> Seed
- 2 things: encryption and seeding in chef server. Git hook, new secrets would trigger Jenkins. How this would happen? (next)
- This is the jenkins job that seeded the secrets clone, decrypt, seed with query Determines which nodes have access to secrets
- However access list is static, so This is the key, refreshes access list
- Vault backends, pluggable
- Small script to seed vaautl and control git-crypt keys
- Authentication and provisioning
- Vault backends, pluggable