Home | 문태준 | 시스템어드민 메일링 | Sys Admin 세미나
Skip to end of metadata
Go to start of metadata

 

https://www.vaultproject.io/intro/index.html

What is Vault?

vault는 secrets 에 안전하게 접근할 수 있도록 하는 툴입니다. secret 은 API keys, passwords 또는 인증서 등 철저하게 제어하기를 원하는 모든 정보입니다. vault는 secret에 대해서 단일한 인터페이스를 제공하면서 상세한 접근 통제 및 audit 로그를 기록하는 기능이 있습니다.

현대의 시스템은 여러개의 secret에 접근이 필요합니다. database 비밀번호, 외부 서비스에 대한 API 키, 서비스 지향 아키텍쳐 통신을 위한 비밀번호 등. 누가 어떤 secret에 접근가능한지 이해하는 것이 매우 어렵고 플랫폼 의존적입니다. 전문화된 솔루션이 없다면  키 순환하는 기능 추가, 안전한 스토리지, 상세한 오딧 로그 남기는 것이 거의 불가능합니다. vault가 제공하는 기능이 이러한 기능입니다.

 

Secure Secret Storage

Dynamic Secrets

Data Encryption

Leasing and Renewal

Revocation

 

Use Cases

General Secret Storage

Employee Credential Storage

API Key Generation for Scripts

Data Encryption

Getting Started

https://www.vaultproject.io/intro/getting-started/install.html

Install Vault : 설치

Starting the Server : vault 시작

Secret write, read, delte

Secrets Engines → 해당 종류 확인 필요.

Dynamic Secrets : AWS Secrete Engine. AWS access key pair 생성해줌. revoke 하면 해당 secret 도 IAM에서 삭제가 됨.

Built-in Help

Authentication : Auth Methods로 github 인증 예제. 

Policies  : 특정 policy 생성 후 token 생성하는 예제. Policies를 auth methods(github)에 매킹하는 예제. github로 로그인시 기본 policy를 만들어서 적용.

