# NeuVector Onboarding and Best Practices Guide
<style>
.indent-title-1{
margin-left: 1em;
}
.indent-title-2{
margin-left: 2em;
}
.indent-title-3{
margin-left: 3em;
}
</style>
## Preface
<div class="indent-title-1">
可以透過點擊展開以下目錄，選擇想看的內容，跳轉至特定章節
:::warning
:::spoiler 文章目錄
[TOC]
:::
</div>
## Neuvector 各 Container 所扮演的角色
- **Manager**: 顯示 web-based console 的 stateless container。通常只需要一個，而且可以在任何地方執行。Manager 失敗不會影響 Controller 或 enforcer 的任何作業。但是，一些通知（事件）和最近的連線資料會被 Manager 快取到記憶體中，因此檢視這些資料會受到影響。
- **Controller**: NeuVector 的 「control plane」，應該部署在 HA 的架構中，以便在節點故障時不會遺失設定。Controller 可在任何地方執行，但在許多情況下，由於其關鍵性，客戶會選擇將其放置在「management」、master node或 infra node 上。
- **enforcer**: 此 container 作為 daemonset 部署，因此每個要保護的節點上都有一個 Enforcer。通常會部署到每個 Worker 節點，但也可以部屬到 master 和 infra 節點。注意：如果 Enforcer 不在叢集中的節點上，且連線來自該節點上的 Pod，這些 workloads 在 NeuVector 中會顯示為「unmanaged」workloads。
- **scanner**: 根據 Controller 的指示，使用內建的 CVE 資料庫執行弱點掃描。可部署多個 scanner 以增加掃描容量。 scanner 可在任何地方執行，但通常在 Controller 執行的節點上執行。scanner 節點的大小考量請參閱下文。當 scanner 用於建立階段掃描時，也可以獨立調用，例如在 pipeline 中觸發掃描、擷取結果並停止 scanner 。 scanner 包含最新的 CVE 資料庫，因此應每日更新。
- **updater**: 當需要更新 CVE 資料庫時，updater 會透過 Kubernetes cron job 觸發 scanner 的更新。請務必針對您的環境進行設定。
## Architecture
<div class="indent-title-1">
最簡單的部署模式是讓 Kubernetes 或 orchestrator 根據每個 Container 的記憶體（可能還有 cpu）需求，決定將每個 Contiainer 放置在哪裡。對於每個節點資源相近的叢集，而且可以保證所有 workloads 都有足夠的空間，這樣就沒問題了。其他考慮因素，例如獨立節點的維護週期、網路隔離和大小，都可能影響 NeuVector containers 的放置位置（在每個受保護節點上執行的 Enforcer 除外）。 下圖顯示了部署模式範例以及 NeuVector 部署的彈性 :
1. Kubernetes 可以將 NeuVector Container 放置在任何節點 (在此例中為 worker 節點) 上的部署，除非也啟用了調度至 Master node。在 EKS、AKS 等公有雲管理服務中，NeuVector 只能在 worker 節點上執行。最常見的部署。
2. NeuVector control plane 的 Container 和 scanner 是透過 taints/tolerations 或 labels 放置在 Master node 上。Master node 可根據 control plane 的需求適當調整 node 資源的大小。
3. 類似於 2，但會選擇 node 來執行 NeuVector control plane 和 scanners。這些節點可以是 worker node，而且大小適當。請注意，其中一個 NeuVector node 也允許 workloads 在上面執行，而其他節點則不允許 workloads 在上面執行。
NeuVectorcontrol plane 和 scanners 在 Master node 或 專用節點上執行，但由於 Master node 或專用節點上沒有 workloads ，因此不會在主節點或專用節點上部署 Enforcer。在這種情況下，NeuVector 不會監控在主節點上執行的 system containers，這與公有雲的情況類似。
</div>
### Q&A
* Q: 是否可以在同一個節點上執行兩個或兩個以上的 Controller？
A: 可以，但如果節點領便當，該節點上的所有 Controller 都會丟失。範例部署的 yaml 中有一個「affinity」設定，預設會偏好在不同節點上部署 Controller。
```yaml=
apiVersion: apps/v1
kind: Deployment
metadata:
name: neuvector-controller-pod
namespace: neuvector
spec:
template:
spec:
affinity:
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 100
podAffinityTerm:
labelSelector:
matchExpressions:
- key: app
operator: In
values:
- neuvector-controller-pod
topologyKey: "kubernetes.io/hostname"
```
> 這個 AntiAffinity 規則告訴 Kubernetes 的 scheduler，當指派新的 Pod 時，應該儘量避免將它們指派到已經有標籤 `app=neuvector-controller-pod` 的 Pod 所在的節點上。
* Q: 我們應該在 master 節點和 infra 節點上部署 Enforcer 嗎？
A: 是的，如果可能，建議這樣做，這樣它也可以監控這些節點上的 Container 和網路流量。
## Sizing and Scale
<div class="indent-title-1">
NeuVector Containers 需要足夠的記憶體和 cpu 才能正常運作。這是規劃部署架構時最重要的考量。確保每種 NeuVector Containers 的最低需求 (通常為 1GB RAM) 已經分配且可用。在某些情況下，這應該增加，例如 :
* **Large image scanning**。Scanner Containers 必須有足夠的記憶體，才能將要掃描的 Container images 拉入記憶體並展開。如果要掃瞄大於 1GB 的 Container images ，請將掃瞄機的記憶體增加至略高於預期的最大 Container images 大小。
* **在保護模式下，預期網路連線數很高**。Enforcer 在保護（線上防火牆封鎖）模式下需要 CPU 和記憶體來保持和檢查連線及可能的有效負載 (DLP)。增加記憶體並將一個 CPU 核心專用於 Enforcer 可確保足夠的封包過濾能力。
:::info
Tip： 在 NeuVector Container 上設定不足的 Pod 資源限制，可能會導致意想不到的行為。我們建議您不要在 NeuVector Pod 上設定任何記憶體或 CPU 約束（最大值），如果有需要，請確保根據 staging/production 環境（目標 workloads 規模）中的實際效能特性，有足夠的可用空間。
:::
</div>
### 其他擴充考量
* **K8s 叢集中的節點數量**。隨著叢集中節點數量的增加，從每個 enforcer 到 controllers 的網路連接將共同增加。此外，在 Web 控制台中檢視節點的實際管理可能會變得更具挑戰性。
* **節點上的 Pod（ workloads ）數量**。節點上 Pod 的數量會影響資源消耗，並可能影響網路流量 (節點上 Pod 與 Pod 之間或與其他節點之間的網路流量)。NeuVector Enforcer 也將會有更多的 Pods 來收集掃描資料和合規性資料，以傳送給 controllers。
* 叢集中的 Namespaces、Containers 和其他資產數量。隨著 Containers、 Namespaces、群組和其他資產的增加，主控台中的各種顯示會變得更繁忙，可能需要更多的時間來載入。大多數畫面都有篩選器可用，以快速隔離要檢視的 Namespaces或 Containers/pod。
* Registry 中要掃描 Container images 的數量。如果 Registry 中的 Container images 數量超過一千個，且/或掃描或重新掃描整個 Registry/repository 所需的時間超過預期，請考慮在不同節點上部署多個 scanner pod。請記住，每個 scanner pod 會在掃描期間消耗其主機上的資源。自動擴展功能可設定為自動擴展可用 scanner pod 的數量，以滿足需求。
* 聯邦中的叢集數量。多叢集 Primary 會在其與遠端叢集之間啟動雙向連線。此外，如果部署了聯邦規則，這些規則會在發生任何變更時推送至所有遠端叢集。
<div class="indent-title-1">
:::info
提示： 在與預期生產環境相似的環境中，觀察所有 pod（包括 NeuVector）的記憶體和 CPU 消耗統計，以確保沒有觀察到任何不利影響。
:::
:::info
提示：在網路拓樸中，選擇一個或多個 namespaces 和核取標記，以將檢視限制為選取的物件。這將使地圖的載入速度更快。
:::
</div>
### Q&A
* Q：運行 Controller 的 Host 主機最低規格為何？
A：假設 Controller 將與其他系統的 Containers 或 workloads 一起執行，我們建議至少使用 16 GB RAM 和 4 個 CPU 核心。
* Q：NeuVector 最多可支援多少節點？
A：NeuVector 沒有硬性的限制，但是根據環境和主機資源的不同，超過 500 個節點的叢集可能會遇到實際的困難。
## Deployment and Initial Configuration
### Q&A
* Q：樣本部署預設值需要做哪些變更？
A：變更可能包括：
1. Manager Service 的存取方法。Loadbalancer、nodeport、ingress controllers ...等。
2. 如果從不同的 Registries 拉取重新命名或重新標記的 Container Image。就要修改 Container Image Path's/Registries/names/version。
3. Container run-time 的 volume mounts。預設 containerd、CRI-O、docker 及其他需要變更磁碟區掛載的 run-times。
4. 多叢集 (主叢集/遠端叢集)。如果需要多叢集，請啟用 service access。
5. Controller、scanner Replicas 的數量。Controller 的 Replcas 預設值為 3。
6. 用於 Control-plane 節點部署的 Taints/tolerations。用於控制 Controller 被部署在哪些節點，或 enforcers 是否應該部署在 master node 上。
## Managing NeuVector
<div class="indent-title-1">
大多數 NeuVector 部署至少部分是透過網頁式主控台來管理。然而，REST API、CLI、configMaps 和 CRD 都可用於 non-console-based (非控制台管理)。
:::info
Tip： 在「My Profile」功能表 (右上方) 中，增加「Session Timeout」，這樣您就不會在 5 分鐘後登出。
:::
簡單的部署可以使用整合式 load balancer (例如 EKS、AKS、GKE、IKS 上的 load balancer) 來啟用 Manager 服務的外部存取，或是開放一個 nodePort 供存取。請注意，nodePort 存取有其安全性考量，因為它會在每個節點上開放連接埠供外部存取，而不是強制透過 load balancer 或 ingress controller 進入入口。
:::info
Tip： 使用 load balancer 或 ingress controller (例如 nginx) 來控制 NeuVector console 的存取。
:::
:::info
Tip：SSL 連線可以在入口 ingress controller 終止，並使用 HTTP 連線到 manager。在 Manager deployment 的 YAML 檔中使用環境變數關閉到 manager 的 SSL
:::
</div>
### Q&A
* Q：Manager container 可以在叢集外執行嗎？
A：可以，但這並不常見。Manager 需要將 controller 的 REST API 暴露在叢集之外。
* Q：NeuVector Manager 服務可以使用 Istio 等 service mesh 類型的 ingress controller 嗎？
A：不支援。請使用其他 Kubernetes ingress 方法。
* Q：Manager 可以管理多個叢集嗎？
A：可以，這需要部署 Multi-cluster federation (多叢集聯邦)的 controllers。可能還需要單獨的授權。
* Q：自簽證書可以更換嗎？
A：可以。
## Policy Modes – Discover, Monitor, Protect
<div class="indent-title-1">
每個 Group 的 policy 模式會決定 NeuVector 在偵測到 processes、網路連線和檔案活動時會做什麼。一般而言，「Discover」模式應該用於測試和暫存環境，以建立保護應用程式 workloads 的白名單規則。Monitor 或 Protect 模式應在生產環境中使用，以回應 Security Events (安全事件)。也可在測試/暫存環境中使用「Monitor」或「Protect」模式，觀察 NeuVector 在生產環境中的預期 run-time 行為。
:::info
Tip： 在「Discover」模式下部署 workloads 後，執行測試 script 或流量，以運用 Container 中的所有功能（網路連線、process、檔案）。當幾天未建立新規則時，請將群組切換至 Monitor 模式，並觀察至少一週。尋找 Notification -> Security Events，看看合法活動是否被警告。加入適當的網路或程序規則，將合法活動列入白名單。如果需要 Protect (封鎖) 模式，請將群組切換至 Protect 模式，並在接下來幾天特別注意任何被封鎖的活動。
:::
:::info
Tip：預設會啟用 Container 中的程序和檔案保護的 Zero-drift 模式。這對於允許有限 functions/processes 的強化 Container 非常有用。
:::
</div>
### Q&A
* Q：在轉移至「Monitor」或「Protect」模式之前，我應該讓群組處於「Discover」模式多久？
A：在執行所有應用程式測試，並確定 NeuVector 已學會所有網路連線和程序之後，最快也要幾個小時。也可能需要數天或一週的時間。舉例來說，有些開放原始碼工具會定期與外部連線以檢查更新，而您可能看不到這些連線。您應該決定是否允許這些外部連線，如果允許，就為它們加入白名單規則。好的做法是將規則匯出為 CRD yaml 檔案，並與應用程式開發人員一起檢閱，以確認預期的行為。
## Backups and Persistent Data
<div class="indent-title-1">
NeuVector 的設定以及任何狀態資料 (連線、通知等) 都會在可用的 controllers 之間同步。但是，如果所有 controllers 都領便當，設定和狀態資料就會遺失。若要讓 NeuVector 在領便當後自動復原叢集的組態，請啟用 persistent volume。當 controllers 啟動時，它們會從 persistent volume 中提取最新備份的設定資訊。
:::info
Tip： 建立 RWX persistent volume 來自動備份 NeuVector 設定，並在任何 NeuVector、主機作業系統或 orchestrator 更新（重新開機）之前，定期透過 Web Console 或 REST API 進行手動匯出備份。某些公共雲端儲存系統不支援 RWX，因此可能需要部署 NFS 等獨立儲存設備。
:::
</div>
### Q&A
* Q：匯出的備份檔案可以匯入不同的群集進行設定嗎？
A：不建議這樣做，因為名稱、namespace、IP 位址、system container 或其他組態設定的變更，可能在目標群集中無法運作。請使用 Helm、configMaps 和 CRD 來自動設定叢集。
## Integration Into CI/CD Pipeline
<div class="indent-title-1">
安全應該儘可能整合並自動化到 CI/CD pipeline 中。漏洞與合規性管理將在下一節說明。整合可使用 NeuVector 的 plug-ins (外掛程式)與支援介面，或使用 REST API 自訂。 Admission control 是 Pipeline 與生產環境之間的重要橋樑，建議啟用。
:::info
Tip：在 Policy -> Admission Control 中啟用並測試 admission controller。然後建立一些簡單的規則來阻止未經授權的部署。即使尚未設定 registry scan，根據 registry 的名稱、namespace 或其他一般條件的規則，也可針對 Container image 的部署提供保障。
:::
</div>
## Enterprise Integration: Alerts, Notifications, SIEM/SYSLOG, Webhooks
<div class="indent-title-1">
NeuVector 在「Notifications」功能表中顯示 alerts，並透過 SYSLOG、webhooks 或 Prometheus exporter 匯出事件。事件也可以使用 REST API 匯出。NeuVector 會顯示每種事件類型 (security events、risk reports 及一般事件) 的最新事件。不過，這些資料僅限於每種類型最近的 4K 事件。預期事件將透過 SYSLOG 或其他方式匯出，以進行永久儲存、alerting 及進階處理。
:::info
Tip：使用 webhooks 將特殊事件通知直接傳送至 webhook endpoint (例如 Slack) 或叢集內的自訂 webhook receptor container，以便進行額外處理。
:::
:::info
Tip: 提示： 若要與 alerting/paging 系統、case management (案件管理)系統或 SIEM 自訂整合，請使用 REST API、webhooks 或其組合。
:::
</div>
## Policy Migration – Staging to Production
<div class="indent-title-1">
一旦應用程式經過測試，且 NeuVector 的執行時 security rules 經過驗證，就應該將規則複製到生產環境中。
:::info
Tip：使用 NeuVector CRD 將 security rules 從暫存環境匯出、檢閱、登入及遷移到生產環境。
:::
:::info
Tip：在生產環境中，在「Settings」->「Configuration」中將「New Services Mode」設定為「Monitor」或「Protect」，以防止任何未知服務啟動而不產生警示。在部署任何新的 workloads 之前，請確保透過 CRD、REST API 或主控台部署白名單規則 (程序、網路、檔案)，以便 workloads 可以在受保護狀態下不中斷地開始執行。
:::
</div>
### Q&A
* Q：在轉移到生產環境之前，我們應該在暫存環境中運行多久？
A：確保您的暫存環境擁有與生產環境相同的 node、orchestrator、system containers 及其他重要資產。也應該測試預期在生產中的 Initial application workloads，但預期新的和更新的應用程式會持續發生。對於初始部署，這通常需要在暫存環境中進行幾週的測試，而對於新增或更新的 application workloads，則需要幾天到幾週的時間。
* Q：我們應該在生產中以「Monitor」或「Protect」模式執行嗎？
A：一開始，我們建議您在生產中以 Monitor 模式執行所有群組數天或數週，直到您對通知中偵測到的任何安全事件感到滿意為止。然後，您可以切換到 Protect 模式，只針對希望 NeuVector 阻擋網路、程序和檔案違規的群組。這可以根據具有出口連線的群組、關鍵資料庫，或是您 100% 確信所有預期行為都已列入白名單的 workloads 來決定。
* Q：我可以使用「Settings」->「Configuration」中的 export/import 設定檔案來進行遷移嗎？
答：不建議這樣做，因為名稱、namespace、IP 位址、system containers 或其他設定可能有變，無法在目標叢集中運作。使用 CRD 來進行遷移，方法是匯出群組規則，並在 yamls 中編輯這些規則，以反映生產環境中的任何變更，然後再進行部署。ConfigMaps 可用於在暫存環境和生產環境中一致配置其他設定。
<div class="indent-title-1">
> References
>* Using CRD: https://open-docs.neuvector.com/policy/usingcrd
</div>
## Vulnerability and Compliance Management
<div class="indent-title-1">
每家公司都會有不同的流程和標準來管理 Vulnerability (漏洞)和 Compliance (合規性) 測試。NeuVector 可彈性適應您的流程。
弱點與法規遵循管理的主要最佳實務包括：
* 要求開發人員在有修復方法時修復關鍵弱點，並盡可能在建立階段就停止或警示。
* 如果在 registry 中的現有 (已核准) Container images 或生產環境的 Container 中發現新的弱點，通知開發人員或適當的團隊。
* 提供寬限期，讓開發人員修復關鍵弱點，但確保運作中的 workloads 受到 NeuVector 白名單規則與「virtual patching」的保護。請參閱以下有關 virtual patching 的 Q&A 與參考連結， virtual patching 可保護執行漏洞的容器。
* 允許開發人員與 devops 團隊申請政策的例外情況，並能夠忽略某些漏洞掃描警示 (根據 CVE 編號)。
:::info
Tip：利用欄位「已修復」、「發佈日期」和自訂「Author/developer」 的 metadata，自動執行政策，要求開發者修復已發佈超過 7 天 (寬限期) 的弱點 (已修復)。
:::
</div>
### Q&A
* Q：為什麼 NeuVector 的掃描報告與我使用的其他 scanner 不同？
A：每家掃描廠商都維護自己的 CVE 資料庫，以及對 CVE 來源的詮釋，例如嚴重性/關鍵性等級。
* Q：NeuVector 是否可以在 Container images 推送到 registry 時立即進行掃描？
A：有些 registry (例如 Openshift) 支援 imagestreams，可讓 NeuVector 在 Container images 推送時自動掃描。對於其他 registry，則可設定定期掃描，每隔幾分鐘或幾小時掃描一次新 Container images。對於真正的按需掃描，可使用 REST API 在特定 Container images 推送至 registry 後觸發掃描。
* Q：什麼是 Virtual Patching (虛擬修補)？
A：NeuVector 所使用的這個詞彙，是指在生產環境中運行的 Container，如果存在 critical 的漏洞，NeuVector 在 Monitor 或 Protect 模式下運行時，會對其進行「virtually patched (虛擬修補)」，因為任何利用漏洞的嘗試都會立即被偵測到並封鎖，因為它會創建未經授權的 process、網路連線或檔案存取。
## Compliance Management
<div class="indent-title-1">
NeuVector 的 Compliance (合規性)檢查包括 CIS benchmarks (docker、kubernetes、openshift 等) 以及自訂合規性檢查 (在 Container 或主機上執行的 script)。這些都可以針對 PCI、GDPR 等各種產業標準進行 tag 與報告。
</div>
### Q&A
* Q：我可以自訂合規性報告嗎？
A：可以，透過標記適當的合規檢查，可以建立 PCI、GDPR 及其他的標準報告。每項報告都可以自訂，以包含或排除某些檢查。
## Improving the Security Risk Score in the Dashboard
<div class="indent-title-1">
Dashboard 提供整體安全風險評分，該評分根據 Container 的 Policy 模式、ingress/egress 連線、vulnerabilities (弱點)、privileged/root Container 和 admission
control。使用分數旁邊的精靈工具來逐步改善您的分數。
:::info
Tip：通常不可能將風險分數降至零，因為任何執行中的 Container、Kubernetes system container 或 egress 連線都代表風險。任何在「良好」範圍（小於 20）內的分數都被認為是可以接受的。
:::
</div>
## Network Rules – Ingress, Egress, Segmentation
<div class="indent-title-1">
網路 Segmentation (分割)、檢查和保護是 run-time 最重要的安全防護措施。應仔細檢閱和調整網路規則，以達到所需的行為（允許、警示、封鎖）。NeuVector 在「發現」模式下學習到的網路規則，在某些情況下會變得支離破碎，例如 :
* 連線來源或目的地總是在變，因為使用的是隨機連接埠，例如透過 load balancer 或 ingress 連接
* 部屬同一應用程式的 Pod 或同一應用程式的新版本在命名慣例中有版本號或隨機字串，導致 NeuVector 認為這是一個新應用程式，並為其建立新規則。
:::info
Tip： 透過在 Policy -> Network Rules 中篩選應用程式，檢視並編輯影響每個應用程式的網路規則。如果您注意到許多規則重複出現，且出發地或目的地的 IP 位址、連接埠或節點不斷變更，請考慮如何根據通訊協定、標籤或其他條件 (有或沒有通配符) 建立更高層級的網路規則，以整合這些規則。
:::
Egress 的連接可能是高風險的來源，因此應加以評估，並在可能的情況下，聲明只允許存取特定目的地。
:::info
Tip： 為需要存取叢及外部的 workloads 建立自訂出口規則。使用 `address=<destination>` 建立目標 (目的地) 自訂群組，並建立相對應的網路規則，允許從 Pod 群組存取到目標群組，可能的話使用應用程式通訊協定 (例如 MySQL、redis、mongodb、SSL 等)。
:::
在部署過程中套用的 Pod 標籤也可以用來強制執行規則。舉例來說，`scope=cde`、`scope=non_cde`、`external_access=allowed` 都是標籤的範例，這些標籤可以套用到 Pod，並在 NeuVector 中為這些 Pod 建立規則。可以建立符合標籤的自訂群組，並將規則套用至該群組。
</div>
</div>
### Q&A
* Q：網路規則可以訂製嗎？
A：可以，自訂和學習的網路規則可以透過 console 或 REST API 排序。聯邦規則和 CRD 建立的規則無法編輯，且總是先進行評估（即優先於其他規則）。
* Q：建立自訂群組時，可以使用通配符嗎？
Q：可以，通配符通常支援在條件中使用，例如 `address=*.google.com`。如果需要更靈活的匹配，也可以使用 regex 表達式，用 `~` 符號表示，例如 `label~my.label*-xyz`。
* Q：我可以將自訂群組的 `policymode` 變更為 Monitor 或 Protect 嗎？
A：目前自訂群組的政策模式是無法設定的，因為所引用的底層 Pod 可能處於不同的模式 (Discover、Monitor、Protect)。
* Q：DLP 網路 payload 檢查 regex 引擎可否用於其他政策？
A：可以，它可以用於 secrets 檢查、檢查 HTTP 標頭或路徑，或其他用途。
* Q：某些群組可以設定為 block，而其他群組只設定為警示嗎？
A：可以，NeuVector 中每個已學習的「Group」都可以有不同的模式：「Discover」、「Monitor」或「Protect」。
* Q：是否可以將「Group」設定為封鎖外部 egress 連線，但只在叢集或 namespace 中的其他 pod 違規時發出警示？
A：目前不可以。群組對於所有流量只能使用一種模式。我們正考慮在未來的版本中使用更細緻的政策。
## Automation – REST API
<div class="indent-title-1">
使用 REST API 可直接在 Controller 上執行任何動作，而無需透過 Web console。Manager container 使用 REST API 存取 Controller。REST API 的預設連接埠為 `10443`，可從叢集內部存取。若要從群集外部對 Controller 進行呼叫，請在外部將 REST API expose 為服務。
:::info
Tip：在 script 中使用 REST API 來自動執行 Policy 備份、根據可疑活動的封包擷取、觸發 Container images 掃描、讀取掃描結果等工作。
:::
</div>
### Q&A
* Q： authentication (驗證) 和 authorization (授權) 如何執行？
A：api token 請求需要使用者帳號和密碼進行驗證。使用者的角色決定該使用者可透過 api 進行哪些動作。
* Q：token 可使用多久？
A：token 的持續時間與使用者個人資料中設定的使用者逾時時間相同。例如，如果超時設定為 10 分鐘 (600 秒)，只要在 10 分鐘內使用，token 就會有效。10 分鐘未使用後，它就會過期。
## Automation – Security Policy, CRD
<div class="indent-title-1">
NeuVector Custom Resource Definition (CRD) 提供了一個強大的機制，可在 NeuVector 中宣告並自動化 security rules (安全規則)。它可讓安全、開發與開發人員協同討論與檢視允許的應用程式行為。
:::info
Tip：使用 NeuVector 來學習應用程式在 staging/test 中的行為，然後將規則匯出為 CRD，以便與開發人員和 devops 團隊一起檢閱與核准。然後檢查 CRD，像管理其他「code (程式碼)」一樣管理安全政策。
:::
CRD 用來「宣告」一組 Groups、rules 和 NeuVector objects 的 policy 模式。一旦宣告後，就只能套用更新的 CRD 來編輯。
:::info
Tip：使用 CRD 設定不與特定應用程式行為掛鉤的「global」安全規則，例如在「所有 Container」上防止 SSH 或 SCP (Container 是 NeuVector 中的保留群組名稱，可用於此)。或是允許外部 api 存取特定標籤的 Pod。
:::
</div>
### Q&A
* Q：如何匯出應用程式的 CRD？
A：移至 Groups，選擇要匯出的 Group，然後按一下匯出 Group Policy。選取 Groups 的所有 rules，以及相關 Groups (即在 network rules [網路規則] 中定義為選取群組的來源或目的地的群組) 將會匯出。
* Q：在 CRD 中應用之前，我可以變更自訂群組的「policy mode」嗎？
A：目前，自訂 Group 的 policy mode 必須為 `null`，因為所引用的底層 Pod 可能處於不同的模式 (Discover、Monitor、Protect)。
## Reviewing Notifications and Reducing False Positives
<div class="indent-title-1">
在 NeuVector 部署的最初幾天或幾週內，應檢查事件以確定它們是否為誤報。有幾種方法可以減少誤報：
1. 檢視「Notifications」中的事件，如果適用，選擇「Review Rule」按鈕，立即新增違規事件的白名單規則。
2. 檢閱事件通知後，在適當的政策功能表中手動建立白名單規則 - admission control、process (Group 下)、network rules 等。
3. 建立 Response rule，以「抑制通知」這些類型的事件。
:::info
Tip： 盡可能建立白名單規則，以允許被報告為違反的行為。若要暫時壓制通知，請使用 Response rule，此規則稍後可輕鬆停用或移除。
:::
</div>
## Updating – NeuVector, Nodes, Host OS, Orchestrator Platforms
<div class="indent-title-1">
NeuVector 支援對 critical containers 進行滾動式的更新，但對於環境的任何更新，都應該特別小心。controllers 之間會維持一個狀態，如果所有 controllers 同時不可用，這個狀態就會消失。因此，在升級 hosts/nodes (重新開機) 或 orchestrator (例如 Kubernetes) 時，請特別小心，即使已啟用節點 draining process。
:::info
Tip： 對於主機作業系統或如 Kubernetes 等 orchestrator 平台的更新，需要重新啟動節點或排出 Pod 時，請確保至少有一個 NeuVector Controller 一直處於活動狀態。當重新啟動有 Controller 的節點時，請觀察新 Controller，以確保它至少有 60 秒（幾分鐘更好）處於 available (可用) 的狀態，以確保它有時間與領導 Controller 同步狀態，然後再重新啟動下一個有 Controller 的節點。
:::
:::info
Tip： 在更新 NeuVector、其運行的主機或 orchestrator 之前，請務必手動備份整個設定檔。您可以在 `Settings` -> `Configuration` -> `Export All` 中匯出備份。
:::
</div>
## Appendix - Pre-Deployment Checklist
1. 收集所需的資訊
* [ ] NeuVector 版本和 K8s 版本。
* [ ] 拉取 NeuVector Container image 的 Dockerhub ID。
* [ ] 目標節點的 CPU/記憶體 設定文件。
* [ ] 正在使用的 Container run-time。
* [ ] manager 使用 Ingress 的方法對外。
* [ ] SYSLOG servers、LDAP/AD、SSO/SAML servers 的整合資訊。
2. 檢閱 [NeuVector 官方文件](https://open-docs.neuvector.com/)
* [ ] 特別是第 1 節 [Deployment Preparation](https://open-docs.neuvector.com/basics/installation/native)
* [ ] 第 2 節 [Deploying](https://open-docs.neuvector.com/deploying/production)。每個協調平台也在本節有特定的部署說明。
3. 準備目標環境
* [ ] 如果不是從 NeuVector docker hub registry 動態拉取，請預先拉取 images。
* [ ] 建立 RWX 儲存空間（如果使用持久化儲存空間來備份設定） ‧
4. 確保網路連通性
* [ ] 測試從 Cluster 到 Registry 或 docker hub 拉取映像的能力。
* [ ] 啟用並測試從集群內部存取 Registry 以進行 Registry 掃描（如適用）。
* [ ] 透過 load balancer、route、IP/port（預設埠 8443），存取集群中的 manager service 的控制台。
* [ ] 檢查網路或本機防火牆（如 firewalld）是否阻擋 NeuVector 所需連接埠的存取。
* [ ] 啟用 SYSLOG（預設埠514）和 webhook 通知所需的 outbound connections。
5. 建立部署流程與範本
* [ ] 決定部署方法： `Helm`、`kubectl/yaml` 檔案、`Operator`...
* [ ] 檢閱範例 yaml 檔案和 值 與設定選項
* [ ] Kubernetes - https://open-docs.neuvector.com/deploying/kubernetes
* [ ] 從 Rancher Manager 部署 - https://opendocs.neuvector.com/deploying/rancher
* [ ] Openshift - https://open-docs.neuvector.com/deploying/openshift
* [ ] 在 Helm 中編輯 yamls 或部署值（如適用）：
* [ ] Manager 存取方式 - LoadBalancer、ingress、NodePort...
* [ ] 啟用/停用多叢集 master 和 remote services
* [ ] Container Images 名稱、版本標籤或 NeuVector images 的路徑
* [ ] 若為 containerd 或 CRI-O 則為 Container run-time
* [ ] 控制 NeuVector Pod 部署位置的 Taints/tolerations 或節點標籤。
## Ref
- [NeuVector Onboarding and Best Practices Guide
](https://open-docs.neuvector.com/assets/files/NV_Onboarding_5.0-e780f27e1cde02dad5ebf3650377aff0.pdf)
Sign in with Wallet
Connect another wallet