列出階層中的所有專案和資料夾

Trusted Cloud by S3NS 中的資源會整理成階層，每個節點 (機構、資料夾、專案等) 都會參照其父項。您可以將該參照做為掃描作業的主要篩選條件，提高資源搜尋的一致性。

您可以透過自訂角色授予使用者權限。這些角色遵循最低權限原則，通常只提供執行特定工作所需的最低權限。

這項配置有助於隔離不同的使用者群組。例如：

大型公司，其中某些部門不應能檢查同儕的資源。
獲得特定專案的權限，但沒有其他資源的權限。

不過，由於權限受限，執行清單作業時，自訂角色可能會導致階層中的許多資源遭到省略。以獲派自訂角色的使用者身分執行搜尋時，可能難以判斷特定資源未顯示的原因。

為避免發生這種情況，本頁面將說明列出資源階層中所有由 Cloud Resource Manager API 管理資源的最佳做法。您可以根據這份指南設定自訂稽核檢查，或在 Cloud Resource Manager API 的基礎上建立自己的使用者體驗。

列出所有資源節點

掃描資源階層以列出所有資源時，您需要強烈一致的結果。如果掃描作業遺漏資源或提供過時結果，您可能難以判斷是否出錯。為確保您一律取得最準確完整的結果，請使用服務帳戶，並按照下列方式執行掃描：

在機構資源中，授予服務帳戶機構、資料夾和專案的 list 和 get 權限。
如果要列出專案和資料夾資源，請在篩選字串中指定父項資源。
針對要尋找的每種資源類型，以及任何中繼資源 (例如資料夾)，使用這個服務帳戶執行 projects.list() 方法。

列出所有資源節點的範例

下列虛擬程式碼示範如何列出機構中的每個資源節點：

organizations = organizations.search()
projects = emptyList()

parentsToList = queueOf(organizations)
while (parent = parentsToList.pop()) {
  // TODO: Iterate over paginated results as needed.
  // TODO: Handle PERMISSION_DENIED appropriately.
  projects.addAll(projects.list(parent.type, parent.id))
  parentsToList.addAll(folders.list(parent))
}

建構自訂使用者體驗時，您可能也想混用搜尋結果，並視需要載入父項資源 (同時也擷取 PERMISSION_DENIED 例外狀況)。

縮短 gcloud projects list 的延遲時間

如果gcloud projects list查詢失敗或耗時過長，可能是因為要傳回的專案數量過多。Trusted Cloud by S3NS 如要修正這個問題，請將 filter 和 page-size 標記套用至 gcloud projects list 指令。

如要進一步瞭解可新增至 gcloud projects list 指令的旗標，請參閱 gcloud projects list。

排除 Apps Script 專案範例

查詢失敗或延遲最常見的原因，是機構內有大量 Apps Script 專案。下列指令說明如何從專案清單中排除 Apps Script 專案，並限制每頁傳回的資源數量。

gcloud projects list --filter="NOT parent.id: 'APPS_SCRIPT_FOLDER_ID' "--page-size='30'

取得 Apps Script 資料夾 ID

如要找出 Apps Script 資料夾 ID，請按照下列步驟操作。

在控制台的工具列中，按一下「搜尋資源、文件、產品和其他項目」，然後輸入 apps-script。 Trusted Cloud

前往 Trusted Cloud 控制台
在「資源」下方，選取「apps-script」資料夾。
在「資料夾 ID」下方，複製資料夾 ID。

搜尋資源

如果掃描的目的是搜尋一段時間前建立的資源，您可以執行最終一致性掃描，這類掃描比強一致性掃描更快。請注意，這種搜尋方法可能會從搜尋結果中省略部分資源，尤其是最近變更的資源。如要搜尋資源，請按照下列步驟操作：

使用具備您要搜尋資源 get 權限的服務帳戶。
使用這個服務帳戶執行 projects.search() 方法。

疑難排解遭省略的資源

如果您要開發掃描工具，建議使用機構層級授予的 list 和 get 權限。這樣可避免使用者只有部分權限而導致問題，因為這樣會造成部分資源從清單中省略。

如果您要設計自訂使用者體驗來檢查使用者權限，則沒有簡單的解決方案。如果使用者沒有機構層級的權限，就必須擁有每個資源的特定權限，才能看到資源。如果使用者在階層中的某個資源缺少權限，部分資源可能不會顯示。

如果使用者擁有特定資源的 list 權限，但沒有 get 權限，該資源就不會顯示在Trusted Cloud 控制台中。不過，如果使用 API 或 Google Cloud CLI 搜尋時指定了資源的父項，系統仍會傳回該資源。嘗試掃描資源階層時， Trusted Cloud 控制台和其他方法之間的差異，是常見的混淆來源。

下圖顯示一些常見的權限設定，以及這些設定如何影響使用者在搜尋時可看到的資源。

列出所有資源

在本範例中，所有必要權限都會在機構資源中授予。因此，執行清單或搜尋時，整個階層都會顯示。

缺少機構權限

在這個範例中，使用者擁有所有必要權限，但沒有 resourcemanager.organizations.get 權限，不過系統已在資料夾層級授予這些權限。這項權限缺口可讓他們完整查看該部分階層的清單或搜尋結果，但無法查看另一半。

僅限專案取得權限

這個範例顯示使用者體驗，使用者僅在資料夾資源層級獲得 resourcemanager.projects.get 權限。他們可以透過搜尋查看該資料夾階層中的專案，使用清單功能不會傳回任何結果。

僅限取得資料夾的權限

這個範例顯示的問題與上述相同，即授予的權限只允許使用者透過搜尋尋找資料夾資源。使用清單功能不會傳回任何結果。

混合權限

在這個範例中，使用者在整個機構中擁有各種權限。他們可以列出機構層級的資料夾，並透過在整個階層中指定上層資源的搜尋方式找到這些資料夾。他們可以列出一個資料夾的專案資源，但無法列出另一個資料夾的專案資源，而且他們在階層底部的某個專案上擁有 resourcemanager.projects.get 權限。

因此無法傳回這個資源階層左側的專案。他們只能使用指定父項資源的搜尋條件，在右側列出專案，且在 Trusted Cloud 控制台中查看時，只會顯示一個專案。

無法探索的資源

在這個範例中，使用者可以指定整個階層中的父項，藉此取得機構資源並列出專案資源。不過，他們無權列出或搜尋任何中繼資料夾。如果使用者知道父項資料夾的 ID，就能搜尋專案。使用者完全看不到資料夾，因此如果沒有 ID，就無法找到。 Trusted Cloud 控制台只會顯示機構資源。

設計自訂使用者體驗時，請務必留意上述類似情況。您可以結合列出和搜尋作業，來算繪資源階層。此外，您也應考慮如何向使用者說明他們缺少權限，因此無法查看完整的資源階層。