Deploy Vault

  • 실제 환경에 vault 구성시 설정하는 것 설명하고 있음. 설정, seal/unseal, scaling. physical backend로 consul 사용. 
  • 서버 시작하기, 초기화 하기(unseal key 5개 나오며 잘 보관해야 하며 Initial Root Token 도 확인필요
  • Vault 가 초기화 되었을 때 sealed 상태임. vault가 데이터를 어떻게 decrypt 하면 되는지 알려주는 것이 unsealing. vault 가 시작을 할 때마다 unsealing을 해야 하며 unseal key 에 대한  threshold  갯수만큼 필요하다.
  • 마지막으로 initial root token으로 인증을 한다.

HTTP API : HTTP API 예제.

정리

Secrets Engines

https://www.vaultproject.io/docs/secrets/index.html 

Secrets Engines : AWS, Consul, Databases, Key/Value, etc...

AWS

AWS secrets Engine

https://www.vaultproject.io/intro/getting-started/dynamic-secrets.html

vault read aws/creds/my-role 를 실행하면 access_key, secret_key를 생성한다. 

 

lease 설정하는 예

 

policy 만들고 github team과 연동. organization은 자기에 맞게 변경해야 함.

 

이제 github에서 Personal access tokens 을 생성한다. token 생성시 repo에 대해서 권한을 주지 않는 경우 조회 자체가 안되었다. 이 부분만 권한을 주면 될 듯 하다.

https://github.com/settings/tokens

 

일반 user의 경우 github에 Personal access tokens 을 먼저 생성한다. 그러고 나서 github의 token을 이용하여 로그인을 하고 필요한 권한을 read 하면 된다.

 

Databases

https://www.vaultproject.io/docs/secrets/databases/mysql-maria.html

admin

 

user

 

 

Auth Methods

https://www.vaultproject.io/docs/auth/index.html 

Auth Methods : AppRole, AWS, GitHub(GitHub personal access token), LDAP, Tokens, Username&Password (외부 소스에서 읽어오지 못함), etc

GitHub 인증은 사람에게 유용함

GitHub

https://www.vaultproject.io/intro/getting-started/authentication.html 에서 github 

 

AppRole

https://www.vaultproject.io/docs/auth/approle.html : The approle auth method allows machines or apps to authenticate with Vault Vault-defined roles. The open design of AppRole enables a varied set of workflows and configurations to handle large numbers of apps. This auth method is oriented to automated workflows (machines and services), and is less useful for human operators. 

대량의 apps 를 처리하기 위한 다양한 워크플로, 설정이 가능하다고 하며 자동화된 workflows에 촛첨이 맞추어져 있고 사람의 작업에 유용하지는 않다고 함.

 

https://www.vaultproject.io/guides/configuration/authentication.html 에서 Advanced Features 참고.

Approle을 쓰는 경우 어떻게 client app에 role ID, secret ID를 넘겨줄 것인가가 이슈임.

The Role ID is equivalent to a username, and Secret ID is the corresponding password. The app needs both to log in with Vault. Naturally, the next question becomes how to deliver those values to the expecting client.

A common solution involves three personas instead of two: adminapp, and trusted entity. The trusted entitydelivers the Role ID and Secret ID to the client by separate means.

For example, Terraform as a trusted entity can deliver the Role ID onto the virtual machine. When the app runs on the virtual machine, the Role ID already exists on the virtual machine.

 

Trusted Entity 가 role ID, secret ID를 해당 client,app에 넘겨주는 것이다. Trusted Entity 는 Terraform, CM도구, jenkins 등이 될 수 있겠다. 이 과정에서 response wrapping 을 쓰면 편리하다. 그런데 일반 개발소스에서도 Trusted Entity를 이용할 수 있을까?

 

AppRole auth backend workflow

AppRole 이용한 예제

사전에 예제용으로 secret/mysql 을 생성한다.

admin

 

https://www.vaultproject.io/guides/configuration/authentication.html 참고하여 설정

admin

 

App에서 사용하기 :  role-id, secret-id 이용. 이 정보는 admin이 해당 app에 전달을 해 주어야 한다.

app

 

trusted entity 이용하여 Role ID and Secret ID  app에 전달하기

jenkins, saltstack 같은 trusted entity 가  vault 에서 필요한 role-id 를 읽을 수 있어야 하고 secret-id는 생성, 업데이트 권한도 있어야 한다. 

admin

 

trusted entity and app

위에서 trusted_entity 정책을 가진 토큰을 생성하고 이 토콘을 이용하여 trusted entity에서 로그인을 하고 필요한 정보를 가져올 수 있도록 설정한다.

secret/mysql/prod 에 설정한 mysql_password 의 값은 사전에 설정이 되어 있어야 한다.

app

 

실제 app에서 활용하기

사람은 github 정보를 통해서 권한관리를 하고 SERVER/CI는 app-id를 이용하여 관리하는 경우의 사례. 

https://infinum.co/the-capsized-eight/hiding-secrets-in-vault

여기서는 관리해야 할 secrets가 많기 때문에 아래의 naming conventions 사용.

rails/#{git_repository_name}/#{environment} 

위 예를 보면 애플리케이션의 비밀번호 config/application.yml , DBMS 관련한 정보 config/database.yml 를 별도의 파일에 빼어 놓는다.

이 파일들은 버전관리시스템에서 관리하지 않는다. (.gitignore 설정) 

 

애플리케이션 배포를 할 때 배포 스크립트에서 secret 관련한 정보를 vault에서 가져와 해당 설정파일을 만드는 형태이다.

.secret 파일 예제 : secret 들어간 파일 명과 vault  에서 사용하는 path 정보가 들어 있다.

github 에서 여러가지 이용한 예제

github 인증은 활성화를 하고 organization 설정을 했다고 가정을 함. 

아래의 경우는 github 에서 devops팀에 ec2admin, jenkins 라는 policy를 허용해주는 설정임.

admin

policy를 각 권한별로 관리할 수도 있고 (AWS 별도, 소스코드 비밀번호 별도 등) 각 팀별로 만들 수 있다. (devops에 A, B 권한 설정)

참고

관리용 스크립트

테스팅 편리하게 사용하기 위한 스크립트 모음.

vault init 을 하고 unseal을 하며 init하면서 만든 root token 으로 로그인을 한다. 

수동으로 할 경우에는 export VAULT_ADDR='http://127.0.0.1:8200' 을 해 주어야 한다.

vault init

unseal

root token 얻고 로그인

HA

Storage Backend 에서 HA 지원하는 것은 Consul, Zookeeper, etcd이다. 이중 HashiCopr Supported는 Consul만 된다. Zookeeper, etcd 를 사용하고 있지 않다면 Consul과 같이 써야 한다.

https://www.vaultproject.io/docs/concepts/ha.html Storage Support 참고. s3의 경우 HA 지원하지 않는다. (https://www.vaultproject.io/docs/configuration/storage/s3.html)

 

https://www.vaultproject.io/docs/concepts/ha.html

Vault supports a multi-server mode for high availability. 

The successful server node then becomes the active node; all other nodes become standby nodes. At this point, if the standby nodes receive a request, they will either forward the request or redirect the client depending on the current configuration and state of the cluster -- see the sections below for details. Due to this architecture, HA does not enable increased scalability. In general, the bottleneck of Vault is the data store itself, not Vault core. For example: to increase the scalability of Vault with Consul, you would generally scale Consul instead of Vault.

vault에서 high availability를 위해 여러 대의 서버를 운영하는 것을 지원한다. 현재 운영중인 서버 노드가 active node가 되고 나머지 노드는 standby 노드가 된다. 스탠바이 노드에서 요청을 받으면 설정에 따라서 요청을 포워드 하거나 redirect를 한다. 이런 구조 때문에 HA는 확장성을 높이지는 않는다. 일반적으로 vault 에서 병목이 생기는 것은 vault 자체가 아니고 데이터를 저장하는 부분이다. consul과 함께 vault를 사용하는 경우 확장성을 높이려면 일반적으로 consul을 확장한다.

 

vault HA 구성하는 것과 관련해서는 아래 문서에 자세히 나와있다.

https://www.vaultproject.io/guides/operations/vault-ha-consul.html

Reference Architecture

vault 에서 HA 구성시 연관되어 있는 옵션은 cluster_address, api_addr, cluster_addr 이다.

cluster_address : this should be set to address that you prefer the Vault servers perform intra-server communications on. vault 서버간에 통신을 하는 address

api_addr : this should be set to the address which client (API) requests are to be redirected to. 클라이언트 요청을 redirect 할 주소

cluster_addr :  this parameter is specifically for HA request forwarding between Vault servers and needs to be a address routable between all Vault servers in a full URL format with port. vault 서버간에 HA 요청을 포워딩할 때 사용함. 

 

 

그런데 consul을 쓰는 경우 이 부분을 따로 설정하지 않아도 여러 대의 vault 서버를 띄우는 경우 자동으로 acitve/standby 구성을 한다. standby 서버에 접근하려는 경우에는 자동으로 active 서버로 request forwarding 을 한다. 만약 로드밸런서를 이용하여 vault에 접근하려는 경우에는 api_addr을 로드밸런서의 정보로 변경해야 할 것이다.

 

외부 로드밸런서를 쓸 경우에는 active node를 체크하기 위해 특정 url을 체크해야 한다. 이경우 http://<Vault Node URL>:8200/v1/sys/health 에 대해서 200으로 응답을 한다. 

https://www.vaultproject.io/guides/operations/reference-architecture.html#load-balancing

 

참고자료

vault use case : https://sreeninet.wordpress.com/2016/10/01/vault-use-cases/

Example usage of HashiCorp Vault secrets management https://github.com/hashicorp/vault-guides 

 

https://github.com/bruj0/vault_jenkins 

https://www.reddit.com/r/devops/comments/7ou98v/how_to_use_hashicorp_vault_to_store_secrets_and/

docker-compose로 vault, consul, jenkins 올림. 테스팅 용도로 좋음.

jenkins에서 테스팅을 하려면 https://github.com/jenkinsci/hashicorp-vault-plugin 설치해야 함. 아직 jenkins를 잘 몰라서 어떻게 실행하는지는 잘모르겠음.

 

아래 AWS 문서가 vault tree 구조 설계할 때 도움이 될 듯 함.

파라미터를 계층 구조로 조직

https://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/sysman-paramstore-su-organize.html

/Environment/Type of computer/Application/Data

/Dev/DBServer/MySQL/db-string13

 

KMS, Paramter Store 이용하여 secrets 관리하는 AWS 예제

https://aws.amazon.com/ko/blogs/compute/managing-secrets-for-amazon-ecs-applications-using-parameter-store-and-iam-roles-for-tasks/

Labels
  • No labels
  1. https://www.vaultproject.io/docs/internals/architecture.html

    client 가 vault에 연결하려면 authenticate 필요함. 사람의 경우에는 username/password, github, ldap 등을 이용할 수 있으며 application의 경우에는 public/private key나 token을 이용할 수 있음. 

    authentication 후에는  Policy (named ACL rule) check를 한다 

    authentication , policy check 를 한후 에 client token이 생성되며 이후 요청은 client token을 이용한다. 

    이제 해당 요청은 secretes engine으로 라우팅되며 각 secret engine에 따라서 처리가 된다. secrete engine에서 secret 을 반환할 때 lease ID를 할당한다. lease ID를 통해서 해당 secrete을 renew, revoke를 할 수 있다. lease 가 만료되면 자동으로 secrete을 revoke 한다.

     

    admin

    • 필요한 secret engine 설정 : aws, database, kv
    • policy 설정 : 필요한 secret 에 대한 접근권한. read, write, update, delete 등.
    • authentication 설정 : github, token (특정 policy와 연결)

     

    user level

    application에서 자동으로 처리하려고 할 경우에는 vault login에 필요한 token을 admin이 사전에 만들어주어야 하며 이 token을 이용하여 원하는 secrete을 가져오면 된다. 여기에서 token이 노출되면 vault 의 정보에 접근이 가능하므로 이 부분은 프로그램 소스에 넣지 않고 배포스크립트같은 곳에서 사용을 하는 것이 좋을 것이다.

     

  2. 2018. 4.10 HashiCorp Vault 0.10 이 나왔습니다.

    HashiCorp Vault 는 password, API key 등의 보안 정보를 안전하게 관리하기 위한 솔루션입니다.

    아직 테스팅을 해 본 것은 아니고 관련된 자료만 살펴 보았습니다. 버전을 올릴지 말지 고민을 해야 겠네요.

     

    https://www.hashicorp.com/blog/vault-0-10

    아래와 같은 새로운 기능이 들어갔다고 합니다.

    • K/V Secrets Engine v2 with Secret Versioning: Vault's Key-Value Secrets Engine now supports additional features, including secret versioning and check-and-set operations.
    • Open Source Vault Web UI: The previously Enterprise-only UI has been made open source and is now released in all versions of Vault along with many enhancements.
    • Root DB Credential Rotation: Root/admin credentials for databases controlled by Vault's Combined DB secrets engine can now be securely rotated with only Vault knowing the new credentials.
    • Azure Auth Method: Azure Machines can now log into Vault via their Azure Active Directory credentials.
    • GCP Secrets Engine: Vault can now create dynamic IAM credentials for accessing Google Cloud Platform environments.

    저한테 눈에 띄는 것은 두가지인데요.

    K/V Secrete Engine 이 v2로 올라가면서 버저닝 기능을 지원합니다. 이전에는 key/value를 무조건 업데이트 했다면 이제 버전 기능이 지원되기 때문에 변경 기록을 관리하기가 더 좋아졌네요.

    아래 문서에 version1 에서 업그레이드 하는 법이 나오며 ACL Rules 설정이 변경되었습니다.

    https://www.vaultproject.io/docs/secrets/kv/kv-v2.html

     

    이전에는 엔터프라이즈 버전에만 들어있다고 했던 UI가 오픈소스로 포함되었습니다.

    자세한 내용은 https://www.hashicorp.com/resources/vault-oss-ui-introduction 에 들어 있습니다.

    UI에서 secrets, Aceess (authentication methods), Replication, Policy 등을 지원하네요. CLI 등으로 할 수 있는 작업들이지만 UI가 있으면 초기에 테스팅을 할 때는 좀 더 편할 수는 있을 것 같습니다.