部署內容包分析

部署前應該拿到「安裝包」和配套的「授權配置」，授權配置中包含授權包的授權碼，完整性校驗碼等內容。

安裝包

安裝包是一個壓縮文件，里面包含了一個安裝工具和一個加密壓縮之后的部署包。安裝工具利用授權碼對部署包進行處理，并按授權碼攜帶的信息進行部署。

完整性校驗碼

完整性校驗碼用于校驗安裝包的完整性。

授權碼的結構

部署授權碼用于協調部署安裝過程。

授權碼考慮使用具備授權信息的json文本，利用非對稱加密的方法，加密出來的字符串作為授權碼，授權碼的結構包括但不限于 授權的模塊，部署包的解壓密碼等；

受商業模式的影響，還可以增加其他的授權內容用于做到不同程度的限制，如下：

1、授權碼可能會被多次使用，特別是在內網的情況下，無法限制其部署的次數，可以考慮增加「授權碼的過期時間或授權碼生效的MAC地址」參數來限制授權碼的反復使用。

2、如果授權碼被濫用，為了便于后續查看是哪家泄漏的授權碼，可以在授權碼的原始json中增加「授權對象名稱」字段。

3、平臺如果是按年收費等，可以增加 「平臺的授權時間范圍」 字段，用來限制平臺的使用時間。

4、平臺如果考慮按用戶數量等收費，也可以增加 「授權的用戶數」 字段，用來限制平臺創建用戶的數量限制等。

下面是一套授權碼的 JSON 結構示例，涵蓋了授權信息，如授權模塊、部署包解壓密碼、授權對象、MAC 地址綁定、授權時間范圍等。

ounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(line
{
  "license_id": "123e4567-e89b-12d3-a456-426614174000",
  "issued_at": "2024-10-22T12:00:00Z",
  "expires_at": "2025-10-22T12:00:00Z",
  "licensee": {
    "company": "某某科技有限公司",
    "contact": "admin@example.com"
  },
  "authorized_modules": [
    "asset",
    "vulnernable",
    "notice"
  ],
  "deployment": {
    "unpack_password": "s3cr3tP@ssw0rd",
    "allowed_macs": [
      "00:1A:2B:3C:4D:5E",
      "00:1A:2B:3C:4D:5F"
    ],
    "instance_type": 0
  },
  "usage_restrictions": {
    "valid_from": "2024-11-01T00:00:00Z",
    "valid_to": "2025-11-01T00:00:00Z",
    "max_users": 100
  },
  "security": {
    "signature": "base64-encoded-signature"
  }
}

說明

1. 「license_id」：唯一的授權碼 ID，可用于追蹤授權。
2. 「issued_at / expires_at」：授權碼的簽發時間和到期時間。
3. 「licensee」：授權對象（企業或個人）。
4. 「authorized_modules」：被授權的功能模塊列表。
5. 「deployment」：

• unpack_password：部署包的解壓密碼。
• allowed_macs：受限的 MAC 地址列表，可用于防止無限制使用授權碼。
• nstance_type：授權部署實例的類型（0表示單節點授權部署，1表示三節點授權部署）

6. 「usage_restrictions」：

• valid_from / valid_to：平臺的授權有效期。

• max_users：授權的最大用戶數。

7. 「security」：

• signature：授權碼的數字簽名（使用私鑰對整個 JSON 加密的哈希值，驗證時使用公鑰校驗）。

使用非對稱加密（如 RSA、ECC）對 JSON 進行加密，并將其轉換為 Base64 字符串，作為最終的授權碼。

缺陷問題

為了得到足夠的授權信息，授權碼會比較長：“我們的客戶場景基本為內網部署，無法通過給簡單授權碼然后請求遠程授權信息的方式來代替”。

虛擬化或云環境下，MAC 地址可能頻繁變動，影響授權驗證：“在這種情況下，可以修改變化的MAC地址為其他不變的參數”。

用戶可能會修改系統時間，繞過授權時間限制

在內網部署的情況下，授權碼盜用和濫用的方法比較多，我們現目前沒有很好的方案從技術上完全限制。

部署流程設計

校驗和配置

完整性校驗

用戶拿到 「安裝包、校驗碼、授權碼」 后，需使用完整性校驗工具對 「安裝包」 進行完整性校驗，確保安裝包未被篡改。「示例命令（SHA256 校驗）：」

ounter(line
sha256sum -c install_package.sha256

「若校驗失敗，則終止安裝并提示用戶重新獲取安裝包。」

解壓安裝包

校驗通過后，用戶手動解壓安裝包，得到以下內容：

• 「加密部署包（encrypted_package.tar.gz）」
• 「部署工具（deploy_tool，可執行二進制）」
• 「部署配置文件（deploy_config.yaml）」

「示例解壓命令：」

ounter(line
tar -xzf install_package.tar.gz

deploy_config.yaml 包含：

• 「版本信息」（當前包版本號）
• 「依賴信息」（是否依賴其他組件）
• 「可選配置參數」（如端口、數據庫連接等）

配置參數

用戶可根據需求修改 deploy_config.yaml，未配置的參數采用默認值。

開始部署

啟動部署工具

用戶運行部署工具：

ounter(line
./deploy_tool

部署工具會要求用戶輸入 「授權碼」。

授權碼校驗

1. 「解密授權碼」

• 使用預設的 「私鑰」 解密授權碼，獲得授權信息。

2. 「校驗授權信息」

• 確認授權信息是否與本次部署的 「版本、環境」 匹配。

• 授權有效 → 繼續安裝

• 授權無效 → 終止安裝，提示用戶檢查授權

自動讀取當前環境信息

部署工具會自動檢測系統中是否已有相同組件：

• 若已有 「相同版本」，提供 「僅安裝」 或 「覆蓋安裝」 選項：

a.「僅安裝」：保留用戶數據，使用當前版本進行安裝

b.「覆蓋安裝」：不保留舊版本數據，重新安裝

• 若已有 「舊版本」，提供 「升級」 或 「覆蓋安裝」 選項：

• 「升級」：保留用戶數據，更新至新版本

• 「覆蓋安裝」：不保留舊版本數據，重新安裝

「示例命令（檢查已安裝版本）：」

ounter(line
./deploy_tool --check-version

執行安裝部署步驟

依賴檢查通過之后，利用授權碼解密得到的部署包密碼對部署包進行解密。

解密成功之后，進入安裝步驟，安裝工具會使用授權碼解密得到的安裝實例類型參數，如果參數值為0，表示該授權碼是單實例部署的授權；如果參數值為1，表示該授權碼是三節點實例部署的授權；

如果是單實例部署，會提示用戶輸入當前服務的外部IP地址和服務名（可選）；

如果是三實例部署，會提升用戶需要輸入master節點的IP地址和服務名（可選）；其他節點的IP地址和服務名（可選）。

用戶也可以在安裝前，將IP地址和服務名以配置的方式寫入到 deploy_config.yaml 中。

例如：

ounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(line
master:
  ip: "192.168.1.10"
  host_name: "master-10"
nodes:
  - ip: "192.168.1.11"
    host_name: "node-11"
  - ip: "192.168.1.12"
    host_name: "node-12"

如果是單實例部署中，IP地址用戶也可以缺省，按照工具默認使用127.0.0.1進行部署，host_name默認為master；

在三實例部署中，host_name可以缺省，系統會自動以 **master-主節點IP（三四位）**為主節點；「node-從節點IP（三四位）為各個從節點」。

在所有的部署情況中，IP地址（和主機名）是變化概率比較大的內容，所以這幾個參數還是會保留以交互式的方式讓用戶進行輸入。其他組件和應用的配置參數，則以缺省的方式進行配置（即默認值填充）。

安裝包的命名

「目標」：通過文件名即可識別 「包類型」、「版本」、「發布時間」 及 「其他關鍵信息」。

****「命名格式」

ounter(line
<產品名稱>-<包類型>-<客戶標識>-<發布版本>-<包類別>-<發布日期>.tar.gz

例如：

ounter(line
MyApp-Custom-ABCCorp-V2.3.1-Patch-202440.tar.gz

****「詳細字段說明」

****「命名示例」

****「額外可選字段」

如果需要進一步細化，可以增加：

• 「架構類型」（x86_64 / arm64）→ MyApp-General-V2.3.1-Full-202440-x86_64.tar.gz
• 「加密方式」（Enc 表示加密）→ MyApp-Custom-ABC-V2.3.1-Full-202440-Enc.tar.gz

「這樣一眼就能看出這個包的類型、客戶、版本和發布時間」

實現方案

部署場景的文件結構

• checksum.txt
• listence.txt
• MyApp-Custom-XYZCorp-V1.5.0-Full-202438-x86_64.tar.gz

a.部署工具，二進制

• 部署配置文件
• 加密的部署包
• MyApp-Custom-XYZCorp-V1.5.0-Full-202438-x86_64-Enc.tar.gz
• deploy_config.yaml
• deploy_tool

checksum.txt中存放MyApp-Custom-XYZCorp-V1.5.0-Full-202438-x86_64.tar.gz的完整性校驗碼。

listence.txt中存放授權碼，是加密并編碼之后的授權信息。

安裝工具對授權碼進行解密

當用戶手動解壓 MyApp-Custom-XYZCorp-V1.5.0-Full-202438-x86_64.tar.gz 之后，得到 deploy_tool 部署工具，該工具首先讀取并解密listence.txt，得到授權信息。

生成加密的授權碼

目標是：

1. 「確保授權碼只能被安裝工具解密」（即防止他人隨意解密）。
2. 「防止私鑰泄露，同時保持安全性」。

• 生成一對 「RSA 公私鑰」：

a.「公鑰（public_key.pem）」 用于加密 listence.txt，并內置在 部署包 內。

b.**私鑰（private_key.pem）**「僅存儲在部署工具（deploy_tool）內部」，用于解密授權碼。

• 這樣，**即使別人知道公鑰，他們也無法解密 ****listence.txt**。

「加密流程（生成授權碼）」

ounter(line
openssl rsautl -encrypt -pubin -inkey public_key.pem -in raw_license.txt -out listence.txt

「解密流程（在 deploy_tool 中）」

ounter(line
openssl rsautl -decrypt -inkey private_key.pem -in listence.txt -out license_decoded.txt

這樣，「只有」**deploy_tool**** 具備私鑰，才能解密授權碼**。

風險

把 「私鑰」 放到 deploy_tool 里面存在 「反編譯泄露風險」，如果攻擊者能夠獲取 deploy_tool 并反編譯，就有可能提取私鑰，從而解密 listence.txt。我們「可以考慮動態生成固定私鑰」的方法，通過「代碼中的特定計算規則」，在運行時生成私鑰，計算過程隱藏在復雜的數學運算、位運算、哈希計算等邏輯中。

授權信息的結構

在前面的章節中，提到過授權信息的結構。授權信息是一個json結構的內容，里面包含了所有用戶不能看或者不能篡改的內容。

用戶填寫好IP和主機名之后的執行邏輯

用戶可以手動在 deploy_config.yaml 中填寫好IP等必填參數信息，也可以通過腳本交互式填寫（如果deploy_config.yaml 沒有），格式為：

ounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(line
master:
  ip: "192.168.1.10"
  host_name: "master-10"
nodes:
  - ip: "192.168.1.11"
    host_name: "node-11"
  - ip: "192.168.1.12"
    host_name: "node-12"

在此之后，一鍵化腳本會調用現目前的交互式部署工具V1進行細化的部署工作，V1工具為下面每個組件定義了完整的部署邏輯：

biz base

datax

dinky

dolphinschedul

doris

flink

fluentd

grafana

jdk11

jdk17

jdk8

kafka

knowledge

log_audit

minio

mysql

nginx

nmap

pgsql

prometheus

redis

supervisord

zookeeper

配置前優化

同時V1工具也為每一個可變參數，sql都定義了執行流。

一鍵化部署工具V2會根據授權信息中的授權的大業務組件，「對需要的小組件進行安裝和校驗」，如果用戶在外部沒有為組件定義缺省參數，則各組件會依照原有自動化部署中的默認參數進行配置和部署。

缺省的參數清單

在上面的描述中，我們在 deploy_config.yaml 配置了部署的IP信息。在某些情況下，我們需要手動配置一些部署的參數，那么這個時候就需要用戶手動在deploy_config.yaml設置參數。

安裝進度展示

用戶可以看到安裝的進度、輸出的安裝正確日志或者錯誤日志和輸出最終訪問的方法等。

輔助文檔輸出

在上述一鍵化部署方案實施的前提下，在本方案交付時還應該提供出缺省的參數清單、可能出現的問題&解決清單、一鍵化部署用戶使用、授權碼申請模版等文檔。