プロンプトと適用範囲
複数のディストリビューションからなるLinuxフリートにおいて、手動デプロイを削減するために、パッケージングリポジトリからOpenTelemetry Injector、自動計装パッケージ、およびCollectorをインストールしたいと考えています。プロジェクト側の説明によると、パッケージングの取り組みは初期段階であり、リポジトリは本番環境レベルのホスティングではなく、パッケージはまだ署名されていません。実験から本番環境に至るまでのセキュリティ境界、検証、権限、およびロールバックを設計してください。
面接官がテストしていること
面接官は、インストールの利便性とサプライチェーンの信頼性を切り離して考えられているか、そしてスクリプトの権限、パッケージの出所、自動計装の副作用、ネットワーク外部送信（egress）、バージョンのロールバックを特定できるかをテストしています。優れた回答では、どの環境で試行可能か、どの環境が待機すべきか、どのような証跡やガードレールが必要かを明示します。
最初に明確にすべき質問
- 対象ホストでは、どのディストリビューション、アーキテクチャ、プロキシ、アップグレードポリシーが実行されていますか？
- Collector、Injector、言語パッケージ、またはすべてのコンポーネントをインストールしますか？
- ホストはsystemdサービス、eBPF権限、および送信先エンドポイントを追加できますか？
- 組織にはどのような署名、アーティファクトプロキシ、SBOM、およびロールバックの要件がありますか？
30秒の回答
「初期段階のリポジトリにある1コマンドスクリプトを本番環境で直接実行することはありません。分離されたホスト上で、パッケージの内容、出所、ハッシュ、権限、systemdユニット、ネットワーク外部送信、アンインストールパスを検査します。未署名のパッケージは短期間の実験にはなり得ますが、サプライチェーンのゲートを迂回することはできません。本番環境の候補には、内部ミラー、署名検証、最小権限、およびバージョン管理されたロールバックが必要です。まずは非クリティカルなホストでカナリア展開を行い、CPU、メモリ、ネットワーク、プロセス起動、データ漏洩、アンインストールの成功を監視し、ガードレールに違反した場合は拡大を停止します。」
ステップごとのソリューション
1. 試行境界の定義
公式リポジトリを本番環境の承認ではなく、実験的なソースとしてラベル付けします。機密データのない再構築可能なホストを選択し、コアデータベース、踏み台サーバー、または高権限のコントロールノードで直接実行することは絶対に避けてください。
2. サプライチェーンの検証
リポジトリのコミット、パッケージバージョン、および依存関係を固定（ピン留め）します。ダウンロードURL、ハッシュ、ビルドの出所、SBOM、および署名ステータスを検証します。未署名パッケージには内部レビューと分離されたプロキシが必要です。スクリプトのtrustedや検証スキップオプションを使用してインストールの失敗を解決しないでください。
3. 権限と副作用の検査
インストールスクリプト、systemdユニット、ファイルパス、ID、ケーパビリティ、eBPF要件、およびファイアウォールの変更を確認します。Injectorが承認されたプロセスのみを対象とし、Collectorが必要なログとメトリクスのみを読み取り、クレデンシャルがプレーンテキストファイルではなく有効期間の短い参照であることを確認します。
4. データ外部送信の制御
OTLPエンドポイント、TLS、プロキシ、リトライ、キュー、および秘匿化（リダクション）ルールをリスト化します。データはまず分離されたバックエンドに送信し、サービス名、ホスト識別子、コマンドライン引数、個人データがテナントやリージョンの境界を越えていないことを確認します。ネットワークが利用できない場合の明示的な破棄またはローカルバッファ動作を定義します。
5. カナリアメトリクスの設計
ディストリビューション、アーキテクチャ、およびビジネスの重要度ごとにロールアウトします。インストールの成功、プロセスの起動、CPUとメモリ、eBPFエラー、Collectorキュー、外部送信、機密フィールドの一致、およびアンインストールの成功を監視します。ガードレールに違反した場合は新規ホストの受け入れを停止し、問題を隠すために権限を拡大しないでください。
6. ロールバックとアップグレード
元のパッケージ、設定、systemdの状態、およびファイルマニフェストを保持します。InjectorとCollectorを停止し、古いパッケージとファイアウォールの状態を復元することでロールバックします。バージョンごとに再現可能なアンインストールコマンドと復旧時間を記録します。署名、ホストされたアーティファクト、およびセキュリティレビューが成熟するまで、試行範囲を限定したまま維持します。
模範回答
このリポジトリは実験的なものとして扱います。再構築可能なホスト上で、コミット、ハッシュ、SBOM、署名、依存関係、systemd、権限、eBPF、外部送信を検証します。未署名のパッケージは本番環境には導入しません。Injectorの対象を制限し、最小権限のCollectorアクセス、短期間のクレデンシャル、TLS、秘匿化、および分離されたバックエンドを使用します。インストール、リソース、キュー、外部送信、およびアンインストールのメトリクスを監視しながら、ディストリビューションとビジネスの重要度ごとにカナリア展開を行います。古いパッケージ、設定、復旧手順を保持し、障害発生時には新規ホストへの適用を停止して個別にロールバックします。内部ミラーと署名プロセスが成熟した後にのみ拡大します。
よくある間違い
- 1コマンドスクリプトを本番環境で実行する → 権限と出所が不明 → まず分離し、レビューし、内部でミラーリングする。
- 未署名パッケージを無視する → 出所を証明できない → ハッシュ、SBOM、および署名ゲートを必須とする。
- Injectorにあらゆるプロセスを対象とさせる → ビジネスおよびプライバシーのリスクが拡大する → プロセスの許可リストを使用する。
- インストールのみを監視する → 実行時データが漏洩する可能性がある → 外部送信、秘匿化、およびリソースメトリクスを監視する。
- アンインストールや復旧のマニフェストを保持しない → 障害発生時に手作業でのフォレンジックが必要になる → ロールバック手順をバージョン管理する。
フォローアップの質問と回答
未署名パッケージは完全にテスト不可能ですか？
機密データのない、分離された使い捨てのホスト上で、実験用として明確にラベル付けされていれば、短期間テストすることは可能です。テスト結果を本番環境への承認として扱うことはできません。
なぜスクリプトに最初からrootアクセスを与えてはいけないのですか？
rootはスクリプトと依存関係の影響範囲（ブラスト半径）を拡大します。まず必要な権限を確認し、その後、専用アカウント、ケーパビリティ、および制御されたsystemdサービスを使用してください。
自動計装がビジネスロジックに変更を加えていないことをどのように証明しますか？
エラー、レイテンシ、起動引数、クリティカルパスについて、同じバージョンのホスト間で比較します。新しいスパン、ログ、ネットワーク接続を検査し、異常が発生した場合はビジネスコードを変更するのではなくInjectorを無効化します。
いつ本番環境に導入できますか？
制御されたアーティファクトミラー、検証可能な署名、SBOM、最小権限、外部送信の監査、再現可能なロールバック、および段階的な受け入れを必須とします。初期段階のリポジトリが利用可能であることだけをもって、本番環境への準備が整ったと判断してはなりません。