建站
咨詢
售后
建站咨詢
新聞中心
云原生安全概述
本概述定義了一個模型，用于在 Cloud Native 安全性上下文中考慮 Kubernetes 安全性。
成都創(chuàng)新互聯(lián)公司是一家專業(yè)提供南豐企業(yè)網(wǎng)站建設(shè),專注與成都網(wǎng)站建設(shè)、成都做網(wǎng)站、H5響應(yīng)式網(wǎng)站、小程序制作等業(yè)務(wù)。10年已為南豐眾多企業(yè)、政府機構(gòu)等服務(wù)。創(chuàng)新互聯(lián)專業(yè)網(wǎng)站建設(shè)公司優(yōu)惠進行中。
Warning: 此容器安全模型只提供建議，而不是經(jīng)過驗證的信息安全策略。
云原生安全的 4 個 C
你可以分層去考慮安全性，云原生安全的 4 個 C 分別是云（Cloud）、集群（Cluster）、容器（Container）和代碼（Code）。
Note: 這種分層方法增強了深度防護方法在安全性方面的 防御能力，該方法被廣泛認為是保護軟件系統(tǒng)的最佳實踐。
云原生安全的 4C
云原生安全模型的每一層都是基于下一個最外層，代碼層受益于強大的基礎(chǔ)安全層（云、集群、容器）。 你無法通過在代碼層解決安全問題來為基礎(chǔ)層中糟糕的安全標準提供保護。
云
在許多方面，云（或者位于同一位置的服務(wù)器，或者是公司數(shù)據(jù)中心）是 Kubernetes 集群中的 可信計算基。 如果云層容易受到攻擊（或者被配置成了易受攻擊的方式），就不能保證在此基礎(chǔ)之上構(gòu)建的組件是安全的。 每個云提供商都會提出安全建議，以在其環(huán)境中安全地運行工作負載。
云提供商安全性
如果你是在你自己的硬件或者其他不同的云提供商上運行 Kubernetes 集群， 請查閱相關(guān)文檔來獲取最好的安全實踐。
下面是一些比較流行的云提供商的安全性文檔鏈接：
| IaaS 提供商 | 鏈接 |
|---|---|
| Alibaba Cloud | https://www.alibabacloud.com/trust-center |
| Amazon Web Services | https://aws.amazon.com/security/ |
| Google Cloud Platform | https://cloud.google.com/security/ |
| IBM Cloud | https://www.ibm.com/cloud/security |
| Microsoft Azure | https://docs.microsoft.com/en-us/azure/security/azure-security |
| Oracle Cloud Infrastructure | https://www.oracle.com/security/ |
| VMWare VSphere | https://www.vmware.com/security/hardening-guides.html |
基礎(chǔ)設(shè)施安全
關(guān)于在 Kubernetes 集群中保護你的基礎(chǔ)設(shè)施的建議：
| Kubernetes 基礎(chǔ)架構(gòu)關(guān)注領(lǐng)域 | 建議 |
|---|---|
| 通過網(wǎng)絡(luò)訪問 API 服務(wù)（控制平面） | 所有對 Kubernetes 控制平面的訪問不允許在 Internet 上公開，同時應(yīng)由網(wǎng)絡(luò)訪問控制列表控制，該列表包含管理集群所需的 IP 地址集。 |
| 通過網(wǎng)絡(luò)訪問 Node（節(jié)點） | 節(jié)點應(yīng)配置為 僅能 從控制平面上通過指定端口來接受（通過網(wǎng)絡(luò)訪問控制列表）連接，以及接受 NodePort 和 LoadBalancer 類型的 Kubernetes 服務(wù)連接。如果可能的話，這些節(jié)點不應(yīng)完全暴露在公共互聯(lián)網(wǎng)上。 |
| Kubernetes 訪問云提供商的 API | 每個云提供商都需要向 Kubernetes 控制平面和節(jié)點授予不同的權(quán)限集。為集群提供云提供商訪問權(quán)限時，最好遵循對需要管理的資源的最小特權(quán)原則。Kops 文檔提供有關(guān) IAM 策略和角色的信息。 |
| 訪問 etcd | 對 etcd（Kubernetes 的數(shù)據(jù)存儲）的訪問應(yīng)僅限于控制平面。根據(jù)配置情況，你應(yīng)該嘗試通過 TLS 來使用 etcd。更多信息可以在 etcd 文檔中找到。 |
| etcd 加密 | 在所有可能的情況下，最好對所有存儲進行靜態(tài)數(shù)據(jù)加密，并且由于 etcd 擁有整個集群的狀態(tài)（包括機密信息），因此其磁盤更應(yīng)該進行靜態(tài)數(shù)據(jù)加密。 |
集群
保護 Kubernetes 有兩個方面需要注意：
- 保護可配置的集群組件
- 保護在集群中運行的應(yīng)用程序
集群組件
如果想要保護集群免受意外或惡意的訪問，采取良好的信息管理實踐，請閱讀并遵循有關(guān)保護集群的建議。
集群中的組件（你的應(yīng)用）
根據(jù)你的應(yīng)用程序的受攻擊面，你可能需要關(guān)注安全性的特定面，比如： 如果你正在運行中的一個服務(wù)（A 服務(wù)）在其他資源鏈中很重要，并且所運行的另一工作負載（服務(wù) B） 容易受到資源枯竭的攻擊，則如果你不限制服務(wù) B 的資源的話，損害服務(wù) A 的風(fēng)險就會很高。
容器
容器安全性不在本指南的探討范圍內(nèi)。下面是一些探索此主題的建議和連接：
| 容器關(guān)注領(lǐng)域 | 建議 |
|---|---|
| 容器漏洞掃描和操作系統(tǒng)依賴安全性 | 作為鏡像構(gòu)建的一部分，你應(yīng)該掃描你的容器里的已知漏洞。 |
| 鏡像簽名和執(zhí)行 | 對容器鏡像進行簽名，以維護對容器內(nèi)容的信任。 |
| 禁止特權(quán)用戶 | 構(gòu)建容器時，請查閱文檔以了解如何在具有最低操作系統(tǒng)特權(quán)級別的容器內(nèi)部創(chuàng)建用戶，以實現(xiàn)容器的目標。 |
| 使用帶有較強隔離能力的容器運行時 | 選擇提供較強隔離能力的容器運行時類。 |
代碼
應(yīng)用程序代碼是你最能夠控制的主要攻擊面之一，雖然保護應(yīng)用程序代碼不在 Kubernetes 安全主題范圍內(nèi)，但以下是保護應(yīng)用程序代碼的建議：
代碼安全性
| 代碼關(guān)注領(lǐng)域 | 建議 |
|---|---|
| 僅通過 TLS 訪問 | 如果你的代碼需要通過 TCP 通信，請?zhí)崆芭c客戶端執(zhí)行 TLS 握手。除少數(shù)情況外，請加密傳輸中的所有內(nèi)容。更進一步，加密服務(wù)之間的網(wǎng)絡(luò)流量是一個好主意。這可以通過被稱為雙向 TLS 或 mTLS 的過程來完成，該過程對兩個證書持有服務(wù)之間的通信執(zhí)行雙向驗證。 |
| 限制通信端口范圍 | 此建議可能有點不言自明，但是在任何可能的情況下，你都只應(yīng)公開服務(wù)上對于通信或度量收集絕對必要的端口。 |
| 第三方依賴性安全 | 最好定期掃描應(yīng)用程序的第三方庫以了解已知的安全漏洞。每種編程語言都有一個自動執(zhí)行此檢查的工具。 |
| 靜態(tài)代碼分析 | 大多數(shù)語言都提供給了一種方法，來分析代碼段中是否存在潛在的不安全的編碼實踐。只要有可能，你都應(yīng)該使用自動工具執(zhí)行檢查，該工具可以掃描代碼庫以查找常見的安全錯誤，一些工具可以在以下連接中找到：https://owasp.org/www-community/Source_Code_Analysis_Tools |
| 動態(tài)探測攻擊 | 你可以對服務(wù)運行一些自動化工具，來嘗試一些眾所周知的服務(wù)攻擊。這些攻擊包括 SQL 注入、CSRF 和 XSS。OWASP Zed Attack 代理工具是最受歡迎的動態(tài)分析工具之一。 |
網(wǎng)站標題：創(chuàng)新互聯(lián)kubernetes教程：Kubernetes云原生安全概述
本文URL：http://www.dlmjj.cn/article/cdpggce.html
