HatでOpenShiftのサポートをしているid:nekopです。2019の2日目のエントリです。CNIというものが利用されています。proxyへ流すためにiptablesのルールを利用しています。proxyと共にアプリケーションのPodへInjectされて利用されます。要はroot権限)として設定される必要があります。特権コンテナを許可してしまうと、アプリケーションのすぐ横にセキュリティレベルの弱いコンテナが配置されることになりますし、特権コンテナ起動が許可されているサービスアカウントを流用して他の悪意のある特権コンテナを起動していろいろできてしまったりするので回避したいところです。CNIというCNIプラグインです。contaienrではなくCNIの仕組み内からiptablesのルール適用を行っています。4.2上でどのように構成されているか見ていきたいと思います。この例ではtest-istioというプロジェクトを対象に見ていきます。MeshではServiceMeshMemberRollsというリソースにIstioを使うプロジェクトを記述するとセットアップが実行されます。4ではmultus-cniというCNIプラグインを柔軟に選択できるCNIメタプラグインが標準となっており、上記設定を行うとMultusのNetworkAttachmentDefinitionというリソースがプロジェクトに作成され、istio-cniが有効化されます。NetworkAttachmentDefinitionの中身は利用するCNIの名前だけ指定されているものです。Meshに含まれるDaemonSetが各ノードのmultus設定ディレクトリにCNI設定ファイルを配置していて、その名前を指定しています。/host/etc/cni/このDaemonSetによって各ホストに以下のファイル群が配置されています。/etc/cni/multus/net.d/istio-cni.conf/etc/cni/multus/net.d/istio-cni.kubeconfig/opt/cni/bin/istio-cni/opt/cni/bin/istio-iptables.sh実際のCNI設定内容は以下のようになっています。Meshでは、このようにDaemonSetでMultusにistio-cni設定を配置、MultusのNetworkAttachmentDefinitionで有効化するという仕組みを利用して特権コンテナを利用しない、より安全なIstioのセットアップを実現しています。HatでOpenShiftのサポートをしているid:nekopです。各記事は著者の見解によるものでありその所属組織を代表する公式なものではありません。その内容については非公式見解を含みます。スターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。