kubesecを使ってsecretを暗号化する(Cloud KMS)

暗号化自体は「gcloud kms encrypt」コマンドでできるけど、「kubesec」を使うとk8sのmanifestを可読性を保ったまま、いい感じに暗号化してくれる。 Base64エンコードもやってくれるので楽できる。

GCPのCloud KMSで鍵を管理できるところもメリットだと思う。 ローカルで鍵を管理するとか面倒なので、鍵もクラウド環境にあると便利で安心。(GCPが死亡すると死ぬけど)

想定のフローは以下のとおり。

  • ローカルで暗号化する(KMSの対称鍵を使ってkubesecで暗号化)
  • CommitしてPushする(暗号化しないままコミットすると地獄になるので対策が必須
  • パイプラインやら手動やらで復号化する
  • パイプラインやら手動やらででmanifestをapply(prune)してクラスタに反映させる

Cloud KMSでキーを作成する

暗号化に必要なキーリングとキーを作成する。(キーを作るには、キーリングを作る必要がある)

暗号化したsecretを復号化しないと利用できないので、対象鍵を作成する。

//キーリング作成
[iwata@localhost]$ gcloud kms keyrings create [KEYRING_NAME] --location asia-northeast1 

//キー作成
[iwata@localhost]$ gcloud kms keys create [KEY_NAME] --location asia-northeast1 --keyring [KEYRING_NAME] --purpose encryption

//確認
[iwata@localhost]$ gcloud kms keys list --keyring [KEYRING_NAME] --location asia-northeast1
NAME                                                                         PURPOSE          ALGORITHM                    PROTECTION_LEVEL  LABELS  PRIMARY_ID  PRIMARY_STATE
projects/******/locations/asia-northeast1/keyRings/******/cryptoKeys/******  ENCRYPT_DECRYPT  GOOGLE_SYMMETRIC_ENCRYPTION  SOFTWARE                  1           ENABLED

NAMEカラムの長ったらしい名前がキーのリソースIDで後で使う。

--purposeは、下の値から一つ選ぶ。今回は、encryptionを指定する。

The “purpose” of the key. PURPOSE must be one of: asymmetric-encryption, asymmetric-signing, encryption.

ちなみに、有効なキーの数で課金される。 そして、すぐには削除できない。(破棄がスケジュールされる) 課金されないようにするには、キーを無効にする必要がある。

テキトーな名前でつくると後悔するかもしれないのでご注意を。

kubesecをインストールする

公式に書いてあるとおり、バイナリをダウンロードしてくる。(Goのシングルバイナリ最高)

[iwata@localhost]$ curl -sSL https://github.com/shyiko/kubesec/releases/download/0.9.2/kubesec-0.9.2-linux-amd64 -o kubesec && chmod a+x kubesec && sudo mv kubesec /usr/local/bin/

ちなみに、同じ名前の別のプロジェクトがあるぽい?のでご注意を。

kubesecで暗号化する

まずは、認証しておく。

gcloud auth application-default login

そんでもって実際の暗号化するために以下のコマンドを実行する。 RESOURCE_IDに、先ほどのキーのリソースIDを指定すること。

kubesec encrypt -i --key=gcp:[RESOURCE_ID] [FILE_NAME] --cleartext
  • -i オプションは、引数で渡したファイルに結果を上書きする。 つまり、同名のファイルを暗号化する。( i nstead of stdout)
  • –cleartext オプションを指定しておくと、自動的BASE64エンコードをしてくれる(クリアテキストを渡すよオプション)

kubesecで復号化する

kubesec decrypt -i [FILE_NAME] --cleartext

復号化するときは、キーは指定しない。(暗号化されたファイルにキーが記録されている)

MHW:アイスボーン プレイ記録

アイスボーンが出るっていうので、2ヶ月前から復帰してたんやけど・・・。

最後の2週間前に飽きがきて、あまりやらなくなり・・・アイスボーンはスルーしようと思ってた。

よくあるあるパターン。

が、すでに予約購入済みだったので、とりあえずやることに。

これもよくあるあるパターン。

ダウンロード版なので金曜の0時にスタートできるけど、さすがにそこまでモチベーションが高くなかった。

木曜の夜中に、とりあえずダウンロードしとくかと開始すると、余裕の7時間待ちで軽くテンションダウン。

0時にやるわけじゃないので、別にいいんですけど、少しだけ後悔するっていうね。

翌日の昼休みに、「アイスボーンのすべて任務のリストでてますよ!」とか同僚に言われたけど、へぇー、ふぅーん、みたいな若干冷めた温度感。

金曜の夜は、台風からのうねりが入ってそうなので、釣りには行かずに、がっつりアイスボーンをやることに。

下位の最終装備でどこまでイケるんや~?とか考えながらマスターランクの任務をこなす。

マスターランク★1~5まで

私はランサーの基本ソロプレイヤーでして、マム・タロトをダルくてやってないので、最終装備は、アトロシスタワー止まりでございます。

そんで、自分でいうものなんだけど・・・ゲームめちゃ上手い・・・ではなく普通に下手

なもんで、最初に戦う「ブラントドス」の時点で、結構時間がかかりました。

おいこれ・・・武器作ったほうがええんちゃいますのん・・・とか思ったけど、派生表みるのがダルいのでスルー。

そんな感じで、グダグダと任務を進めて・・・なんとか「イヴェルカーナ」を討伐。

結構いけるもんやね!

お次の「紅蓮滾るバゼルギウス」は、長引くと殺られる感じがしたので、手軽に作れる汎用武器的なダチュラスプラウトII(攻撃力552 毒600)を作成して討伐。

「死を纏うヴァルハザク」は、毒が微妙そうなのでアトロシスタワーで行ったら、討伐はできたものの、体力が多すぎて非常につかれた。😱

その後、ランサー御用達なガンキン装備を作るために、「ウラガンキン」に行って、EXガンキンβの手と足を作成。

この2つで、ガード強化とガード性能Lv4になるのでお手軽やなーと。

「ネロミェール」は、同僚がくっそ強い!ラスボスより強い!とかいってたのでビビってたけど、超雑魚やんけ・・・。

体力もそんなに多くないし、ほとんどガードできるので楽。

そんなことより、ライドコールめちゃ便利やね!

えー!自分で操作できないの?!とか思ったけど、自動のほうが楽。自動でモンスターまでデプロイしてくれる。

自動でいい。自動化最高。

マスターランク★6へ

ここからマスターランク★6へ。

「悉くを殲ぼすネルギガンテ」は、歴戦王ネルギガンテ(以下、王ネギ)とよく遊んでいたので、こちらもさくっと討伐。 ネルギガンテは戦ってて楽しいモンスターです。

そして、ラスボスへ。

同僚が糞雑魚だといってたのに・・・、全然強えーよ!てかダルいよ!💢

とにかく序盤の第一形態が不毛でして、第二形態もガード殺しな技が多く、元気玉をくらって死亡したところで中断。

この第一形態、第二形態、ワイプ・・・どこかで・・・うっ、頭がっ・・・。

あんまり上手くないので、王ネギみたいにガードの上からガンガン削ってくるタイプは苦手。

なんとかしましょう。

全体的な感想

全体的に敵の体力が多くて時間がかかりますが、個人的には削りがいがあって、わりと好き

属性が強くなったのも、いろんな武器を作る動機になってモチベーションを保てそう。

あんまりやる気無かったのに、実際にプレイし始めるとガッツリ楽しんでおります。

ラスボスを除いてはな!

Dockerはブームとか通り越してもはやスタンダード

元ネタ Dockerブームはウソだった? 1年経ってピタリと止まった導入率

IDC Japanによると、本番環境でのDocker使用率は9.2%で、2018年から1.3ポイント上昇。

ステージング環境で16.7%。

本番導入済みの企業の45.5%がK8sで19.8%がOpenShift。

コンテナの導入促進要因については、 「インフラの使用効率向上とコスト削減」34.7% 「開発者の生産性の向上」30.6% 「アプリケーションの信頼性/可用性の向上」28.1% 「アプリケーション運用の効率向上とコスト削減」28.1% 「アプリケーション開発/リリーススピードの向上」27.3%

https://www.keyman.or.jp/kn/articles/1908/27/news050.html より引用して要約

他の会社はどうかしりませんが、うちの会社では少なくともスタンダードです。 というか、Dockerブームってかなり前では・・・。

Docker化するなら本番運用までしたい

個人的には、Docker化するなら本番運用までしないと、あまりメリットがないと思っています。 開発環境だけでの導入でもメリットはありますが、本番運用するところに本当の価値があると思います。 よって、下記はDocker化するならKubernetes(K8s)での本番運用も含めるという見解が前提の話です。

うちの会社のインフラの変遷

物理筐体の話とかだれも聞きたくないと思うので、竹槍な時代は省略します。 ケーブリングの話とか聞きたくないでしょ?

Dockerを導入するまで

基本的に仮想サーバー(以下、VM)で開発してましたが、業界の方々がDockerていうイケてる技術を使うようになりました。

うちの会社は、Dockerの導入がかなり遅かったです。 そんな状態だったので、DockerはVMの一種だと思ってる社員が多く、 「まずCentOSのimageをpullしてupdateかけます、そして必要なミドルウェアをインストールします」 みたいな、今では考えられん事をやっていました。

その後、1、2年くらい使い続て、ようやく現在の使い方に近くなってきました。 その頃から、新規開発するシステムはDockerが標準になりました。 そうなるとシステムが動作する環境の差分を気にする必要がなくなるので、本番環境でも利用したくなります。 ですが、公開サーバーにDockerをインストールして、本番運用するのはさすがにねーな・・・ってことで断念しました。

K8sを導入するまで

そんなある日、Kubernetesとかいうマジで読みにくい、ワケワカラン技術に出会います。 こいつも、Dockerの初期状態と同じで、なんのための技術なのか、どういうメリットがあるの理解できませんでした。 へぇー、クラスタねぇ、エンプラの話やな、ハナホジ~みたいな会話をしてた記憶があります。

ところで、日々の面倒な業務の一つに、VPSで動くレガシーなシステムのアップデートやパッチを当て回る作業があります。 基本的には、VPSはAnsibleなどを通してコードで管理されているので、ある程度は自動化されてますが、こいつが本当にめんどい。 本音は、OSやインフラの面倒を見る時間を、ソフトウェアの開発に当てたいわけです。

そんな問題を解決するために調査していくと、GKEとK8sに出会いました。 マネージドのK8sだと、OSやインフラの保守をせずに、Dockerのimageを直接本番で運用できるやんけ! そんな最高のソリューションを使わない理由はなく、GKE(K8s)の導入が決定しました。 あと、うちの会社はDDDを好む人が多く、マイクロサービスアーキテクチャを採用しているという理由も大きいです。

中小企業のレガシーシステムとK8s

中小企業のSIerって、まだまだレガシーなサービスやプロダクトを多く保守してます。 うちも、まだまだレガシーなシステムが残っております。 こういうシステムは、当然Docker化されてません。 VMやVPSで動く前提の設計になってます。(そういう時代に開発されたモノだから、当時の開発者に罪はない!)

当然ですが、Docker化するためのコストはそのシステムのアーキテクチャや仕様、環境などに依存します。 ファイルシステムにI/Oを頻繁に行ってたり、環境依存のバイナリやコマンドを実行している場合はコストが高くなる傾向にあります。 オンプレで特殊な処理をしてるシステムほどDocker化し難いですが、そういうシステムがお金を生み出している事も珍しくありません。 そんなこんなで、ステークホルダーからは、以下のような意見が投げつけられます。

  • 現状で十分な金を産んでるけど、Docker化する意味あんの?
  • 動かなくなったら責任とれんの?

ちなみに、お金を生んでないプロダクトは、中小企業だと放置するのが基本で、Docker化なんて話にすらなりません。 価値を生み出さないプロダクトに投資する必要はないので、正しい姿勢だと思いますが、だったらクローズしていけよと思います。 これは別の話なので、機会があれば別に書こうと思います。

Docker化して本番運用すると本当にコストが下がるのか

お金にうるさいステークホルダーがやはり注目するのは、運用コストです。(上記のアンケートの結果も同じですよね) 料金固定のVMやVPS内で動かしている分には、運用コストは下手すれば月額数千円で、ある程度、可用性を上げた構成にしても2、3万以内で動いてしまいます。 うわぁ!インフラ貧弱すぎ!いまどきないやろ!・・・とか思う人は、理解がある会社に勤めておられる、もしくは取引しておられると思われます。

実際にうちの会社にも、格安VPSにApacheとPHPとMySQLが一緒に入っていて、冗長化されてないシステムがあったりします。 んで、これらをなんとかDocker化したとして、マネージドのK8sにデプロイすると・・・インフラのコストが急に跳ね上がります。

GCPを例に上げると、クラスタ化するのにn1-standard-1が最低2台は欲しいです。1 データベースは、マネージドのデータベースを別途契約する必要があります。2 それに加えて、ロードバランサーの料金や、ネットワークの料金が発生します。 逆にコストが上がっとるやないかーい! これって誰が得すんの?!

このレガシーなシステムが、今後も活発にコミットされて発展していくなら、メリットはあると思います。(イテレーションや、ベロシティの向上など) ですが、多くのレガシーなシステムは、現状維持が基本です。(開発が盛んなプロダクトならレガシーにならないよね!) むしろ下手にさわんな!とか言われます。 なので、クラウドネイティブ化が目的で、レガシーシステムをDocker化するのは無謀です。すくなくともうちの会社ではそうです。

同一クラスタに詰め込むとコストが下がるが・・・

クラスタ内の余剰リソースを活用するために、他のシステムをデプロイすると、無駄なく運用できてコストを下げることができます。 ですが、SIerの性質上、複数のクライアントのシステムを一つのクラスタに入れると、嫌がるクライアントが出てきます。 セキュリティ上のナンタラが、ウンタラらしいです。

そうなると、クラスタを分けるしかなくなるわけで・・・。 これは、自社サービスの場合でも同様で、サービスごとに物理的にクラスタを切り離しておいた方が安全だと考える人もいます。 マイクロサービスの場合は、そんなこと言ってたら面倒くさくて死ぬんですけど、モノリスでセンシティブな情報を扱うシステムの場合、慎重になるのは理解できます。 そうなると、全然コストさがらないよ?あれ・・・?

さらに、コストを下げようとすると、同じクラスタ内で名前空間を分けて、複数のシステムをデプロイすることになります。 すると、オーバーコミットの発生確率とコストのトレードオフが発生します。 いろんなシステムを詰め込むと、その分コストが下がりますが、負荷が上がるとオーバーコミットしやすくなります。

逆に、オーバーコミットを懸念して余裕をもった設定にしておくと、すぐにノードがスケールアウトされてコストが上がります。 結果整合性が主体で冪等性を保証しているシステムなら問題ありませんが、ミッションクリティカルなシステムとは相性が悪いかなと思います。

ちなみに、メモリがオーバーコミットするとOOM Killerでぶち殺されます。😱

それでもK8sを使う理由

上にも書きましたが、うちの会社がK8sを使う理由はコストではありません。 開発の高速化が目的です。 アプリケーション開発に集中したいので、できるだけインフラの面倒を誰かにみてもらいたい。 でも、ミドルウェアは自分たちである程度制御したい。 そんなワガママをかなえてくれるのがK8sだからです。

そんなこんなで、コストが上がるケースもありますので、ご提案の際はご注意くださいませ。


  1. GKEとK8s自体のPodも立つし、Node障害やメンテナンスを考えると2台欲しいです。 [return]
  2. GCPではクラスタ内でデータベースを本番運用するのをすすめていませんし、実際、やりたくありません。 [return]
Profile
プロフィール画像
Takashi Iwata

大きな水たまりの近くに住む、ルアーフィッシングとゲームをこよなく愛する、アウトドア派のエンジニアです。 好きな言葉は「為せば成らぬ事もある」です。

Archive