組織のドキュメント戦略、k8sの攻撃パターン：DevOps/SRE/Kube Weekly Update (2023/11/27-12/3)
以下の３つの記事から気になったもの & 個人的に気になったものを毎週紹介しています。
DevOps Weekly（ https://devopsweeklyarchive.com/ ）
SRE Weekly（ https://sreweekly.com/ ）
KubeWeekly（ https://www.cncf.io/kubeweekly/ ）
DevOps Weekly
ドキュメント戦略
いかにして製品やプロジェクトの優れたドキュメントを作成していくかについて書かれています。
現状はREADMEなどのドキュメントの作成は後回しになっています。
しかし、優れたドキュメントには以下のような利点があり、組織はドキュメントの整備により注力する必要があると書かれています。
- クライアントの技術チームへのプロジェクトのより迅速な引き継ぎを可能にします。
- コアチームメンバーへの依存を減らします。
- ドキュメントのメンテナンスを容易にします。
- 新しいチームメンバーのオンボーディングを簡素化します。
- 新しいチームメンバーのオンボーディングに必要な時間をより正確に見積もることができます。
- 製品のビジョンへの準拠を容易にします。
- エンジニアの日常業務をガイドします。
優れた直感的なドキュメントを作成するには以下のような勘所があると書かれています。
- シンプルなマニフェスト/ビジョンの作成
- ドキュメントを新規作成するときには常にレビューを行うこと
- できるだけ視覚的な情報を入れて直感的にわかるようにする
- 直感的なフォルダー構造を作成します。
- 例えば、それぞれのドキュメントのカテゴリー別にディレクトリを分けて管理する
オンボーディングを支援する以下のようなドキュメントを作成します。
- README.md
- オンボーディングガイド
- ストーリーガイド
- アーキテクチャ
- 注目の機能リスト
- 専門的なパスガイド
- 価値を付加するドキュメントの作成を自動化します
Spotify のBackstageなどのツールは、開発者ポータルやサービスのカタログの作成に役立ちます。豊富なアドオンを使用すると、多数の自動化やカスタマイズを追加できます。
自動化は確かに大事。ドキュメントを定期的にメンテし続けるのは思ったより大変ですよね。
terraform-aws-github-runner
Github Actionsの自動スケーリングするセルフホストランナーをAWSスポットインスタンスでホストするためのTerraformモジュール。
AWS Lambdaを使用してスケールアップ／ダウンのロジックを実現しているよう。もし、アクティブなワークフローがない場合は、コスト削減のためにランナー数はゼロにスケールダウンすることができます。
SRE Weekly
優れたアラートの作り方
ユーザ体験を損なわないために監視を我々は行っていると思います。
ただし、適切にアラートを設定しないとメンバーの疲弊に繋がってしまうのも事実です。
アラートとモニタリングの混同は珍しいことではなく、モニタリングはシステムから永続的にデータを収集することが目的です。アラートはモニタリングが提供する副産物にしか過ぎないということです。
アラートは測定可能で、意味のある（ユーザ体験を損なう）影響がある場合にのみ存在する必要があると書かれています。
ユーザ体験を損なう可能性のある場合のみアラートを発報し、その詳細を確認するためにモニタリングを行う。つまり、下位レベルのデータポイント（メトリクス、イベント、ログ）は必ずしもアラートのトリガーである必要はありません。
既存のアラートが本当に「価値がある」かどうかを判断するためには以下のようなことから確認していくと良いと書かれています。
- 問題を解決できる人はどのようにして問題を知るのでしょうか? さらに重要なのは、問題を解決できる人がそれを知るまでにどのくらいの時間がかかるでしょうか?
- 問題の発生中に固有の損失はありますか? 1 時間あたり 1,000 ドルを生み出すオンライン販売システムは、利用できなくなると 1 時間ごとにその金額を失います。
- 問題を解決するにはどれくらい時間がかかりますか? 場合によっては、警戒しているかどうかに関係なく、同じ時間がかかります。しかし、はるかに多くの状況では、最初の項目で特定された期間にわたって問題が解決されないまま放置された場合、解決にはさらに長い時間がかかります (おそらく大幅に長くなる可能性があります)。
- 問題を解決できるスタッフの通常 (「合計負荷」) 料金はいくらですか?
- そのスタッフの「中断コスト」はいくらですか? これは、スタッフが（表面上は）この特定のエラーを待って座っているわけではないことを意味します。それでは、彼らの通常の仕事の価値は何でしょうか? なぜなら、彼らはこの問題に取り組んでいる間はそれをやらないからです。
Kube Weekly
Kubernetesにおける攻撃例
Kubernetesの採用が増えていますが、それと同じくしてサイバー攻撃の主な標的となってきています。
このブログでは、Kubernetesを標的とする攻撃例を取り上げ、リスクを明らかにし、それに対する防御策を取り上げています。
例として以下のような攻撃例があります。
公開されたエンドポイント攻撃
1つ以上のエンドポイントがパブリックに公開されているクラスターが標的になる例です。
攻撃者が公開されたエンドポイントへのアクセスを行い、機密データやリソースを含むクラスターへのさらなるアクセスを行う可能性があります。
攻撃者はクラスターで公開されている脆弱性を調査して、リモートコード実行の脆弱性を持つ公開されたワークロードを発見します。クラスター上のPodにマウントされているサービスアカウントトークンをデフォルト設定で使用している場合、攻撃者はそのトークンを使用してkube-api サーバに対する認証を行うことができます。
ワークロードにSecretがマウントされている場合、事態はさらに深刻なものになります。これにより、さらに機密情報を取得できる可能性があります。
そして、ワークロードが特権コンテナ上で実行されている場合、攻撃者はホストのリソースにアクセスして、機密情報にアクセスしてサービスを中断してしまう可能性があります。
対策としては、脆弱性管理ツールを利用して、脆弱性とクラスタのミスコンフィグを特定して、コードを修正していくことが有効になります。
他にも攻撃例とその対策が載っているので、気になる方はぜひブログを見てみてください。
まとめ
ドキュメント戦略において、ここでもBackstageが挙がっていましたね。
先日のBackstageCONでも様々な先行事例が発表されていました。
今年も12月に入りました。あと1ヶ月頑張っていきましょう。
Discussion