The application server for automated deployment with polling a repository. Management linux user and authentication with team or collaborator on Github.
Provides tools necessary to build and deploy reliable, scalable distributed applications ๏Velocity for development delivery with Reliability ๏Scaling Services and Team ๏The abstraction of Infrastructure for Portability ๏Efficient use of resources
Provides tools necessary to build and deploy reliable, scalable distributed applications ๏Velocity for development delivery with Reliability ๏Declarative Configuration ๏Self Healing System ๏Immutability ๏Scaling Services and Team ๏The abstraction of Infrastructure for Portability ๏Efficient use of resources
Provides tools necessary to build and deploy reliable, scalable distributed applications ๏Velocity for development delivery with Reliability ๏Declarative Configuration ๏Self Healing System ๏Immutability ๏Scaling Services and Team ๏The abstraction of Infrastructure for Portability ๏Efficient use of resources }Need to change our system
system ๏Using container images for virtual machine ๏To record the state of machine ๏Easy change the state of machine ๏Running anywhere ๏Easy scaling with auto ๏Provisioning and Deployment changes ๏Secrets management?
๏Fast development cycle ๏Credential sharing, Long lifetime secrets ๏Unmanaged pods ๏Leak secrets easily by logs with exception backtrace or debugging ๏Potentially taking down multiple service tiers at once ๏Members join and leave the team
principle of least privilege (POLP), an important concept in computer security, is the practice of limiting access rights for users to the bare minimum permissions they need to perform their work. Under POLP, users are granted permission to read, write or execute only the files or resources they need to do their jobs: In other words, the least amount of privilege necessary.”
given for each deployment ๏Deployment unit is replica-set in CloudNative application ๏Only enabled containers should have enabled credentials ๏By granting the credentials in detail, we can revoke the invalid container credentials Deployment ReplicaSet Pod Pod ReplicaSet Pod Pod DB User: deploy1 Password: secret1 User: deploy2 Password: secret2
Secrets and Protect Sensitive Data ๏Encrypted Key-Value Store ๏Dynamic Secrets management ๏Support many secrets and authentication ๏Abstraction secrets (Database, SSH, PKI…) ☕ Namespace problem: 1Password, Google, CentOS, Ansible and more.
Kuberentes ๏ The vault agent manages the token for vault after Kubernetes authentication ๏ Application gets database credentials as a file via consul template DB Vault Server Application Vault Agent Consul Template .vault_token db.yaml Get Credential Pod Volume ServiceAccount token auth & renew Create User Auth Backend Kubernetes
Kuberentes ๏ Using the Transit Secrets to protecting confidential in database ๏ Vault only saves encryption key for Transit Secrets DB Vault Server Application Vault Agent Consul Template .vault_token db.yaml ServiceAccount token auth & renew Get Credential Pod Volume Create User Encrypt/Decrypt Encrypted data Kubernetes Auth Backend
Secrets policy can be separated by Role by the Vault policy setting ๏ A token for the Vault is issued for per- deployment authentication ๏ This is the principle of least privilege Kubernetes Vault kubectl apply Manifest Enable AuthMethod Create Policy SRE/Ops Dev --- apiVersion: apps/v1 kind: Deployment metadata: name: db-sidecar labels: app: db-sidecar spec: replicas: 1 selector: matchLabels: app: db-sidecar template: metadata: labels: app: db-sidecar path "secret/auth/foo" { capabilities = ["create", "read", "update", "delete", "list"] }
Cluster Kubernetes requires PKI for the following operations: ๏ Client certificates for the kubelet to authenticate to the API server ๏ Server certificate for the API server endpoint ๏ Client certificates for administrators of the cluster to authenticate to the API server ๏ Client certificates for the API server to talk to the kubelets ๏ Client certificate for the API server to talk to etcd ๏ Client certificate/kubeconfig for the controller manager to talk to the API server ๏ Client certificate/kubeconfig for the scheduler to talk to the API server. ๏ Client and server certificates for the front-proxy
should be the only main process running on a machine. This reduces the risk that another process running on the same machine is compromised and can interact with Vault. Similarly, running on bare metal should be preferred to a VM, and a VM preferred to a container. This reduces the surface area introduced by additional layers of abstraction and other tenants of the hardware. Both VM and container based deployments work, but should be avoided when possible to minimize risk.” –Production Hardning
Pros ๏Simple Architecture as all containers ๏Skip overhead for operation (automation) ๏Easily grow clusters Cons ๏Other vulnerabilities can affect vaults in containers that share resources ๏Can not manage K8s certificates?
a lot from Kubernetes, but we also need to adapt our systems and thinking ๏In a scalable system, minimizing privileges is very important ๏Vault grants the least privileges with minimal operations ๏Where to run Vault depends on your organization's policy
Kubernetes? https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/ Benefits of Kubernetes https://medium.com/platformer-blog/benefits-of-kubernetes-e6d5de39bc48 Why We Need Dynamic Secrets https://www.hashicorp.com/blog/why-we-need-dynamic-secrets Production Hardening https://learn.hashicorp.com/vault/operations/production-hardening What is principle of least privilege (POLP)? https://searchsecurity.techtarget.com/definition/principle-of-least-privilege-POLP
linyows
bkuhlmann
ogurotakayuki
hinakko2
free_world21
izumin5210
nearme_tech
kosmosebi
1wedge_one
akidon0000
ryunakayama
zsmb
kasacchiful
lara
addyosmani
notwaldorf
kastner
chriscoyier
trallard
eileencodes
keathley
dougneiner
colly
ufuk
zakiyama
