Security

GitHubのコミットログ、コミットした人のアイコンが出ていてとてもわかりやすいですよね。 コミットとアカウントの紐付けにはどうやら、コミットに紐付けられたメールアドレスが使用されているようです。そうなると、コミットに紐付ける(git config user.email=...とかやるアレです)メールアドレスはアカウントに登録してあるメールアドレスにしたいものです。 しかし、会社ではGitHub Enterprise(GHE)、私用ではgithub.com を使用している、と言った場合はどうでしょうか。コミットに紐付けたいメールアドレスがリポジトリによって変わる、ということになってしまいます。 調べてみると、そういった場合、次の様に.gitconfigにIncludeIfのブロックを設定することでうまく回避ができそうということがわかり、しばらく設定していました 1 2 [IncludeIf "gitdir:~/src/GHE_DOMAIN"] path = "~/.gitconfig.ghe" ~.gitconfig.gheには次の様に書かれています。 1 2 [user] email = 社用メールアドレス 私はGo言語をよく書くのと、ghq を使っている都合上、gitのリポジトリを配置するパスが$(GOPATH)/src/GIT_DOMAIN/USERNAME/REPOSITORYという形式になっているため、リモートリポジトリのドメインを指定することでうまいこと社用GHEの時だけ設定を上書きすることができていたのでした。 そしてこれは、どのPCでも使用できるように、dotfilesリポジトリ としてgithub.com にpushしていました。 その結果、会社の人から、「社内のサービスのURL(この場合はGHEのURL)はセキュリティ的な理由から外に出さないようにしてほしい」と連絡を受けました。すぐさま該当のブロックは消したのですが、そうするとメールの設定が自動でされなくなってしまい不便です。リポジトリのパスを変更するというのも、せっかくの統一的な操作に違いが出てしまい、不便です。 そこで思いついたのが、こういったセンシティブな情報を別のプライベートリポジトリに分け、Makefile でインストールを自動化するという方法です。 パブリックなdotfilesリポジトリ にある.gitconfig には次の様に書いてあります。 [include] path = ~/.gitconfig.secret .gitconfig.secretはその名の通り、秘匿情報を含んだ.gitconfigで、プライベート化されたdotfiles-secretリポジトリにおいてあります。dotfiles-secretリポジトリはmake installとしたときにgit cloneされ、さらにそのディレクトリ内のMakefileにより配置されます。dotfiles-secret/.gitconfig.secretには先ほどのIncludeIfブロックが書かれており、同リポジトリ内の.gitconfig.secret.ghe(名前を少し変えました)を読み込みます。 これで、全体の使い勝手をほとんど損なうことなくどのマシンでも(dotfilesが配備済みなら)同様に設定することができました。 Makefileは特にdotfilesのリストを持たないよう記述しているため、新しいdotfileが増えても、特にMakefileの変更をする必要も無く安心です。

TL;DR Alertmanagerの設定には一部Secretが含まれる バージョン管理システムに入れたくない initContainerでconfdを使って設定ファイルを生成する Alertmanagerの設定の一部をSecretに格納できる confd kelseyhightower/confd は非常に軽量な設定ファイル管理ツールです。基本的にはテンプレートエンジンですが、多くのバックエンドデータストアからデータを持ってきて、設定ファイルに書き出すことが出来ます。 また、事前処理や事後処理を行うことが出来るので、例えば設定ファイルを書き換えたあと、リロードする、というところまでconfdで行うことが出来ます。 Install Go言語で書かれているため、インストールは非常に簡単で、バイナリをダウンロードしてきて実行権限を与え、パスの通ったところに置くだけです。バイナリはリリースページ からダウンロードすることが出来ます。 使用方法 confdを使用するためには、三つのものを用意する必要があります。 テンプレートリソース テンプレート データストア テンプレートリソース テンプレートリソースには、どのテンプレートを使用して、どんなキーでデータストアからデータを取り出し、完成した設定ファイルをどこに置くのか、事前処理・事後処理はどんなものかを記述します。書式はTOMLで、慣れ親しんだ(慣れ親しんでない？)iniファイルの様に気軽に書くことが出来ます。/etc/confd/conf.d以下に配置します。 テンプレート テンプレートはその名の通り、設定ファイルのテンプレートです。ここに、データストアから取り出したデータを合わせて設定ファイルを作成します。書式はGo言語のtext/template に準じます。/etc/confd/templates以下に配置します。 データストア そして、データストアにデータを入れる必要があります。 confdは、データストアとして、次のものをサポートしています(2018/08/20現在) etcd (GitHub: coreos/etcd ) consul (GitHub: hashicorp/consul ) dynamodb redis (GitHub: antirez/redis ) vault (GitHub: hashicorp/vault ) zookeeper (GitHub: apache/zookeeper ) rancher metadata-service (GitHub: rancher/rancher , rancher/metadata ) AWS Systems Manager パラメータストア 環境変数 ファイル Alertmanager Alertmanager はPrometheus からのアラートを受け取り、適切にハンドルするためのアプリケーションです。Alertmanagerの設定はYAMLで記述するのですが、SMTPのパスワードやSlack のIncoming Webhook URL 等、平文でバージョン管理システムに入れるのは躊躇われるデータを含みます。しかし、環境変数などから設定をすることも出来ないため、平文で記述するか、何らかの方法で設定ファイルを編集してから使う必要があります。 特に、Prometheus/AlertmanagerはKubernetes と併せて使用されることが多いため、出来ればKubernetesのSecret機能を使用したいところです。 そこでconfdをinitContainerで使用して、設定ファイルを生成します。...

Japan Container Days v18.04 で表題のセッションを聞いたので、まとめました。 スライド資料 Kubernetesのセキュリティのベストプラクティス(SpeakerDeck) APIサーバへの攻撃を防ぐ RBACでPodに付与される権限を絞る Podにはシークレットが自動でマウントされるため、不正アクセスにより読み込まれてしまうと危ない FirewallでAPIサーバへのアクセスについてIP制限を付与する いざ、シークレットが漏れた場合でも、APIサーバにアクセスされてしまわないように、ファイアウォールでIP制限をかけておくと良い NetworkPolicyでDBへの接続が許可されるPodを制限する 大体の場合、重要なデータはDBに有るため、DBへのアクセスを絞ることで安全性を上げる example: 1 2 3 4 5 6 7 8 9 10 11 12 13 kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: redis spec: podSelector: matchLabels: name: redis ingress: - from: - podSelector: matchLabels: name: guestBook ホストへの攻撃を防ぐ 次の三つを併用すると良い non-rootユーザでPodを実行する example: 1 2 3 4 5 6 7 kind: Pod apiVersion: v1 metadata: name: security-context-demo spec: securityContext: runAsUser: 1000 読み込み専用ファイルシステムを使用する example: 1 2 3 4 5 6 7 kind: Pod apiVersion: v1 metadata: name: security-context-demo spec: securityContext: readOnlyRootFilesystem: true no_new_privs forkしたプロセスが強い権限を持てないようにする...