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

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

重要更新內(nèi)容包括：

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

●   在存儲庫級別修整策略

●   新的用戶界面提供更多Quay功能

●   通用AWS STS支持

●   Quay操作器增強

增強用戶組控制

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

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

靈活實現(xiàn)自動化鏡像生命周期管理

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

在新用戶界面中探索更多功能

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

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

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

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

操作增強

Quay操作器現(xiàn)在可用于在Kubernetes層面微調(diào)資源消耗請求和限制。Quay堆棧中的每個受管組件（包括Quay自身、Clair、二者的PostgreSQL實例、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)

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

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

其他增強

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

未來展望

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