# クラウドネイティブセキュリティの概要

LLMS index: [llms.txt](/llms.txt)

---

<!-- overview -->

この概要では、クラウドネイティブセキュリティにおけるKubernetesのセキュリティを考えるためのモデルを定義します。

<div class="alert alert-danger" role="note"><h4 class="alert-heading">警告:</h4>コンテナセキュリティモデルは、実証済の情報セキュリティポリシーではなく提案を提供します。</div>


<!-- body -->

## クラウドネイティブセキュリティの４C

セキュリティは階層で考えることができます。クラウドネイティブの4Cは、クラウド、クラスター、コンテナ、そしてコードです。


<div class="alert alert-info" role="note"><h4 class="alert-heading">備考:</h4>階層化されたアプローチは、セキュリティに対する<a href="https://en.wikipedia.org/wiki/Defense_in_depth_(computing)">多層防御</a>のアプローチを強化します。これはソフトウェアシステムを保護するベストプラクティスとして幅広く認知されています。</div>




<figure>
    <img src="/images/docs/4c.png"/> <figcaption>
            <h4>クラウドネイティブセキュリティの４C</h4>
        </figcaption>
</figure>

クラウドネイティブセキュリティモデルの各レイヤーは次の最も外側のレイヤー上に構築します。コードレイヤーは、強固な基盤(クラウド、クラスター、コンテナ)セキュリティレイヤーから恩恵を受けます。コードレベルのセキュリティに対応しても基盤レイヤーが低い水準のセキュリティでは守ることができません。

## クラウド

