Błąd AWS: "Odmowa dostępu" w CodeDeploy po utworzeniu przez Jenkinsa

Question

Ustawiłem Jenkinsa na instancji EC2, która uruchamia kompilację, gdy zmiany są przekazywane do gałęzi głównej w github. Gdy kompilacja na jenkins przechodzi, uruchamia proces zip kodu źródłowego i umieszcza go w konkretnym wiadrze S3. Następnie aplikacja CodeDeploy, o której Jenkins jest świadomy w konfiguracji, i uruchamia proces instalacji, aby spróbować pobrać kod źródłowy ZIP z S3, ale powoduje błąd: Access Denied. Wygląda na to, że rola IAM nie ma właściwego dostępu i uprawnień do pobierania ZIP z S3.

Mój problem polega na próbie zrozumienia roli IAM, jej związku z użytkownikiem Jenkins i rolą usługi IAM? Jak skonfigurować uprawnienia i kto powinien uzyskać te uprawnienia? Proszę doradzić i pomóc mi to zrozumieć.

Answer 1

W konfiguracji CodeDeploy są zazwyczaj dwa scenariusze ... część, która "tworzy" wdrożenie (zwykle jest to serwer CI/agent tworzenia) i agenta CodeDeploy, który działa na instancjach docelowych i czy rozlokowanie. Pierwsza połowa to w zasadzie przesuwając do CodeDeployment, a druga połowa to ściągając z tego ... tak lubię ją wizualizować.

Dla agentów CI/agentów kompilacji, powinni oni mieć rolę IAM z uprawnieniami, jak na przykład ... Dzięki temu agent budujący może (1) uzyskać dostęp do wiadra S3 przeznaczonego do wdrożenia i (2) uzyskać dostęp do usługa CodeDeploy stworzyć wersje itp

{ 
    "Version": "2012-10-17", 
    "Statement": [ 
     { 
      "Effect": "Allow", 
      "Action": [ 
       "s3:ListAllMyBuckets" 
      ], 
      "Resource": "arn:aws:s3:::*" 
     },  { 
      "Effect": "Allow", 
      "Action": [ 
       "s3:PutObject" 
      ], 
      "Resource": "arn:aws:s3:::YourDeploymentBucket" 
     }, 
     { 
      "Effect": "Allow", 
      "Action": [ 
       "codedeploy:*" 
      ], 
      "Resource": "*" 
     } 
    ] 
} 

na instancji EC2 cel, muszą mieć coś takiego ... to daje usługa agenta CodeDeploy (1) dostęp do wiadra S3 ciągnąć rewizji i (2) dostęp do wszystkich ogólnych zasobników z wdrożeniem kodu, aby agent mógł się sam zaktualizować. Oczywiście te instancje muszą spełniać wszystkie inne kryteria ... ogólnie rzecz biorąc, potrzebują one roli IAM i muszą mieć zainstalowanego agenta wdrażania kodu.

{ 
    "Version": "2012-10-17", 
    "Statement": [ 
     { 
      "Effect": "Allow", 
      "Action": [ 
       "s3:Get*", 
       "s3:List*" 
      ], 
      "Resource": [ 
       "arn:aws:s3:::YourDeploymentBucket/*", 
       "arn:aws:s3:::aws-codedeploy-us-east-1/*", 
       "arn:aws:s3:::aws-codedeploy-us-west-1/*", 
       "arn:aws:s3:::aws-codedeploy-us-west-2/*", 
       "arn:aws:s3:::aws-codedeploy-ap-northeast-1/*", 
       "arn:aws:s3:::aws-codedeploy-ap-northeast-2/*", 
       "arn:aws:s3:::aws-codedeploy-ap-south-1/*", 
       "arn:aws:s3:::aws-codedeploy-ap-southeast-1/*", 
       "arn:aws:s3:::aws-codedeploy-ap-southeast-2/*", 
       "arn:aws:s3:::aws-codedeploy-eu-central-1/*", 
       "arn:aws:s3:::aws-codedeploy-eu-west-1/*", 
       "arn:aws:s3:::aws-codedeploy-sa-east-1/*" 
      ] 
     } 
    ] 
} 

Jak przypisać te uprawnienia należy do ciebie ... jeśli agenci budować przypadki EC2, byłoby najlepiej, aby przypisać je jako polityka dołączonej do IAM roli związanej z instancji (ów). W przypadku docelowych maszyn wdrożeniowych zrobiłbyś to samo ... utwórz zasadę i przypisz ją do ról IAM powiązanych z instancjami, które chcesz skierować.