將 AWS 憑證傳遞到 Docker 容器的最佳方式是什麼?
P粉662361740
P粉662361740 2023-08-27 16:05:56
0
2
530
<p>我正在 Amazon EC2 上執行 docker-container。目前我已將 AWS 憑證新增至 Dockerfile 中。您能讓我知道執行此操作的最佳方法嗎? </p>
P粉662361740
P粉662361740

全部回覆(2)
P粉399585024

自從提出這個問題以來,Docker 發生了很多變化,所以這裡嘗試更新答案。

首先,特別是對於已在雲端中運行的容器上的 AWS 憑證,使用 IAM 角色,如 Vor 建議 是真的是不錯的選擇。如果你能做到這一點,那麼在他的答案中再加一加一並跳過其餘部分。


一旦您開始在雲端之外運行事物,或擁有不同類型的機密,我建議不要在兩個關鍵位置儲存機密:

  1. 環境變數:當在容器上定義這些變數時,容器內的每個進程都可以存取它們,它們透過/proc 可見,應用程式可以將其環境轉儲到stdout,並將其存儲在日誌中,最重要的是,當您檢查容器時,它們會以明文顯示。

  2. In the image itself: images often get pushed to registries where many users have pull access, sometimes without any credentials required to pull the image. Even if you delete the secret from one layer the pull the image。 common Linux utilities like tar and the secret can be found from the step where it was first added to the image.


那麼 Docker 容器中的機密還有哪些其他選項?

選項A:如果您僅在建置映像期間需要此金鑰,在建置開始之前無法使用該金鑰,且尚無權存取BuildKit,則多階段建置是最好的壞選擇。您可以將機密新增至建置的初始階段,在那裡使用它,然後將沒有機密的該階段的輸出複製到您的發布階段,並且僅將該發布階段推送到註冊表伺服器。這個秘密仍然在構建伺服器上的圖像快取中,所以我傾向於僅將其用作最後的手段。

選項B:同樣在建置期間,如果您可以使用18.09發布的BuildKit,目前有實驗功能允許將機密注入作為單一運行線路的捲安裝。此裝載不會寫入映像層,因此您可以在建置期間存取秘密,而不必擔心它會被推送到公共註冊表伺服器。產生的 Dockerfile 如下所示:

# syntax = docker/dockerfile:experimental
FROM python:3
RUN pip install awscli
RUN --mount=type=secret,id=aws,target=/root/.aws/credentials aws s3 cp s3://... ...

您可以使用 18.09 或更高版本中的命令來建立它,例如:

DOCKER_BUILDKIT=1 docker build -t your_image --secret id=aws,src=$HOME/.aws/credentials .

選項 C:在單一節點上執行時,無需 Swarm 模式或其他編排,您可以將憑證載入為唯讀磁碟區。存取此憑證需要與在 docker 外部存取相同憑證檔案的存取權限相同,因此它並不比沒有 docker 的情況更好或更差。最重要的是,當您檢查容器、查看日誌或將映像推送到註冊表伺服器時,該檔案的內容不應該是可見的,因為在每種情況下該磁碟區都位於該磁碟區之外。這確實需要您在 docker 主機上複製憑證,與容器的部署分開。 (請注意,任何能夠在該主機上執行容器的人都可以查看您的憑證,因為對docker API 的存取權限是主機上的root,並且root 可以查看任何使用者的檔案。如果您不信任主機上擁有root 的用戶,然後不要給他們docker API 存取權限。)

For a docker run, this looks like:

docker run -v $HOME/.aws/credentials:/home/app/.aws/credentials:ro your_image

或對於撰寫文件,您需要:

version: '3'
services:
  app:
    image: your_image
    volumes:
    - $HOME/.aws/credentials:/home/app/.aws/credentials:ro

選項 D:借助 Swarm 模式和 Kubernetes 等編排工具,我們現在擁有比卷更好的機密支援。使用 Swarm 模式,檔案在管理員檔案系統上進行加密(儘管解密金鑰通常也在那裡,允許在管理員不輸入解密金鑰的情況下重新啟動管理員)。更重要的是,秘密僅發送給需要秘密的工作人員(使用該秘密運行容器),它僅存儲在工作人員的內存中,而不是磁碟中,並且它作為文件注入到具有 tmpfs 的容器中山。 swarm 外部主機上的使用者無法將該秘密直接掛載到自己的容器中,但是,透過對docker API 的開放訪問,他們可以從節點上正在運行的容器中提取秘密,因此再次限制誰有權訪問該秘密。 API。從 compose 來看,這個秘密注入看起來像是:

version: '3.7'

secrets:
  aws_creds:
    external: true

services:
  app:
    image: your_image
    secrets:
    - source: aws_creds
      target: /home/user/.aws/credentials
      uid: '1000'
      gid: '1000'
      mode: 0700

You turn on swarm mode with docker swarm init for a single node, then follow the directions for adding additional nodes. You can create the secret externally with docker secret create aws_create the secret externally with docker secret create aws_create /HO/. aws/credentials. And you deploy the compose file with docker stack deploy -c docker-compose.yml stack_name

.

我經常使用以下腳本來版本化我的秘密:https://github.com/ sudo-bmitch/docker-config-update

選項 E:還有其他工具可以管理機密,我最喜歡的是 Vault 因為它能夠創建自動過期的有時間限制的秘密。然後,每個應用程式都會取得自己的一組令牌來請求機密,這些令牌使它們能夠在能夠到達保管庫伺服器的情況下請求這些有時間限制的機密。如果某個秘密被從您的網路中取出,這會降低風險,因為它要么不起作用,要么很快就會過期。 AWS for Vault 的特定功能記錄在 https://www.vaultproject.io /docs/secrets/aws/index.html

###
P粉523625080

最好的方法是使用 IAM 角色並且根本不處理憑證。 (請參閱 http://docs.aws .amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html )

Credentials could be retrieved from http://169.254.169.254..... Since this is a private ip address, it could be accessible only from EC2 instances.

所有現代 AWS 用戶端程式庫都「知道」如何從那裡取得、刷新和使用憑證。因此,在大多數情況下,您甚至不需要了解它。只需使用正確的 IAM 角色運行 ec2 即可。

As an option you can pass them at the runtime as environment variables ( i.e docker run -e AWS_ACCESS_KEY_ID=xyz -e AWS_SECRET_ACCESS_KEY=aaa myimage)

您可以透過在終端機上執行 printenv 來存取這些環境變數。

熱門教學
更多>
最新下載
更多>
網站特效
網站源碼
網站素材
前端模板