概要
で紹介したprotoeasyがリンクごと消えて使えなくなったので、protocの使い方を整理するために書きます。
環境
- libprotoc 3.9.1
使い方
Goを例に基本的な使い方を説明します。
SRC_DIRディレクトリに.protoファイルがある場合、基本的には以下のようにコンパイルを実行します。
$ protoc -I./SRC_DIR --go_out=./OUT_DIR ./SRC_DIR/*.proto
各オプションをそれぞれ説明していきます。
続きを読むVaultのCubbyhole Response Wrapping
概要
HashiCorp VaultにはCubbyhole Response Wrappingという仕組みが用意されています。
これによってトークンや秘密情報の受け渡し時の漏洩リスクを最小限にします。
課題・背景
人やマシンにトークンを渡す場合、
などの問題点を考慮する必要があります。
また仮に漏洩した場合に
- 漏洩したトークンが不正に利用された
ということを検知する仕組みが必要になります。
Cubbyhole Response Wrappingはそれらを解決する手段です。
環境
- Vault 1.2.2
HashiCorp VaultのDynamic Secrets
概要
HashiCorp VaultにはDynamic Secretsという期限の付いた認証情報を動的に生成してパブリッククラウドやDBへのアクセスをセキュアに保つ仕組みが用意されています。
課題・背景
秘密情報とその周辺の認証を一元化し、適切な暗号化・Auditなどをしっかりしたとしても以下の課題が残っています。
- 鍵情報を用意してもローテーション運用が大変
- 退職者が出るたびにローテーションしなきゃいけない
- 鍵の共有化
- 影響範囲が分からず削除できない
- 漏洩しても誰が使ったのか分からない
- 起動時だけ秘密情報が必要なのに永続的にどこかに残すのがセキュアでない
- ログやクラッシュレポートに秘密情報が吐き出されてしまったり
ref: https://www.hashicorp.com/blog/why-we-need-dynamic-secrets
Dynamic Secretsはそれを解決するための手段です。
環境
- Vault 1.2.1
VaultのTokenとLease
概要
HashiCorp VaultのTokenにはLeaseという概念があります。
この概念によってよりローテーションを強制し、秘密情報のセキュアな管理をすることが可能です。
環境
- Vault 1.2.1
default_lease_ttlとmax_lease_ttl
root tokenを除く全てのtokenにはdefault_lease_ttlとmax_lease_ttlの２つのTTLがあります。
$ vault read sys/auth/token/tune Key Value --- ----- default_lease_ttl 768h force_no_cache false max_lease_ttl 768h token_type default-service
説明すると以下です。
| TTL | 説明 |
|---|---|
| default_lease_ttl | tokenをcreate, renewした時のTTL |
| max_lease_ttl | renewの上限値expire_time>issue_time+max_lease_ttlとなるrenewはNGデフォルト32日 |
このように２つの期限でvaultのtokenは管理されています。
続きを読むKubernetes の Ingress を理解する
概要
KubernetesにはL4ロードバランサのServiceとL7のIngressがあります。
IngressはControllerによって挙動が大きく変わるので実際に手を動かして学んでみます。
環境
- minikube 1.3.0
- Kubernetes 1.15.2
- nginx-ingress 0.24.1
- nginx-ingress chart 1.6.19
- Helm 2.14.3
Ingress Controller
Ingress ControllerはIngressリソースを動かすためのものです。
例えば以下のようなIngress Controllerがあります。
Ingress Controllers | Kubernetes
続きを読むHelm の基本的な使い方
概要
Kubernetesの問題の１つに、マニフェストファイルがたくさんできるYAMLの壁と呼ばれるものがあります。
- image
- mountするファイル
- label
- リソース割当
といった一部の要素だけ変えたい時、ほとんど構成は同じで似たようなマニフェストファイルが大量に出てしまいます。
そしてそういったファイルは往々にして管理されず負債となっていきます。
それを解決するのがHelmというKubernetesのパッケージマネージャです。
共通部分をテンプレート化し、可変部分を変数で扱えるようになります。
今回はそのHelmの基本的な使い方を説明します。
環境
- Kubernetes 1.15.0
- Helm 2.14.3
システム図
Helmをシステムアーキテクチャは以下です。
ref: Simplifying App Deployment in Kubernetes with Helm Charts
図からわかるようにTillerと呼ばれるサーバがKubernetes Cluster内で起動し、api-serverをコールしてデプロイを行います。
続きを読む