屬性上下文 (proto)

service.auth.v3.AttributeContext

[service.auth.v3.AttributeContext proto]

屬性是描述網路活動的中繼資料片段。例如，HTTP 請求的大小或 HTTP 回應的狀態碼。

每個屬性都有一個類型和名稱，邏輯上定義為 AttributeContext 的 proto 訊息欄位。AttributeContext 是 Envoy 授權系統支援的個別屬性的集合。

{
  "source": {...},
  "destination": {...},
  "request": {...},
  "context_extensions": {...},
  "metadata_context": {...},
  "route_metadata_context": {...},
  "tls_session": {...}
}

source: (service.auth.v3.AttributeContext.Peer) 網路活動的來源，例如啟動 TCP 連線。在多跳網路活動中，來源表示最後一跳的傳送者。

destination: (service.auth.v3.AttributeContext.Peer) 網路活動的目的地，例如接受 TCP 連線。在多跳網路活動中，目的地表示最後一跳的接收者。

request: (service.auth.v3.AttributeContext.Request) 表示網路請求，例如 HTTP 請求。

context_extensions: (repeated map<string, string>) 這與 http_request.headers 類似，但這些內容不會傳送到上游伺服器。Context_extensions 提供一個擴展機制，用於將額外資訊傳送到授權伺服器，而無需修改 proto 定義。它對應於篩選器鏈中的內部不透明上下文。

metadata_context: (config.core.v3.Metadata) 與請求關聯的動態中繼資料。

route_metadata_context: (config.core.v3.Metadata) 與選定路由關聯的中繼資料。

tls_session: (service.auth.v3.AttributeContext.TLSSession) 底層連線的 TLS 會話詳細資訊。預設情況下不會填入此資訊，只有在已明確設定 ext_authz 篩選器以包含此資訊時才會填入。對於 HTTP ext_authz，這需要將 include_tls_session 設定為 true。對於網路 ext_authz，這需要將 include_tls_session 設定為 true。

service.auth.v3.AttributeContext.Peer

[service.auth.v3.AttributeContext.Peer proto]

此訊息定義處理網路請求的節點的屬性。節點可以是傳送、轉發或接收請求的服務或應用程式。服務對等點應適當填入 service、principal 和 labels。

{
  "address": {...},
  "service": ...,
  "labels": {...},
  "principal": ...,
  "certificate": ...
}

address: (config.core.v3.Address) 對等點的位址，這通常是 IP 位址。它也可以是 UDS 路徑或其他。

service: (string) 對等點的正規服務名稱。它應設定為 HTTP x-envoy-downstream-service-cluster。如果可以透過 mTLS/安全命名取得更可靠的服務名稱來源，則應使用它。

labels: (repeated map<string, string>) 與對等點關聯的標籤。這些可以是 Kubernetes 的 pod 標籤或 VM 的標籤。標籤的來源可以是 X.509 憑證或其他設定。

principal

(string) 此對等點的已驗證身分。例如，與工作負載 (例如服務帳戶) 關聯的身分。如果使用 X.509 憑證來斷言身分，則此欄位應依序從 URI 主體替代名稱、DNS 主體替代名稱 或 主體 中取得。主要身分應為主體。主體格式是發行者特定的。

範例

SPIFFE 格式為 spiffe://信任網域/路徑。
Google 帳戶格式為 https://127.0.0.1/{userid}。

certificate: (string) 用於驗證此對等點身分的 X.509 憑證。如果存在，憑證內容會以 URL 和 PEM 格式編碼。

service.auth.v3.AttributeContext.Request

[service.auth.v3.AttributeContext.Request proto]

表示網路請求，例如 HTTP 請求。

{
  "time": {...},
  "http": {...}
}

time: (Timestamp) Proxy 接收請求的第一個位元組時的時間戳記。

http: (service.auth.v3.AttributeContext.HttpRequest) 表示 HTTP 請求或類似 HTTP 的請求。

service.auth.v3.AttributeContext.HttpRequest

[service.auth.v3.AttributeContext.HttpRequest proto]

此訊息定義 HTTP 請求的屬性。HTTP/1.x、HTTP/2、gRPC 都被視為 HTTP 請求。

{
  "id": ...,
  "method": ...,
  "headers": {...},
  "header_map": {...},
  "path": ...,
  "host": ...,
  "scheme": ...,
  "query": ...,
  "fragment": ...,
  "size": ...,
  "protocol": ...,
  "body": ...,
  "raw_body": ...
}

id: (string) 請求的唯一 ID，可以傳播到下游系統。對於特定服務，ID 在一天內發生衝突的可能性應該很低。對於 HTTP 請求，它應該是 X-Request-ID 或等效項目。

method: (string) HTTP 請求方法，例如 GET、POST。

headers: (repeated map<string, string>) HTTP 請求標頭。如果多個標頭共用相同的索引鍵，則必須根據 HTTP 規格合併它們。所有標頭索引鍵都必須小寫，因為 HTTP 標頭索引鍵不區分大小寫。標頭值以 UTF-8 字串編碼。非 UTF-8 字元將會被「!」取代。如果將 encode_raw_headers 設定為 true，則不會設定此欄位。

header_map

(config.core.v3.HeaderMap) 原始 HTTP 請求標頭的清單。當 encode_raw_headers 設定為 true 時，會使用此選項來取代 headers。

請注意，這實際上不是 map 類型。header_map 包含單個重複欄位 headers。

在此，只有 key 和 raw_value 欄位會針對每個 HeaderValue 填入，並且僅當將 encode_raw_headers 設定為 true 時才會如此。

此外，與 headers 欄位不同，具有相同索引鍵的標頭不會合併成單個以逗號分隔的標頭。

path: (string) 請求目標，如 HTTP 請求的第一行所示。這包括 URL 路徑和查詢字串。不會執行解碼。

host: (string) HTTP 請求 Host 或 :authority 標頭值。

scheme: (string) HTTP URL 協定，例如 http 和 https。

query: (string) 此欄位永遠空白，且存在的原因是為了相容性。path 欄位中包含 HTTP URL 查詢。

fragment: (字串) 此欄位永遠為空，存在僅為相容性考量。URL 片段不會作為 HTTP 請求的一部分提交；它是未知的。

大小: (int64) HTTP 請求的大小，以位元組為單位。如果未知，則必須為 -1。

協定

(字串) 與請求一起使用的網路協定，例如 “HTTP/1.0”、“HTTP/1.1” 或 “HTTP/2”。

請參閱 headers.h:ProtocolStrings 以取得所有可能值的列表。

主體: (字串) HTTP 請求主體。

原始主體: (位元組) 以位元組表示的 HTTP 請求主體。當 pack_as_bytes 設定為 true 時，會使用此欄位，而不是 body。

service.auth.v3.AttributeContext.TLSSession

[service.auth.v3.AttributeContext.TLSSession proto]

此訊息定義了底層 TLS 會話的屬性。

{
  "sni": ...
}

sni: (字串) 用於 TLS 會話的 SNI。