从Kubernetes安全地访问AWS服务,告诉你多云场景下如何管理云凭据!
作者|?Alexey Ledenev
翻譯 | 天道酬勤,責編 |?Carol
出品 | CSDN云計算(ID:CSDNcloud)
隨著企業與各種云提供商合作,多云場景已經變得十分常見。
在谷歌Kubernetes引擎(GKE)上運行的應用程序需要訪問亞馬遜網絡服務(AWS)API時,這種情況也會出現。任何應用程序都有需求,也許它需要在AmazonRedshift上運行分析查詢,訪問存儲在Amazon S3存儲桶中的數據,使用Amazon Polly將文本轉換為語音或使用任何其他AWS服務。
跨云訪問帶來了新挑戰:如何管理云憑據。這是從一個云提供商訪問另一個提供商運行的服務所必需解決的問題。如果用不成熟的方法來分發和保存云提供商的機密是非常不安全的。將長期憑證分配給需要訪問AWS服務的每個服務管理起來具有挑戰性,并且存在潛在的安全風險。
當前解決方案
實際上,每個云服務商都提供了自己獨特的解決方案來克服這一挑戰,和其中一個云服務商合作就可以解決。
谷歌云(Google Cloud)推出了Workload Identity,這是GKE應用程序認證和使用其他谷歌云服務的推薦方式。Workload Identity 通過綁定Kubernetes服務帳戶和Cloud IAM服務帳戶來工作,因此你可以使用本地Kubernetes概念來定義哪些工作負載以哪些身份運行,并允許你的工作負載自動訪問其他谷歌云服務,而無需管理Kubernetes秘密或IAM服務帳戶密鑰。
AWS通過“ IAM服務帳戶角色”功能支持類似的功能。使用Amazon EKS集群上服務帳戶的IAM角色,可以將IAM角色與Kubernetes服務帳戶關聯。然后該服務帳戶可以向使用該服務帳戶任何Pod中的容器提供AWS權限。使用此功能不再需要為工作節點IAM角色提供擴展權限,以便該節點上的Pod可以調用AWS API。
但是,如果你在GKE集群上運行應用程序工作負載,并且希望在不影響安全性的情況下訪問AWS服務該怎么辦?
定義一個使用案例
假設你已經有一個AWS賬戶和一個GKE集群,并且你的公司已決定在GKE集群上運行基于微服務的應用程序,但仍想使用AWS賬戶中的資源(Amazon S3和SNS服務)與在AWS上部署的其他系統。
例如,在GKE集群中運行業務流程作業(部署為Kubernetes Job),需要將數據文件上傳到S3存儲桶中并向Amazon SNS主題發送消息。等效的命令行如下:
這是一個很簡單的例子。為了能使這些命令成功執行,業務流程作業必須具有可用的AWS憑證,并且這些憑證必須能夠進行相關的API調用。
不成熟的(非安全的)方法:IAM的長期憑據
導出某些AWS IAM用戶的AWS訪問密鑰和保密密鑰,并將AWS憑證作為憑證文件或環境變量注入到業務流程作業中。可能不是直接執行此操作,而是使用RBAC授權策略保護的Kubernetes Secrets資源。
這里的風險是這些憑據永遠不會過期。必須將它們從AWS環境轉移到GCP環境,并且在大多數情況下,人們希望將它們存儲在某個位置,以便在以后需要時可用于重新創建業務流程作業。
使用長期AWS憑證時,可以通過多種方式來破壞你的AWS賬戶。無意中將AWS憑證提交到GitHub存儲庫中、將其保存在Wiki系統中、針對不同的服務和應用程序重復使用憑證和允許無限制訪問等等。
盡管可以為已發布的IAM用戶憑據設計適當的憑據管理解決方案,但是如果你永遠不會一開始就創建這些長期憑據,則不需要此解決方案。
作者提出的方法
基本思想是將AWS IAM角色分配給GKE Pod,類似于針對服務帳戶云特定功能的工作負載身份和EKS IAM角色。
對我們來說很幸運的是,AWS允許為開放ID連接聯盟(OpenID Connect Federation,OIDC)身份提供者而不是IAM用戶創建IAM角色。另一方面,谷歌實現了OIDC提供程序,并通過工作負載身份功能將其與GKE緊密集成。為GKE Pod提供有效的OIDC令牌,該令牌在鏈接到谷歌云服務帳戶的Kubernetes服務帳戶下運行。所有這些都可以有助于實現GKE-to-AWS的安全訪問。
將OIDC訪問令牌轉換為ID令牌
需要完成該方法還缺少一點東西。通過正確設置工作負載身份,GKE Pod會獲得OIDC訪問令牌,該令牌允許訪問谷歌云服務。為了從AWS安全令牌服務(STS)獲取臨時AWS憑證,你需要提供有效的OIDC ID令牌。
正確設置以下環境變量后,AWS開發工具包(和aws-cli工具)將自動從STS服務請求臨時AWS憑證:
AWS_WEB_IDENTITY_TOKEN_FILE——Web身份令牌文件的路徑(OIDCID令牌);
AWS_ROLE_ARN——Pod容器承擔的角色的ARN;
AWS_ROLE_SESSION_NAME——應用于此假定角色會話的名稱。
聽起來可能有點復雜,但是作者將提供分步指南并支持開源項目dointl / gtoken來簡化該設置。
gtoken-webhook可變流
gtoken-webhook將gtoken initContainer注入目標Pod和一個附加的gtoken sidekick容器(以在到期前刷新OIDC ID令牌),安裝令牌量并注入三個AWS特定的環境變量。gtoken容器會生成有效的GCP OIDC ID令牌,并將其寫入令牌卷。它還會注入必需的AWS環境變量。
AWS SDK將代表你自動對AWS STS進行相應的AssumeRoleWithWebIdentity調用。它將處理內存中的緩存以及根據需要刷新憑據。
配置流程指南
1)部署gtoken-webhook
要部署gtoken-webhook服務器,我們需要在Kubernetes集群中創建一個webhook服務和部署。這很簡單,只需配置服務器的TLS。如果你想檢查deploy.yaml文件,則會發現從命令行參數中讀取了證書和相應的私鑰文件,并且這些文件的路徑來自指向Kubernetes機密的卷安裝:
要記住的最重要的事情是稍后在webhook配置中設置相應的CA證書,因此apiserver將知道應接受該證書。現在,我們將重用Istio團隊最初編寫的腳本來生成證書簽名請求。然后,我們會將請求發送到KubernetesAPI,獲取證書,然后從結果中創建所需的秘密。
首先,運行webhook-create-signed-cert.sh腳本,并檢查是否已創建包含證書和密鑰的機密:
一旦創建了秘密,我們就可以創建部署和服務。這些是標準的Kubernetes部署和服務資源。到目前為止,我們只生成了HTTP服務器,該服務器通過端口443上的服務接受請求:
2)配置可變的webhook
現在我們的webhook服務器正在運行,它可以接受來自apiserver的請求。但是,我們應該首先在Kubernetes中創建一些配置資源。讓我們從驗證webhook開始,然后再配置可變的webhook。如果查看一下webhook配置,你會注意到它包含CA_BUNDLE的占位符:
有一個小的腳本用此CA替換配置中的CA_BUNDLE占位符。在創建驗證webhook配置之前運行以下命令:
創建一個可變的webhook配置:3)為gtoken-webhook配置RBAC創建與gtoken-webhook一起使用的Kubernetes服務帳戶:
定義webhook服務帳戶的RBAC權限:
4)配置流程變量
用戶應提供以下某些變量,其他變量將自動生成并在以下步驟中重復使用。
PROJECT_ID——GCP項目ID(由用戶提供)
CLUSTER_NAME——GKE群集名稱(由用戶提供)
GSA_NAME——谷歌云帳戶名(由用戶提供)
GSA_ID——谷歌云服務帳戶的唯一ID(由谷歌生成)
KSA_NAME——Kubernetes服務帳戶名(由用戶提供)
KSA_NAMESPACE——Kubernetes命名空間(由用戶提供)
AWS_ROLE_NAME——AWS IAM角色名稱(由用戶提供)
AWS_POLICY_NAME——分配給IAM角色的AWS IAM策略(由用戶提供)
AWS_ROLE_ARN——AWS IAM角色ARN標識符(由AWS生成)
5)谷歌云:啟用GKE工作負載身份
創建一個啟用了工作負載標識的新GKE集群:
或更新現有集群:
6)谷歌云:創建一個谷歌云服務賬戶
創建一個谷歌云服務帳戶:
使用以下角色更新GSA_NAME谷歌服務帳戶:role / iam.workloadIdentityUser——模擬來自GKE 工作負載的服務帳戶
role / iam.serviceAccountTokenCreator——模擬服務帳戶以創建OAuth2訪問令牌,簽署Blob或簽署JWT令牌
為谷歌 OIDC提供者準備角色信任策略文檔:
使用谷歌網絡身份創建AWSIAM角色:
分配所需的AWS角色策略:
獲取要在K8s SA注釋中使用的AWS Role ARN:
8)GKE:創建一個Kubernetes服務帳戶
創建K8s命名空間:
創建K8s服務帳戶:使用GKE工作負載身份(GCP服務帳戶電子郵件)注釋K8s服務帳戶:
使用AWS Role ARN注釋K8s服務帳戶:9)運行一個演示樣例使用K8s ${KSA_NAME}服務帳戶運行新的K8s Pod:
好啦,希望這篇文章對你有用,如果你對此有意見和任何問題,歡迎在評論區和我們交流。
參考文獻
l?GitHub:?Securely access AWS services from GKE cluster with?doitintl/gtoken
l?AWS Docs:?Creating aRole for Web Identity or OpenID Connect Federation
l?Blog:?Kubernetes GKE Workload Identity?link
l?AWS Blog:?Introducing fine-grained IAM roles for service accounts?link
l?GitHub:?AWS Auth using?Web IdentityFederation?from Google Cloud?shrikant0013/gcp-aws-webidentityfederation?GitHubproject
l?Blog:?Using GCP Service Accounts to access AWS IAM Roles?blog post?byColin Panisset
?
原文:https://hackernoon.com/access-aws-services-from-google-kubernetes-engine-securely-a-how-to-guide-x8an3b5y
本文為 CSDN 云計算翻譯,轉載請經授權。
在中國企業與「遠程辦公」正面相遇滿月之際,2月29日,CSDN 聯合廣大「遠程辦公」工具服務企業共同舉辦【抗擊疫情,科技公司在行動】系列之【遠程辦公】專題線上峰會活動:中國「遠程辦公」大考。
掃下方二維碼或點擊閱讀原文免費報名直播+抽取獎品+與大牛交流。想提前了解峰會詳情,可加小助手微信csdnai,回復遠程辦公,進直播群。
推薦閱讀:面試還搞不懂Redis,快看看這40道面試題!| 博文精選 徹徹底底給你講明白啥是SpringMvc異步處理 IntelliJ IDEA 的這個接口調試工具真是太好用了! NFT——加密數字資產的基石 AI口罩“督查官”誕生記 一個學渣的 CTO 逆襲之路真香,朕在看了!點擊“閱讀原文”,參與報名總結
以上是生活随笔為你收集整理的从Kubernetes安全地访问AWS服务,告诉你多云场景下如何管理云凭据!的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 华为:跨过时艰,向未来
- 下一篇: 牛!2020年,这项技术将获得1,000