同じKubernetesポッド内の別のコンテナでコマンドをトリガーする安全な方法はありますか?
ネットワーク呼び出しを受け入れ、同じポッド内の他のコンテナーでコマンドをトリガーできるエージェントサービスを作成しています。もちろん、これはポッドの通常のユースケースではありませんが、JenkinsやKubernetesプラグインなど、一部のCIツールが同様のことを行うことは知っています。
現在、エージェントコンテナでkubectlを使用して動作させて実行kubectl exec <pod> -c <container> -- <command>
していますが、正常に動作しています。しかし、それは脆弱性の大きなチャンスのようです。
エージェントがkubectlexecアクセス権を持つためにはpod/exec
、同じ名前空間内のすべてのポッドへのアクセスを許可する特権を持っている必要があります。
rules:
- apiGroups: [""]
resources: ["pods", "pods/exec"]
verbs: ["get", "list", "watch", "create"]
これにアプローチするためのより良い方法がない場合は、同じポッドへの呼び出しのみを受け入れるように、execコマンドをエージェントに焼き付けます。
しかし、私の大きな懸念は、エージェントから未知のコードを実行し、必要以上にアクセスできるようにすることです。Jenkinsの例では、誰かがコードをテストするパイプラインを持っていて、それらが悪意があり、実際にkubernetes-clientライブラリを使用して名前空間内の他のポッドを呼び出すテストが含まれている場合、有効にしながらそれをどのように防止しますかコンテナ間の通信?
何か提案をいただければ幸いです。
回答
ポッドでコマンドを実行したいが、kube-apiserverをヒットしたくないようです。また、アプリケーションがトリガーをリッスンしていて(ある種のベースのブローカーまたはアプリケーションで)、コマンドを実行しているように見えます。
私の提案は、を使用して同じポッドで実行するのではなく、アプリケーションの「シェルアウト」でコマンド自体をkubectl
実行することexec
です。アプリケーションの記述言語を指定していませんが、ほとんどの一般的な言語には、execシステム呼び出しを実行したりプロセスを管理したりするためのライブラリがあります。つまり、Golang、Pythonなどです。
✌️