紅帽推出Quay 3.11引入智慧授權、生命周期管理與AWS集成

世界領(lǐng)先的開(kāi)源解決方案供應商紅帽公司日前宣布紅帽Quay 3.11將于本月正式推出。該版本將更新權限管理和鏡像生命周期自動(dòng)化功能，以實(shí)現更高效的全面管理。

重要更新內容包括：

●   團隊與OIDC（OpenID Connect）小組的同步

●   在存儲庫級別修整策略

●   新的用戶(hù)界面提供更多Quay功能

●   通用AWS STS支持

●   Quay操作器增強

增強用戶(hù)組控制

借助Quay 3.11，用戶(hù)可以根據OIDC提供商服務(wù)（如Azure Active Directory Service）所定義的分組來(lái)管理權限。此更新使Quay 管理員和組織負責人可以更有效地定義訪(fǎng)問(wèn)級別：OIDC中的群組成員可以集中識別多個(gè)系統中的用戶(hù)及其角色，在Quay中，不論用戶(hù)組規模如何，都能輕松向用戶(hù)組添加或刪除權限。例如，名為“developer”的OIDC組可用于新工程師團隊授予使用CI/CD管道和向其Quay組織推送鏡像的權限，而不更改Quay中的組織設置。

在Quay組織中，團隊是一組用戶(hù)，他們可以根據自己的角色拉取、推送、更新鏡像或管理組織。OIDC組同步功能可將團隊定義與OIDC提供商中的組名進(jìn)行對比，以自動(dòng)識別團隊成員。

靈活實(shí)現自動(dòng)化鏡像生命周期管理

在上一版本的基礎上，Quay 3.11引入了存儲庫特定的規則，用于修整組織級策略之外的策略，或者取代組織級策略。這進(jìn)一步細化了鏡像生命周期的定義。例如，在一個(gè)組織內部，多個(gè)存儲庫托管應用堆棧的不同組件。修整策略可以在組織級別定義，以便在鏡像使用超過(guò)一年后自動(dòng)刪除。借助紅帽Quay 3.11，用戶(hù)現在可以為存放測試和暫存鏡像的存儲庫定義額外的策略，這些策略可能會(huì )規定在30日后刪除夜間構建的鏡像。這也將減少在過(guò)期鏡像中發(fā)現的漏洞，從而提高安全性。

在新用戶(hù)界面中探索更多功能

該版本還在新用戶(hù)界面中加入了更多Quay功能，以支持更多工作流?，F在，用戶(hù)可以管理自己的鏡像構建，也可以查看組織內的審核事件。

這一更新版本還引入了使用正則表達式對多個(gè)標簽、存儲庫和組織進(jìn)行高效搜索的功能。此外，用戶(hù)還可以在新的用戶(hù)界面中使用根據用戶(hù)的系統設置自動(dòng)啟用的夜間模式。

通過(guò)AWS服務(wù)增強安全性

現在，用戶(hù)可以通過(guò)AWS的安全令牌服務(wù) (Secure Token Service)更安全地將Quay與AWS S3連接。通過(guò)STS，用戶(hù)不再需要借助長(cháng)期以來(lái)一直使用的AWS訪(fǎng)問(wèn)密鑰和秘鑰才能讓Quay訪(fǎng)問(wèn)AWS服務(wù)，而是可以依靠紅帽Quay和AWS IAM系統之間的自動(dòng)令牌交換機制。這些令牌有時(shí)效性，并由Quay自動(dòng)刷新，因此，令牌泄露造成的影響有限。這是紅帽Quay團隊根據客戶(hù)反饋（要求在他們的環(huán)境中強制使用STS）而實(shí)現的。

操作增強

Quay操作器現在可用于在Kubernetes層面微調資源消耗請求和限制。Quay堆棧中的每個(gè)受管組件（包括Quay自身、Clair、二者的PostgreSQL實(shí)例、Redis和鏡像工作器）都可以配置單獨的資源請求和限制值：

spec:

components:

-   kind: clair

managed: true

overrides:

resources:

limits:

cpu: "5" #Limiting to 5 CPUs (vs. 4 default)

memory: "18Gi"  # Limiting to 18 Gibibytes of memory (vs. 16 Gi default)

requests:

cpu: "4" #Requesting 4 CPUs (vs. 2 default)

這有助于調整Quay組件運行所需向集群請求的最低資源，一般來(lái)說(shuō)，這對在更小、資源更緊張的集群上運行非常有用。限值也可以調整，這適用于極大規模的部署項目，如上例所示。

紅帽Quay 3.11版本還解決了操作器管理的Quay部署組件的自定義副本設置與Pod水平自動(dòng)擴縮器設置相沖突的問(wèn)題?，F在，這些設置都可以調整，而且HPA 也會(huì )相應地遵守這些設置。這樣，如果需要超出默認數量的Quay和Clair Pod實(shí)例，不再必須禁用自動(dòng)擴縮功能。。

其他增強

需要部署大型項目的客戶(hù)通常希望在PostgreSQL端使用Quay將連接匯集到一起。pgBouncer是廣受歡迎的PostgreSQL連接池之一，而且用戶(hù)也希望確認pgBounceer能夠與Quay一起使用。紅帽Quay 3.11支持使用pgBouncer，而且我們的QA團隊使用CrunchyDB Postgres對其進(jìn)行了測試。Quay的靜態(tài)漏洞分析器的能力也得到了增強，旨在提高資源利用率。

未來(lái)展望

Quay在2024年之后的路線(xiàn)圖非常值得關(guān)注。我們希望在今年完成向新用戶(hù)界面的遷移，并完全移除基于A(yíng)ngular的舊界面。我們計劃增強核心注冊表功能，以改進(jìn)容器鏡像生命周期和工作流管理，并實(shí)現自動(dòng)化，例如不可變標簽、默認標簽過(guò)期策略，以及基于漏洞或不正確/缺失簽名拒絕拉取的策略。我們還計劃在Quay端改進(jìn)OpenShift集群上用戶(hù)和工作負載的大規模身份驗證。最后，我們希望在Quay和Clair斷開(kāi)運行時(shí)，能更輕松地將漏洞數據庫轉移到離線(xiàn)環(huán)境。