いろいろな意味でも、クラウド(または同じ場所に設置されたサーバー、企業のデータセンター)はKubernetesクラスターの[トラステッド・コンピューティング・ベース](https://en.wikipedia.org/wiki/Trusted_computing_base)です。クラウドレイヤーが脆弱な(または脆弱な方法で構成されている)場合、この基盤の上に構築されたコンポーネントが安全であるという保証はありません。各クラウドプロバイダーは、それぞれの環境でワークロードを安全に実行させるためのセキュリティの推奨事項を作成しています。

### クラウドプロバイダーのセキュリティ

Kubernetesクラスターを所有しているハードウェアや様々なクラウドプロバイダー上で実行している場合、セキュリティのベストプラクティスに関するドキュメントを参考にしてください。ここでは人気のあるクラウドプロバイダーのセキュリティドキュメントの一部のリンクを紹介します。



 





<table><caption style="display: none;">Cloud provider security</caption>
	<thead>
			<tr>
					<th>IaaSプロバイダー</th>
					<th>リンク</th>
			</tr>
	</thead>
	<tbody>
			<tr>
					<td>Alibaba Cloud</td>
					<td><a href="https://www.alibabacloud.com/trust-center">https://www.alibabacloud.com/trust-center</a></td>
			</tr>
			<tr>
					<td>Amazon Web Services</td>
					<td><a href="https://aws.amazon.com/security/">https://aws.amazon.com/security/</a></td>
			</tr>
			<tr>
					<td>Google Cloud Platform</td>
					<td><a href="https://cloud.google.com/security/">https://cloud.google.com/security/</a></td>
			</tr>
			<tr>
					<td>Huawei Cloud</td>
					<td><a href="https://www.huaweicloud.com/intl/ja-jp/securecenter/overallsafety.html">https://www.huaweicloud.com/intl/ja-jp/securecenter/overallsafety.html</a></td>
			</tr>
			<tr>
					<td>IBM Cloud</td>
					<td><a href="https://www.ibm.com/cloud/security">https://www.ibm.com/cloud/security</a></td>
			</tr>
			<tr>
					<td>Microsoft Azure</td>
					<td><a href="https://docs.microsoft.com/en-us/azure/security/azure-security">https://docs.microsoft.com/en-us/azure/security/azure-security</a></td>
			</tr>
			<tr>
					<td>Oracle Cloud Infrastructure</td>
					<td><a href="https://www.oracle.com/security/">https://www.oracle.com/security/</a></td>
			</tr>
			<tr>
					<td>VMWare VSphere</td>
					<td><a href="https://www.vmware.com/solutions/security/hardening-guides">https://www.vmware.com/solutions/security/hardening-guides</a></td>
			</tr>
	</tbody>
</table>


### インフラのセキュリティ {#infrastructure-security}

Kubernetesクラスターのインフラを保護するための提案です。



 





<table><caption style="display: none;">Infrastructure security</caption>
	<thead>
			<tr>
					<th>Kubernetesインフラに関する懸念事項</th>
					<th>推奨事項</th>
			</tr>
	</thead>
	<tbody>
			<tr>
					<td>API Server(コントロールプレーン)へのネットワークアクセス</td>
					<td>Kubernetesコントロールプレーンへのすべてのアクセスは、インターネット上での一般公開は許されず、クラスター管理に必要なIPアドレスに制限するネットワークアクセス制御リストによって制御されます。</td>
			</tr>
			<tr>
					<td>Nodeへのネットワークアクセス</td>
					<td>Nodeはコントロールプレーンの特定ポート <em>のみ</em> 接続(ネットワークアクセス制御リストを介して)を受け入れるよう設定し、NodePortとLoadBalancerタイプのKubernetesのServiceに関する接続を受け入れるよう設定する必要があります。可能であれば、それらのNodeはパブリックなインターネットに完全公開しないでください。</td>
			</tr>
			<tr>
					<td>KubernetesからのクラウドプロバイダーAPIへのアクセス</td>
					<td>各クラウドプロバイダーはKubernetesコントロールプレーンとNodeに異なる権限を与える必要があります。<a href="https://en.wikipedia.org/wiki/Principle_of_least_privilege">最小権限の原則</a>に従い、管理に必要なリソースに対してクラウドプロバイダーへのアクセスをクラスターに提供するのが最善です。<a href="https://github.com/kubernetes/kops/blob/master/docs/iam_roles.md#iam-roles">Kopsドキュメント</a>にはIAMのポリシーとロールについての情報が記載されています。</td>
			</tr>
			<tr>
					<td>etcdへのアクセス</td>
					<td>etcd(Kubernetesのデータストア)へのアクセスはコントロールプレーンのみに制限すべきです。設定によっては、TLS経由でetcdを利用する必要があります。詳細な情報は<a href="https://github.com/etcd-io/etcd/tree/master/Documentation">etcdドキュメント</a>を参照してください。</td>
			</tr>
			<tr>
					<td>etcdの暗号化</td>
					<td>可能な限り、保存時に全ドライブを暗号化することは良いプラクティスですが、etcdはクラスター全体(Secretを含む)の状態を保持しているため、そのディスクは特に暗号化する必要があります。</td>
			</tr>
	</tbody>
</table>


## クラスター

Kubernetesを保護する為には２つの懸念事項があります。

* 設定可能なクラスターコンポーネントの保護
* クラスターで実行されるアプリケーションの保護

### クラスターのコンポーネント {#cluster-components}

想定外または悪意のあるアクセスからクラスターを保護して適切なプラクティスを採用したい場合、[クラスターの保護](/docs/tasks/administer-cluster/securing-a-cluster/)に関するアドバイスを読み従ってください。

### クラスター内のコンポーネント(アプリケーション) {#cluster-applications}

アプリケーションを対象にした攻撃に応じて、セキュリティの特定側面に焦点をあてたい場合があります。例:他のリソースとの連携で重要なサービス(サービスA)と、リソース枯渇攻撃に対して脆弱な別のワークロード(サービスB)が実行されている場合、サービスBのリソースを制限していないとサービスAが危険にさらされるリスクが高くなります。次の表はセキュリティの懸念事項とKubernetesで実行されるワークロードを保護するための推奨事項を示しています。


ワークロードセキュリティに関する懸念事項 | 推奨事項 |
------------------------------ | --------------------- |
RBAC認可(Kubernetes APIへのアクセス) | https://kubernetes.io/ja/docs/reference/access-authn-authz/rbac/
認証 | https://kubernetes.io/docs/concepts/security/controlling-access/ |
アプリケーションのSecret管理(およびetcdへの保存時に暗号化) | https://kubernetes.io/ja/docs/concepts/configuration/secret/ <br> https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/ |
PodSecurityPolicy | https://kubernetes.io/docs/concepts/policy/pod-security-policy/ |
Quality of Service (およびクラスターリソース管理) | https://kubernetes.io/ja/docs/tasks/configure-pod-container/quality-service-pod/ |
NetworkPolicy | https://kubernetes.io/ja/docs/concepts/services-networking/network-policies/ |
Kubernetes IngressのTLS | https://kubernetes.io/ja/docs/concepts/services-networking/ingress/#tls |


## コンテナ

コンテナセキュリティは本ガイドの範囲外になります。このトピックを検索するために一般的な推奨事項とリンクを以下に示します。

コンテナに関する懸念事項 | 推奨事項 |
------------------------------ | -------------- |
コンテナの脆弱性スキャンとOS依存のセキュリティ | イメージをビルドする手順の一部として、既知の脆弱性がないかコンテナをスキャンする必要があります。 |
イメージの署名と実施 | コンテナイメージを署名し、コンテナの中身に関する信頼性を維持します。 |
特権ユーザーを許可しない | コンテナの構成時に、コンテナの目的を実行するために必要最低限なOS特権を持ったユーザーをコンテナ内部に作成する方法のドキュメントを参考にしてください。 |

## コード

アプリケーションコードは、あなたが最も制御できる主要な攻撃対象のひとつです。アプリケーションコードを保護することはKubernetesのセキュリティトピックの範囲外ですが、アプリケーションコードを保護するための推奨事項を以下に示します。

### コードセキュリティ



 





<table><caption style="display: none;">Code security</caption>
	<thead>
			<tr>
					<th>コードに関する懸念事項</th>
					<th>推奨事項</th>
			</tr>
	</thead>
	<tbody>
			<tr>
					<td>TLS経由のアクセスのみ</td>
					<td>コードがTCP通信を必要とする場合は、事前にクライアントとのTLSハンドシェイクを実行してください。 いくつかの例外を除いて、全ての通信を暗号化してください。さらに一歩すすめて、サービス間のネットワークトラフィックを暗号化することはよい考えです。これは、サービスを特定した2つの証明書で通信の両端を検証する相互認証、または<a href="https://en.wikipedia.org/wiki/Mutual_authentication">mTLS</a>して知られているプロセスを通じて実行できます。</td>
			</tr>
			<tr>
					<td>通信ポートの範囲制限</td>
					<td>この推奨事項は一目瞭然かもしれませんが、可能なかぎり、通信とメトリクス収集に必要不可欠なサービスのポートのみを公開します。</td>
			</tr>
			<tr>
					<td>サードパティに依存するセキュリティ</td>
					<td>既知の脆弱性についてアプリケーションのサードパーティ製ライブラリーを定期的にスキャンすることを推奨します。それぞれの言語は自動でこのチェックを実行するツールを持っています。</td>
			</tr>
			<tr>
					<td>静的コード解析</td>
					<td>ほとんどの言語ではコードのスニペットを解析して、安全でない可能性のあるコーディングを分析する方法が提供しています。可能な限り、コードベースでスキャンして、よく起こるセキュリティエラーを検出できる自動ツールを使用してチェックを実行すべきです。一部のツールはここで紹介されています。 <a href="https://owasp.org/www-community/Source_Code_Analysis_Tools">https://owasp.org/www-community/Source_Code_Analysis_Tools</a></td>
			</tr>
			<tr>
					<td>動的プロービング攻撃</td>
					<td>よく知られているいくつかのサービス攻撃をサービスに対して試すことができる自動ツールがいくつかあります。これにはSQLインジェクション、CSRF、そしてXSSが含まれます。よく知られている動的解析ツールは<a href="https://www.zaproxy.org/">OWASP Zed Attack proxy</a>toolです。</td>
			</tr>
	</tbody>
</table>


## 次の項目

関連するKubernetesセキュリティについて学びます。

* [Podセキュリティの標準](/ja/docs/concepts/security/pod-security-standards/)
* [Podのネットワークポリシー](/ja/docs/concepts/services-networking/network-policies/)
* [Kubernetes APIへのアクセスを制御する](/docs/concepts/security/controlling-access)
* [クラスターの保護](/docs/tasks/administer-cluster/securing-a-cluster/)
* コントロールプレーンとの[通信時のデータ暗号化](/docs/tasks/tls/managing-tls-in-a-cluster/)
* [保存時のデータ暗号化](/docs/tasks/administer-cluster/encrypt-data/)
* [Kubernetes Secret](/ja/docs/concepts/configuration/secret/)