As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Segurança em AWS CodePipeline
A segurança na nuvem AWS é a maior prioridade. Como AWS cliente, você se beneficia de data centers e arquiteturas de rede criados para atender aos requisitos das organizações mais sensíveis à segurança.
A segurança é uma responsabilidade compartilhada entre você AWS e você. O [modelo de responsabilidade compartilhada](https://aws.amazon.com/compliance/shared-responsibility-model/) descreve isso como segurança *da* nuvem e segurança *na* nuvem:
+ **Segurança da nuvem** — AWS é responsável por proteger a infraestrutura que executa AWS os serviços no Nuvem AWS. AWS também fornece serviços que você pode usar com segurança. Auditores terceirizados testam e verificam regularmente a eficácia de nossa segurança como parte dos Programas de Conformidade Programas de [AWS](https://aws.amazon.com/compliance/programs/) de . Para saber mais sobre os programas de conformidade aplicáveis AWS CodePipeline, consulte [AWS Serviços no escopo do programa de conformidade AWS](https://aws.amazon.com/compliance/services-in-scope/) .
+ **Segurança na nuvem** — Sua responsabilidade é determinada pelo AWS serviço que você usa. Você também é responsável por outros fatores, incluindo a confidencialidade de seus dados, os requisitos da sua empresa e as leis e normas aplicáveis.
Esta documentação ajuda você a entender como aplicar o modelo de responsabilidade compartilhada ao usar CodePipeline. Os tópicos a seguir mostram como configurar para atender CodePipeline aos seus objetivos de segurança e conformidade. Você também aprenderá a usar outros AWS serviços que ajudam a monitorar e proteger seus CodePipeline recursos.
**Topics**
+ [Proteção de dados em AWS CodePipeline](data-protection.md)
+ [Gerenciamento de identidade e acesso para AWS CodePipeline](security-iam.md)
+ [Registro e monitoramento em CodePipeline](incident-response.md)
+ [Validação de conformidade para AWS CodePipeline](compliance-validation.md)
+ [Resiliência em AWS CodePipeline](disaster-recovery-resiliency.md)
+ [Segurança da infraestrutura em AWS CodePipeline](infrastructure-security.md)
+ [Práticas recomendadas de segurança](security-best-practices.md)
# Proteção de dados em AWS CodePipeline
O modelo de [responsabilidade AWS compartilhada modelo](https://aws.amazon.com/compliance/shared-responsibility-model/) se aplica à proteção de dados em. Conforme descrito neste modelo, AWS é responsável por proteger a infraestrutura global que executa todos os Nuvem AWS. Você é responsável por manter o controle sobre o conteúdo hospedado nessa infraestrutura. Você também é responsável pelas tarefas de configuração e gerenciamento de segurança dos Serviços da AWS que usa. Para saber mais sobre a privacidade de dados, consulte as [Data Privacy FAQ](https://aws.amazon.com/compliance/data-privacy-faq/). Para saber mais sobre a proteção de dados na Europa, consulte a postagem do blog [AWS Shared Responsibility Model and RGPD](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) no *Blog de segurança da AWS *.
Para fins de proteção de dados, recomendamos que você proteja Conta da AWS as credenciais e configure usuários individuais com Centro de Identidade do AWS IAM ou AWS Identity and Access Management (IAM). Dessa maneira, cada usuário receberá apenas as permissões necessárias para cumprir suas obrigações de trabalho. Recomendamos também que você proteja seus dados das seguintes formas:
+ Use uma autenticação multifator (MFA) com cada conta.
+ Use SSL/TLS para se comunicar com AWS os recursos. Exigimos TLS 1.2 e recomendamos TLS 1.3.
+ Configure a API e o registro de atividades do usuário com AWS CloudTrail. Para obter informações sobre o uso de CloudTrail trilhas para capturar AWS atividades, consulte Como [trabalhar com CloudTrail trilhas](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html) no *Guia AWS CloudTrail do usuário*.
+ Use soluções de AWS criptografia, juntamente com todos os controles de segurança padrão Serviços da AWS.
+ Use serviços gerenciados de segurança avançada, como o Amazon Macie, que ajuda a localizar e proteger dados sensíveis armazenados no Amazon S3.
+ Se você precisar de módulos criptográficos validados pelo FIPS 140-3 ao acessar AWS por meio de uma interface de linha de comando ou de uma API, use um endpoint FIPS. Para saber mais sobre os endpoints FIPS disponíveis, consulte [Federal Information Processing Standard (FIPS) 140-3](https://aws.amazon.com/compliance/fips/).
É altamente recomendável que nunca sejam colocadas informações confidenciais ou sensíveis, como endereços de e-mail de clientes, em tags ou campos de formato livre, como um campo **Nome**. Isso inclui quando você trabalha com ou Serviços da AWS usa o console, a API ou AWS SDKs. AWS CLI Quaisquer dados inseridos em tags ou em campos de texto de formato livre usados para nomes podem ser usados para logs de faturamento ou de diagnóstico. Se você fornecer um URL para um servidor externo, é fortemente recomendável que não sejam incluídas informações de credenciais no URL para validar a solicitação nesse servidor.
As melhores práticas de segurança a seguir também abordam a proteção de dados no CodePipeline:
+ [Configure a criptografia do lado do servidor para artefatos armazenados no Amazon S3 para CodePipeline](S3-artifact-encryption.md)
+ [Use AWS Secrets Manager para rastrear senhas de bancos de dados ou chaves de API de terceiros](parameter-store-encryption.md)
## Privacidade do tráfego entre redes
A Amazon VPC é uma AWS service (Serviço da AWS) que você pode usar para lançar AWS recursos em uma rede virtual (*nuvem privada virtual*) que você define. CodePipelinesuporta endpoints Amazon VPC baseados em AWS PrivateLink, uma AWS tecnologia que facilita a comunicação privada entre o Serviços da AWS uso de uma interface de rede elástica com endereços IP privados. Isso significa que você pode se conectar diretamente CodePipeline por meio de um endpoint privado em sua VPC, mantendo todo o tráfego dentro da VPC e da rede. AWS Anteriormente, era necessário que os aplicativos executados dentro de uma VPC estivessem conectados à Internet para que fosse estabelecida uma conexão com o CodePipeline. Com uma VPC, você possui controle sobre suas configurações de rede, como:
+ Intervalo de endereços IP
+ Sub-redes
+ Tabelas de rotas e
+ Gateways de rede.
Para conectar sua VPC a CodePipeline, você define uma interface para a qual VPC endpoint. CodePipeline Esse tipo de endpoint permite que você conecte a VPC aos Serviços da AWS. O endpoint fornece conectividade confiável e escalável CodePipeline sem a necessidade de um gateway de internet, instância de tradução de endereços de rede (NAT) ou conexão VPN. Para obter mais informações sobre como configurar uma VPC, consulte o [Guia do usuário da VPC](https://docs.aws.amazon.com/vpc/latest/userguide/).
## Criptografia em repouso
Os dados inseridos CodePipeline são criptografados em repouso usando AWS KMS keys. Os artefatos de código são armazenados em um bucket S3 de propriedade do cliente e criptografados com a chave Chave gerenciada pela AWS ou com uma chave gerenciada pelo cliente. Para obter mais informações, consulte [Configure a criptografia do lado do servidor para artefatos armazenados no Amazon S3 para CodePipeline](S3-artifact-encryption.md).
## Criptografia em trânsito
Toda service-to-service comunicação é criptografada em trânsito usando SSL/TLS.
## Gerenciamento das chaves de criptografia
Se você escolher a opção padrão para criptografar artefatos de código, CodePipeline use o. Chave gerenciada pela AWS Você não pode alterar ou excluir isso Chave gerenciada pela AWS. Se você usar uma chave gerenciada pelo cliente AWS KMS para criptografar ou descriptografar artefatos no bucket do S3, poderá alterar ou alternar essa chave gerenciada pelo cliente conforme necessário.
**Importante**
CodePipeline só oferece suporte a chaves KMS simétricas. Não use uma chave assimétrica do KMS para criptografar os dados no bucket do S3.
**Topics**
# Configure a criptografia do lado do servidor para artefatos armazenados no Amazon S3 para CodePipeline
Há duas maneiras de configurar a criptografia do lado do servidor para artefatos do Amazon S3:
+ CodePipeline cria um bucket de artefatos do S3 e usa como padrão Chave gerenciada pela AWS quando você cria um pipeline usando o assistente Create Pipeline. Chave gerenciada pela AWS É criptografado junto com os dados do objeto e gerenciado por AWS.
+ É possível criar e gerenciar sua própria chave gerenciada pelo cliente.
**Importante**
CodePipeline só oferece suporte a chaves KMS simétricas. Não use uma chave assimétrica do KMS para criptografar os dados no bucket do S3.
Se você estiver usando a chave padrão do S3, não será possível alterar ou excluir essa Chave gerenciada pela AWS. Se você estiver usando uma chave gerenciada pelo cliente AWS KMS para criptografar ou descriptografar artefatos no bucket do S3, poderá alterar ou alternar essa chave gerenciada pelo cliente conforme necessário.
O Amazon S3 comporta políticas de bucket que você pode usar se precisar de criptografia de servidor para todos os objetos que estão armazenados em seu bucket. Por exemplo, a política de bucket a seguir negará permissão de upload de objeto (`s3:PutObject`) para todos se a solicitação não incluir o cabeçalho `x-amz-server-side-encryption` que solicita criptografia de servidor com SSE-KMS.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "SSEAndSSLPolicy",
"Statement": [
{
"Sid": "DenyUnEncryptedObjectUploads",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::codepipeline-us-west-2-89050EXAMPLE/*",
"Condition": {
"StringNotEquals": {
"s3:x-amz-server-side-encryption": "aws:kms"
}
}
},
{
"Sid": "DenyInsecureConnections",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": "arn:aws:s3:::codepipeline-us-west-2-89050EXAMPLE/*",
"Condition": {
"Bool": {
"aws:SecureTransport": "false"
}
}
}
]
}
```
------
Para obter mais informações sobre criptografia do lado do servidor e AWS KMS, consulte [Proteção de dados usando criptografia do lado do servidor e Proteção de dados usando criptografia do lado do servidor](https://docs.aws.amazon.com/AmazonS3/latest/userguide/serv-side-encryption.html) com chaves [KMS armazenadas em (SSE-KMS](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingKMSEncryption.html)). AWS Key Management Service
Para obter mais informações sobre AWS KMS, consulte o [Guia do AWS Key Management Service desenvolvedor](https://docs.aws.amazon.com/kms/latest/developerguide/).
**Topics**
+ [Veja o seu Chave gerenciada pela AWS](#S3-view-default-keys)
+ [Configure a criptografia do lado do servidor para buckets S3 usando ou o CloudFormation AWS CLI](#S3-rotate-customer-key)
## Veja o seu Chave gerenciada pela AWS
Quando você usa o assistente **Create Pipeline (Criar pipeline)** para criar seu primeiro pipeline, um bucket do S3 é criado na mesma região em que criou o pipeline. O bucket é usado para armazenar artefatos do pipeline. Quando um pipeline é executado, os artefatos são colocados e recuperados do bucket do S3. Por padrão, CodePipeline usa criptografia do lado do servidor com o AWS KMS uso do para Amazon Chave gerenciada pela AWS S3 (a chave). `aws/s3` Isso Chave gerenciada pela AWS é criado e armazenado em sua AWS conta. Quando os artefatos são recuperados do bucket do S3, CodePipeline usa o mesmo processo SSE-KMS para descriptografar o artefato.
**Para ver informações sobre seu Chave gerenciada pela AWS**
1. Faça login no Console de gerenciamento da AWS e abra o AWS KMS console.
1. Se uma página de boas-vindas for exibida, escolha **Comece a usar agora**.
1. No painel de navegação do serviço, escolha **Chaves gerenciadas pela AWS **.
1. Escolha a região do seu pipeline. Por exemplo, se o pipeline foi criado em `us-east-2`, verifique se o filtro está definido como Leste dos EUA (Ohio).
Para obter mais informações sobre as regiões e os endpoints disponíveis CodePipeline, consulte [AWS CodePipeline endpoints e](https://docs.aws.amazon.com/general/latest/gr/codepipeline.html) cotas.
1. Na lista de chaves de criptografia, selecione a chave com o alias usado para o pipeline (por padrão, **aws/s3**). As informações básicas sobre a chave são exibidas.
## Configure a criptografia do lado do servidor para buckets S3 usando ou o CloudFormation AWS CLI
Ao usar CloudFormation ou AWS CLI para criar um pipeline, você deve configurar a criptografia do lado do servidor manualmente. Use a política de bucket de amostra acima e crie a própria chave gerenciada pelo cliente. Você também pode usar suas próprias chaves em vez da Chave gerenciada pela AWS. Veja a seguir alguns motivos para escolher sua própria chave:
+ Você deseja fazer a rotação das chaves em uma programação para atender aos requisitos comerciais ou de segurança de sua organização.
+ Você deseja criar um pipeline que usa recursos associados a outra conta da AWS . Isso requer o uso de uma chave gerenciada pelo cliente. Para obter mais informações, consulte [Crie um pipeline CodePipeline que use recursos de outra AWS conta](pipelines-create-cross-account.md).
As melhores práticas criptográficas desencorajam a reutilização extensiva de chaves de criptografia. Uma prática recomendada é alternar sua chave em períodos regulares. Para criar um novo material criptográfico para suas AWS KMS chaves, você pode criar uma chave gerenciada pelo cliente e, em seguida, alterar seus aplicativos ou aliases para usar a nova chave gerenciada pelo cliente. Ou é possível habilitar a alternância automática de chaves para uma chave gerenciada pelo cliente existente.
Para alternar sua chave gerenciada pelo cliente, consulte [Como alternar chaves](https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html).
**Importante**
CodePipeline só oferece suporte a chaves KMS simétricas. Não use uma chave assimétrica do KMS para criptografar os dados no bucket do S3.
# Use AWS Secrets Manager para rastrear senhas de bancos de dados ou chaves de API de terceiros
Recomendamos que você use AWS Secrets Manager para alternar, gerenciar e recuperar credenciais de banco de dados, chaves de API e outros **segredos** em todo o ciclo de vida. O Secrets Manager permite substituir credenciais codificadas, incluindo senhas, por uma chamada de API ao Secrets Manager para recuperar o segredo de modo programático. Para obter mais informações, consulte [O que é o AWS Secrets Manager?](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) no Guia do *usuário do AWS Secrets Manager*.
Para pipelines em que você passa parâmetros que são segredos (como OAuth credenciais) em um CloudFormation modelo, você deve incluir referências dinâmicas em seu modelo que acessem os segredos armazenados no Secrets Manager. Para obter padrão e exemplos de ID de referência, consulte [Segredos do Secrets Manager](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/dynamic-references.html#dynamic-references-secretsmanager) no *Guia do usuário do AWS CloudFormation *. Para ver um exemplo que usa referências dinâmicas em um trecho de modelo para GitHub webhook em um pipeline, consulte Configuração de recursos de [webhook](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-codepipeline-webhook.html#aws-resource-codepipeline-webhook--examples).
## Consulte também
Os recursos relacionados a seguir podem ajudar você à medida que trabalha com gerenciamento de segredos.
+ O Secrets Manager pode alternar as credenciais de banco de dados automaticamente, por exemplo, para alternar os segredos do Amazon RDS. Para obter mais informações, consulte [Rotating Your AWS Secrets Manager Secrets Secrets](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotating-secrets.html) no *Guia do Usuário do AWS Secrets Manager*.
+ Para exibir instruções para adicionar referências dinâmicas do Secrets Manager aos modelos do CloudFormation , consulte [https://aws.amazon.com/blogs/security/how-to-create-and-retrieve-secrets-managed-in-aws-secrets-manager-using-aws-cloudformation-template/](https://aws.amazon.com/blogs/security/how-to-create-and-retrieve-secrets-managed-in-aws-secrets-manager-using-aws-cloudformation-template/).
# Gerenciamento de identidade e acesso para AWS CodePipeline
AWS Identity and Access Management (IAM) é uma ferramenta AWS service (Serviço da AWS) que ajuda o administrador a controlar com segurança o acesso aos AWS recursos. Os administradores do IAM controlam quem pode ser *autenticado* (conectado) e *autorizado* (tem permissões) a usar CodePipeline os recursos. O IAM é um AWS service (Serviço da AWS) que você pode usar sem custo adicional.
**Topics**
+ [Público](#security_iam_audience)
+ [Autenticação com identidades](#security_iam_authentication)
+ [Gerenciar o acesso usando políticas](#security_iam_access-manage)
+ [Como AWS CodePipeline funciona com o IAM](security_iam_service-with-iam.md)
+ [AWS CodePipeline exemplos de políticas baseadas em identidade](security_iam_id-based-policy-examples.md)
+ [AWS CodePipeline exemplos de políticas baseadas em recursos](security_iam_resource-based-policy-examples.md)
+ [Solução de problemas AWS CodePipeline de identidade e acesso](security_iam_troubleshoot.md)
+ [referência de permissões](permissions-reference.md)
+ [Gerenciar a função CodePipeline de serviço](how-to-custom-role.md)
## Público
A forma como você usa AWS Identity and Access Management (IAM) difere com base na sua função:
+ **Usuário do serviço**: solicite permissões ao seu administrador se você não conseguir acessar os atributos (consulte [Solução de problemas AWS CodePipeline de identidade e acesso](security_iam_troubleshoot.md)).
+ **Administrador do serviço**: determine o acesso do usuário e envie solicitações de permissão (consulte [Como AWS CodePipeline funciona com o IAM](security_iam_service-with-iam.md))
+ **Administrador do IAM**: escreva políticas para gerenciar o acesso (consulte [AWS CodePipeline exemplos de políticas baseadas em identidade](security_iam_id-based-policy-examples.md))
## Autenticação com identidades
A autenticação é a forma como você faz login AWS usando suas credenciais de identidade. Você deve estar autenticado como usuário do IAM ou assumindo uma função do IAM. Usuário raiz da conta da AWS
Você pode fazer login como uma identidade federada usando credenciais de uma fonte de identidade como Centro de Identidade do AWS IAM (IAM Identity Center), autenticação de login único ou credenciais. Google/Facebook Para ter mais informações sobre como fazer login, consulte [Como fazer login em sua Conta da AWS](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) no *Guia do usuário do Início de Sessão da AWS *.
Para acesso programático, AWS fornece um SDK e uma CLI para assinar solicitações criptograficamente. Para ter mais informações, consulte [AWS Signature Version 4 para solicitações de API](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) no *Guia do usuário do IAM*.
### Usuário raiz da conta da AWS
Ao criar um Conta da AWS, você começa com uma identidade de login chamada *usuário Conta da AWS raiz* que tem acesso completo a todos Serviços da AWS os recursos. É altamente recomendável não usar o usuário-raiz em tarefas diárias. Consulte as tarefas que exigem credenciais de usuário-raiz em [Tarefas que exigem credenciais de usuário-raiz](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks) no *Guia do usuário do IAM*.
### Usuários e grupos do IAM
Um *[usuário do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)* é uma identidade com permissões específicas para uma única pessoa ou aplicação. É recomendável usar credenciais temporárias, em vez de usuários do IAM com credenciais de longo prazo. Para obter mais informações, consulte [Exigir que usuários humanos usem a federação com um provedor de identidade para acessar AWS usando credenciais temporárias](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp) no *Guia do usuário do IAM*.
Um [https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) especifica um conjunto de usuários do IAM e facilita o gerenciamento de permissões para grandes conjuntos de usuários. Para ter mais informações, consulte [Casos de uso de usuários do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/gs-identities-iam-users.html) no *Guia do usuário do IAM*.
### Perfis do IAM
Uma *[perfil do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)* é uma identidade com permissões específicas que oferece credenciais temporárias. Você pode assumir uma função [mudando de um usuário para uma função do IAM (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html) ou chamando uma operação de AWS API AWS CLI ou. Para saber mais, consulte [Métodos para assumir um perfil](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage-assume.html) no *Manual do usuário do IAM*.
Os perfis do IAM são úteis para acesso de usuário federado, permissões de usuário do IAM temporárias, acesso entre contas, acesso entre serviços e aplicações em execução no Amazon EC2. Consulte mais informações em [Acesso a recursos entre contas no IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) no *Guia do usuário do IAM*.
## Gerenciar o acesso usando políticas
Você controla o acesso AWS criando políticas e anexando-as a AWS identidades ou recursos. Uma política define permissões quando associada a uma identidade ou recurso. AWS avalia essas políticas quando um diretor faz uma solicitação. A maioria das políticas é armazenada AWS como documentos JSON. Para ter mais informações sobre documentos de política JSON, consulte [Visão geral das políticas JSON](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json) no *Guia do usuário do IAM*.
Por meio de políticas, os administradores especificam quem tem acesso a que, definindo qual **entidade principal** pode realizar **ações** em quais **recursos** e sob quais **condições**.
Por padrão, usuários e perfis não têm permissões. Um administrador do IAM cria políticas do IAM e as adiciona aos perfis, os quais os usuários podem então assumir. As políticas do IAM definem permissões, independentemente do método usado para realizar a operação.
### Políticas baseadas em identidade
As políticas baseadas em identidade são documentos de políticas de permissão JSON que você anexa a uma identidade (usuário, grupo ou perfil). Essas políticas controlam quais ações as identidades podem realizar, em quais recursos e sob quais condições. Para saber como criar uma política baseada em identidade, consulte [Definir permissões personalizadas do IAM com as políticas gerenciadas pelo cliente](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) no *Guia do Usuário do IAM*.
As políticas baseadas em identidade podem ser políticas *em linha* (incorporadas diretamente em uma única identidade) ou *políticas gerenciadas* (políticas autônomas anexadas a várias identidades). Para saber como escolher entre uma política gerenciada e políticas em linha, consulte [Escolher entre políticas gerenciadas e políticas em linha](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-choosing-managed-or-inline.html) no *Guia do usuário do IAM*.
### Políticas baseadas em recursos
Políticas baseadas em recursos são documentos de políticas JSON que você anexa a um recurso. Entre os exemplos estão *políticas de confiança de perfil* do IAM e *políticas de bucket* do Amazon S3. Em serviços compatíveis com políticas baseadas em recursos, os administradores de serviço podem usá-las para controlar o acesso a um recurso específico. É necessário [especificar uma entidade principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) em uma política baseada em recursos.
Políticas baseadas em recursos são políticas em linha localizadas nesse serviço. Você não pode usar políticas AWS gerenciadas do IAM em uma política baseada em recursos.
### Outros tipos de política
AWS oferece suporte a tipos de políticas adicionais que podem definir o máximo de permissões concedidas por tipos de políticas mais comuns:
+ **Limites de permissões**: definem o número máximo de permissões que uma política baseada em identidade pode conceder a uma entidade do IAM. Para saber mais sobre limites de permissões, consulte [Limites de permissões para identidades do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) no *Guia do usuário do IAM*.
+ **Políticas de controle de serviço (SCPs)** — Especifique as permissões máximas para uma organização ou unidade organizacional em AWS Organizations. Para saber mais, consulte [Políticas de controle de serviço](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) no *Guia do usuário do AWS Organizations *.
+ **Políticas de controle de recursos (RCPs)** — Defina o máximo de permissões disponíveis para recursos em suas contas. Para obter mais informações, consulte [Políticas de controle de recursos (RCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) no *Guia AWS Organizations do usuário*.
+ **Políticas de sessão**: políticas avançadas transmitidas como um parâmetro durante a criação de uma sessão temporária para um perfil ou um usuário federado. Para saber mais, consulte [Políticas de sessão](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) no *Guia do usuário do IAM*.
# Como AWS CodePipeline funciona com o IAM
Antes de usar o IAM para gerenciar o acesso CodePipeline, você deve entender quais recursos do IAM estão disponíveis para uso CodePipeline. Para ter uma visão de alto nível de como CodePipeline e de outras coisas Serviços da AWS funcionam com o IAM, veja Serviços da AWS como [trabalhar com o IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) no *Guia do usuário do IAM*.
**Topics**
+ [CodePipeline políticas baseadas em identidade](#security_iam_service-with-iam-id-based-policies)
+ [CodePipeline políticas baseadas em recursos](#security_iam_service-with-iam-resource-based-policies)
+ [Autorização baseada em CodePipeline tags](#security_iam_service-with-iam-tags)
+ [CodePipeline Funções do IAM](#security_iam_service-with-iam-roles)
## CodePipeline políticas baseadas em identidade
Com as políticas baseadas em identidade do IAM, é possível especificar ações permitidas ou negadas e recursos, bem como as condições sob as quais as ações são permitidas ou negadas. O CodePipeline oferece suporte a ações, recursos e chaves de condição específicos. Para conhecer todos os elementos usados em uma política JSON, consulte [Referência de elementos de política JSON do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html) no *Guia do usuário do IAM*.
### Ações
Os administradores podem usar políticas AWS JSON para especificar quem tem acesso ao quê. Ou seja, qual **entidade principal** pode executar **ações** em quais **recursos** e em que **condições**.
O elemento `Action` de uma política JSON descreve as ações que podem ser usadas para permitir ou negar acesso em uma política. Incluem ações em uma política para conceder permissões para executar a operação associada.
As ações políticas CodePipeline usam o seguinte prefixo antes da ação:`codepipeline:`.
Por exemplo, para conceder a alguém permissão para exibir os pipelines existentes na conta, inclua a ação `codepipeline:GetPipeline` em sua política. As declarações de política devem incluir um `NotAction` elemento `Action` ou. CodePipeline define seu próprio conjunto de ações que descrevem as tarefas que você pode executar com esse serviço.
Para especificar várias ações em uma única instrução, separe-as com vírgulas, como segue:
```
"Action": [
"codepipeline:action1",
"codepipeline:action2"
```
Você também pode especificar várias ações usando caracteres curinga (\$1). Por exemplo, para especificar todas as ações que começam com a palavra `Get`, inclua a seguinte ação:
```
"Action": "codepipeline:Get*"
```
Para ver uma lista de CodePipeline ações, consulte [Ações definidas por AWS CodePipeline](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awscodepipeline.html#awscodepipeline-actions-as-permissions) no *Guia do usuário do IAM*.
### Recursos
Os administradores podem usar políticas AWS JSON para especificar quem tem acesso ao quê. Ou seja, qual **entidade principal** pode executar **ações** em quais **recursos** e em que **condições**.
O elemento de política JSON `Resource` especifica o objeto ou os objetos aos quais a ação se aplica. Como prática recomendada, especifique um recurso usando seu [nome do recurso da Amazon (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html). Para ações que não oferecem compatibilidade com permissões em nível de recurso, use um curinga (\$1) para indicar que a instrução se aplica a todos os recursos.
```
"Resource": "*"
```
#### recursos e operações
No , o principal recurso é um pipeline. Em uma política, você usa um Nome de recurso da Amazon (ARN) para identificar o recurso ao qual a política de aplica. oferece suporte a outros recursos que podem ser usados com o recurso principal, como estágios, ações e ações personalizadas. Estes são chamados de sub-recursos. Esses recursos e sub-recursos têm nomes de recursos da Amazon (ARNs) exclusivos associados a eles. Para obter mais informações sobre ARNs, consulte [Amazon Resource Names (ARN) e AWS service (Serviço da AWS) namespaces](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html) no. *Referência geral da Amazon Web Services* Para obter o ARN de pipeline associado ao seu pipeline, localize o ARN do pipeline em **Configurações** no console. Para obter mais informações, consulte [Visualizar o ARN do pipeline e o ARN do perfil de serviço (console)](pipelines-settings-console.md).
| Tipo de recurso | Formato do ARN |
| --- | --- |
| Pipeline | arn: aws:codepipeline::: *region* *account* *pipeline-name* |
| Estágio | arn: aws:codepipeline:::/*region**account**pipeline-name**stage-name* |
| Ação | arn: aws:codepipeline::://*region**account**pipeline-name**stage-name**action-name* |
| Ação personalizada | arn:aws:codepipeline: ::actiontype:///regionaccountownercategoryproviderversion |
| Todos os recursos | arn:aws:codepipeline:\$1 |
| Todos os recursos do pertencentes à conta especificada na região especificada | arn: aws:codepipeline::: \$1 *region* *account* |
**nota**
A maioria dos serviços em AWS trata dois pontos (:) ou uma barra invertida (/) como o mesmo caractere em. ARNs No entanto, o usa uma correspondência exata nos padrões e regras dos eventos. Use os caracteres do ARN corretos ao criar padrões de evento para que eles correspondam à sintaxe ARN no pipeline a que você quer corresponder.
Em , há chamadas de API que dão suporte a permissões no nível do recurso. As permissões no nível do recurso indicam se uma chamada de API pode especificar um Nome de recurso da Amazon (ARN) de recurso ou se a chamada de API só pode especificar todos os recursos usando o caractere curinga. Consulte [referência de permissões](permissions-reference.md) para obter uma descrição detalhada das permissões em nível de recurso e uma lista das chamadas de CodePipeline API que oferecem suporte a permissões em nível de recurso.
Por exemplo, você pode indicar um pipeline específico (*myPipeline*) em sua declaração usando seu ARN da seguinte forma:
```
"Resource": "arn:aws:codepipeline:us-east-2:111222333444:myPipeline"
```
Você também pode especificar todos os pipelines pertencentes a uma conta específica usando o caractere curinga (\$1), conforme o seguinte:
```
"Resource": "arn:aws:codepipeline:us-east-2:111222333444:*"
```
Para especificar todos os recursos, ou se uma ação de API específica não for compatível ARNs, use o caractere curinga (\$1) no `Resource` elemento da seguinte forma:
```
"Resource": "*"
```
**nota**
Ao criar políticas do IAM, siga as dicas de segurança padrão de concessão de privilégio mínimo, ou seja, conceda apenas as permissões necessárias à execução de uma tarefa. Se uma chamada de API for compatível ARNs, ela suportará permissões em nível de recurso e você não precisará usar o caractere curinga (\$1).
Algumas chamadas de API aceitam vários recursos (por exemplo,`GetPipeline`). Para especificar vários recursos em uma única instrução, separe-os ARNs com vírgulas, da seguinte forma:
```
"Resource": ["arn1", "arn2"]
```
fornece um conjunto de operações para trabalhar com os recursos. Para ver uma lista das operações disponíveis, consulte [referência de permissões](permissions-reference.md).
### Chaves de condição
Os administradores podem usar políticas AWS JSON para especificar quem tem acesso ao quê. Ou seja, qual **entidade principal** pode executar **ações** em quais **recursos** e em que **condições**.
O elemento `Condition` especifica quando as instruções são executadas com base em critérios definidos. É possível criar expressões condicionais que usem [agentes de condição](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html), como “igual a” ou “menor que”, para fazer a condição da política corresponder aos valores na solicitação. Para ver todas as chaves de condição AWS globais, consulte as [chaves de contexto de condição AWS global](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) no *Guia do usuário do IAM*.
CodePipeline define seu próprio conjunto de chaves de condição e também oferece suporte ao uso de algumas chaves de condição globais. Para ver todas as chaves de condição AWS globais, consulte [Chaves de contexto de condição AWS global](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) no *Guia do usuário do IAM*.
Todas as ações do Amazon EC2 oferecem suporte às chaves de condição `aws:RequestedRegion` e `ec2:Region`. Para obter mais informações, consulte [Exemplo: restrição de acesso a uma Região específica](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ExamplePolicies_EC2.html#iam-example-region).
Para ver uma lista de chaves de CodePipeline condição, consulte [Chaves de condição AWS CodePipeline](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awscodepipeline.html#awscodepipeline-policy-keys) no *Guia do usuário do IAM*. Para saber com quais ações e recursos você pode usar uma chave de condição, consulte [Ações definidas por AWS CodePipeline](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awscodepipeline.html#awscodepipeline-actions-as-permissions).
### Exemplos
Para ver exemplos de políticas CodePipeline baseadas em identidade, consulte. [AWS CodePipeline exemplos de políticas baseadas em identidade](security_iam_id-based-policy-examples.md)
## CodePipeline políticas baseadas em recursos
CodePipeline não oferece suporte a políticas baseadas em recursos. No entanto, é fornecido um exemplo de política baseada em recursos para o serviço S3 relacionado ao CodePipeline .
### Exemplos
Para ver exemplos de políticas CodePipeline baseadas em recursos, consulte, [AWS CodePipeline exemplos de políticas baseadas em recursos](security_iam_resource-based-policy-examples.md)
## Autorização baseada em CodePipeline tags
Você pode anexar tags a CodePipeline recursos ou passar tags em uma solicitação para CodePipeline. Para controlar o acesso baseado em tags, forneça informações sobre as tags no [elemento de condição](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) de uma política usando as `codepipeline:ResourceTag/key-name`, `aws:RequestTag/key-name` ou chaves de condição `aws:TagKeys`. Para obter mais informações sobre recursos de marcação do CodePipeline , consulte [Marcando atributos](tag-resources.md).
Para visualizar um exemplo de política baseada em identidade que visa limitar o acesso a um recurso baseado nas tags desse recurso, consulte [Usando tags para controlar o acesso aos CodePipeline recursos](tag-based-access-control.md).
## CodePipeline Funções do IAM
Uma [função do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) é uma entidade na sua AWS conta que tem permissões específicas.
### Usando credenciais temporárias com CodePipeline
É possível usar credenciais temporárias para fazer login com federação, assumir um perfil do IAM ou assumir um perfil entre contas. Você obtém credenciais de segurança temporárias chamando operações de AWS STS API, como [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)ou [GetFederationToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html).
CodePipeline suporta o uso de credenciais temporárias.
### Perfis de serviço
CodePipeline permite que um serviço assuma uma [função de serviço](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-role) em seu nome. O perfil permite que o serviço acesse recursos em outros serviços para concluir uma ação em seu nome. Os perfis de serviço aparecem em sua conta do IAM e são de propriedade da conta. Isso significa que um administrador do IAM pode alterar as permissões para esse perfil. Porém, fazer isso pode alterar a funcionalidade do serviço.
CodePipeline suporta funções de serviço.
# AWS CodePipeline exemplos de políticas baseadas em identidade
Por padrão, os usuários e os perfis do IAM não têm permissão para criar ou modificar recursos do CodePipeline . Eles também não podem realizar tarefas usando a AWS API Console de gerenciamento da AWS AWS CLI, ou. Um administrador do IAM deve criar políticas do IAM que concedam aos usuários e perfis permissão para executarem operações de API específicas nos recursos especificados de que precisam. O administrador deve anexar essas políticas aos usuários ou grupos do IAM que exigem essas permissões.
Para saber como criar uma política baseada em identidade do IAM usando esses exemplos de documentos de política JSON, consulte [Criar políticas na guia JSON](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-json-editor) no *Manual do usuário do IAM*.
Para saber como criar um pipeline que usa recursos de outra conta e para conferir exemplos de políticas relacionados, consulte [Crie um pipeline CodePipeline que use recursos de outra AWS conta](pipelines-create-cross-account.md).
**Topics**
+ [Práticas recomendadas de política](security_iam_service-with-iam-policy-best-practices.md)
+ [Visualizar recursos no console](security-iam-resources-console.md)
+ [Permitir que os usuários visualizem suas próprias permissões](security_iam_id-based-policy-examples-view-own-permissions.md)
+ [Exemplos de políticas baseadas em identidade (IAM)](security-iam-id-policies-examples.md)
+ [Usando tags para controlar o acesso aos CodePipeline recursos](tag-based-access-control.md)
+ [Permissões necessárias para usar o console](security-iam-permissions-console.md)
+ [Permissões necessárias para visualizar registros computacionais no console](security-iam-permissions-console-logs.md)
+ [AWS políticas gerenciadas para AWS CodePipeline](managed-policies.md)
+ [Exemplos de política gerenciada pelo cliente](#customer-managed-policies)
# Práticas recomendadas de política
As políticas baseadas em identidade determinam se alguém pode criar, acessar ou excluir CodePipeline recursos em sua conta. Essas ações podem incorrer em custos para sua Conta da AWS. Ao criar ou editar políticas baseadas em identidade, siga estas diretrizes e recomendações:
+ **Comece com as políticas AWS gerenciadas e passe para as permissões de privilégios mínimos — Para começar a conceder permissões** aos seus usuários e cargas de trabalho, use as *políticas AWS gerenciadas* que concedem permissões para muitos casos de uso comuns. Eles estão disponíveis no seu Conta da AWS. Recomendamos que você reduza ainda mais as permissões definindo políticas gerenciadas pelo AWS cliente que sejam específicas para seus casos de uso. Para saber mais, consulte [Políticas gerenciadas pela AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) ou [Políticas gerenciadas pela AWS para funções de trabalho](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) no *Guia do usuário do IAM*.
+ **Aplique permissões de privilégio mínimo**: ao definir permissões com as políticas do IAM, conceda apenas as permissões necessárias para executar uma tarefa. Você faz isso definindo as ações que podem ser executadas em recursos específicos sob condições específicas, também conhecidas como *permissões de privilégio mínimo*. Para saber mais sobre como usar o IAM para aplicar permissões, consulte [Políticas e permissões no IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) no *Guia do usuário do IAM*.
+ **Use condições nas políticas do IAM para restringir ainda mais o acesso**: é possível adicionar uma condição às políticas para limitar o acesso a ações e recursos. Por exemplo, é possível escrever uma condição de política para especificar que todas as solicitações devem ser enviadas usando SSL. Você também pode usar condições para conceder acesso às ações de serviço se elas forem usadas por meio de uma ação específica AWS service (Serviço da AWS), como CloudFormation. Para saber mais, consulte [Elementos da política JSON do IAM: condição](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) no *Guia do usuário do IAM*.
+ **Use o IAM Access Analyzer para validar suas políticas do IAM a fim de garantir permissões seguras e funcionais**: o IAM Access Analyzer valida as políticas novas e existentes para que elas sigam a linguagem de política do IAM (JSON) e as práticas recomendadas do IAM. O IAM Access Analyzer oferece mais de cem verificações de política e recomendações práticas para ajudar a criar políticas seguras e funcionais. Para saber mais, consulte [Validação de políticas do IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) no *Guia do Usuário do IAM*.
+ **Exigir autenticação multifator (MFA**) — Se você tiver um cenário que exija usuários do IAM ou um usuário root, ative Conta da AWS a MFA para obter segurança adicional. Para exigir MFA quando as operações de API forem chamadas, adicione condições de MFA às suas políticas. Para saber mais, consulte [Configuração de acesso à API protegido por MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) no *Guia do Usuário do IAM*.
Para saber mais sobre as práticas recomendadas do IAM, consulte [Práticas recomendadas de segurança no IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) no *Guia do usuário do IAM*.
# Visualizar recursos no console
O console exige a `ListRepositories` permissão para exibir uma lista de repositórios para sua AWS conta na AWS região em que você está conectado. O console também inclui uma função **Go to resource (Acessar recurso)** para realizar uma pesquisa por recursos que diferencia letras maiúsculas de minúsculas. Essa pesquisa é realizada em sua AWS conta na AWS região em que você está conectado. Os seguintes recursos são exibidos nos seguintes serviços:
+ AWS CodeBuild: projetos de compilação
+ AWS CodeCommit: repositórios
+ AWS CodeDeploy: aplicativos
+ AWS CodePipeline: pipelines
Para realizar essa pesquisa nos recursos em todos os serviços, você deve ter as seguintes permissões:
+ AWS CodeBuild: `ListProjects`
+ CodeCommit: `ListRepositories`
+ CodeDeploy: `ListApplications`
+ CodePipeline: `ListPipelines`
Os resultados não serão retornados para os recursos de um serviço se você não tiver permissões para esse serviço. Mesmo se você tiver permissões para visualizar recursos, alguns recursos não serão retornados se houver um `Deny` explícito para visualizar esses recursos.
# Permitir que os usuários visualizem suas próprias permissões
Este exemplo mostra como criar uma política que permita que os usuários do IAM visualizem as políticas gerenciadas e em linha anexadas a sua identidade de usuário. Essa política inclui permissões para concluir essa ação no console ou programaticamente usando a API AWS CLI ou AWS .
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ViewOwnUserInfo",
"Effect": "Allow",
"Action": [
"iam:GetUserPolicy",
"iam:ListGroupsForUser",
"iam:ListAttachedUserPolicies",
"iam:ListUserPolicies",
"iam:GetUser"
],
"Resource": ["arn:aws:iam::*:user/${aws:username}"]
},
{
"Sid": "NavigateInConsole",
"Effect": "Allow",
"Action": [
"iam:GetGroupPolicy",
"iam:GetPolicyVersion",
"iam:GetPolicy",
"iam:ListAttachedGroupPolicies",
"iam:ListGroupPolicies",
"iam:ListPolicyVersions",
"iam:ListPolicies",
"iam:ListUsers"
],
"Resource": "*"
}
]
}
```
# Exemplos de políticas baseadas em identidade (IAM)
É possível anexar políticas a identidades do IAM. Por exemplo, você pode fazer o seguinte:
+ **Anexe uma política de permissões a um usuário ou grupo em sua conta** — Para conceder a um usuário permissões para visualizar pipelines no console, você pode anexar uma política de permissões a um usuário ou grupo ao qual o usuário pertence.
+ **Anexar uma política de permissões a uma função**: você pode anexar uma política de permissões baseada em identidade a um perfil do IAM para conceder permissões entre contas. Por exemplo, o administrador na Conta A pode criar uma função para conceder permissões entre contas para outra AWS conta (por exemplo, Conta B) ou da AWS service (Serviço da AWS) seguinte forma:
1. Um administrador da Conta A cria uma função do IAM e anexa uma política de permissões à função que concede permissões em recursos da Conta A.
1. Um administrador da Conta A anexa uma política de confiança à função identificando a Conta B como a entidade principal, que pode assumir a função.
1. O administrador da Conta B pode então delegar permissões para assumir a função a qualquer usuário na Conta B. Isso permite que os usuários da Conta B criem ou acessem recursos na Conta A. O principal na política de confiança também pode ser um AWS service (Serviço da AWS) diretor se você quiser conceder AWS service (Serviço da AWS) permissões para assumir a função.
Para obter mais informações sobre o uso do IAM para delegar permissões, consulte [Gerenciamento de acesso](https://docs.aws.amazon.com/IAM/latest/UserGuide/access.html) no *Guia do usuário do IAM*.
O exemplo a seguir mostra um exemplo de política de permissões que permite que um usuário desabilite e habilite transições entre todos os estágios no pipeline `MyFirstPipeline` na `us-west-2 region`:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement" : [
{
"Effect" : "Allow",
"Action" : [
"codepipeline:EnableStageTransition",
"codepipeline:DisableStageTransition"
],
"Resource" : [
"arn:aws:codepipeline:us-west-2:111222333444:MyFirstPipeline/*"
]
}
]
}
```
------
O exemplo a seguir mostra uma política na conta 111222333444 que permite que os usuários visualizem, mas não alterem, o pipeline nomeado no console. `MyFirstPipeline` Essa política é baseada na política gerenciada `AWSCodePipeline_ReadOnlyAccess`, mas, como ela é específica ao pipeline `MyFirstPipeline`, a política gerenciada não pode ser usada diretamente. Se você não desejar restringir a política a um pipeline específico, leve em consideração usar uma das políticas gerenciadas criadas e mantidas pelo . Para obter mais informações, consulte [Como trabalhar com políticas gerenciadas](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-using.html). Você deve anexar essa política a um perfil do IAM criado para acesso, por exemplo, a um perfil chamado `CrossAccountPipelineViewers`:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"codepipeline:GetPipeline",
"codepipeline:GetPipelineState",
"codepipeline:GetPipelineExecution",
"codepipeline:ListPipelineExecutions",
"codepipeline:ListActionExecutions",
"codepipeline:ListActionTypes",
"codepipeline:ListPipelines",
"codepipeline:ListTagsForResource",
"iam:ListRoles",
"s3:ListAllMyBuckets",
"codecommit:ListRepositories",
"codedeploy:ListApplications",
"lambda:ListFunctions",
"codestar-notifications:ListNotificationRules",
"codestar-notifications:ListEventTypes",
"codestar-notifications:ListTargets"
],
"Effect": "Allow",
"Resource": "arn:aws:codepipeline:us-west-2:111222333444:MyFirstPipeline"
},
{
"Action": [
"codepipeline:GetPipeline",
"codepipeline:GetPipelineState",
"codepipeline:GetPipelineExecution",
"codepipeline:ListPipelineExecutions",
"codepipeline:ListActionExecutions",
"codepipeline:ListActionTypes",
"codepipeline:ListPipelines",
"codepipeline:ListTagsForResource",
"iam:ListRoles",
"s3:GetBucketPolicy",
"s3:GetObject",
"s3:ListBucket",
"codecommit:ListBranches",
"codedeploy:GetApplication",
"codedeploy:GetDeploymentGroup",
"codedeploy:ListDeploymentGroups",
"elasticbeanstalk:DescribeApplications",
"elasticbeanstalk:DescribeEnvironments",
"lambda:GetFunctionConfiguration",
"opsworks:DescribeApps",
"opsworks:DescribeLayers",
"opsworks:DescribeStacks"
],
"Effect": "Allow",
"Resource": "*"
},
{
"Sid": "CodeStarNotificationsReadOnlyAccess",
"Effect": "Allow",
"Action": [
"codestar-notifications:DescribeNotificationRule"
],
"Resource": "*",
"Condition": {
"ArnLike": {
"codestar-notifications:NotificationsForResource": "arn:aws:iam::*:role/Service*"
}
}
}
]
}
```
------
Após criar essa política, crie o perfil do IAM na conta 111222333444 e anexe a política a esse perfil. Nas relações de confiança da função, você deve adicionar a AWS conta que assumirá essa função. O exemplo a seguir mostra uma política que permite que os usuários da *111111111111* AWS conta assumam funções definidas na conta 111222333444:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111111111111:root"
},
"Action": "sts:AssumeRole"
}
]
}
```
------
O exemplo a seguir mostra uma política criada na *111111111111* AWS conta que permite que os usuários assumam a função nomeada *CrossAccountPipelineViewers* na conta 111222333444:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::111222333444:role/CrossAccountPipelineViewers"
}
]
}
```
------
Você pode criar políticas do IAM para restringir as chamadas e os recursos a que os usuários em sua conta têm acesso e anexar essas políticas ao seu usuário administrativo. Para obter mais informações sobre como criar funções do IAM e explorar exemplos de declarações de política do IAM para, consulte[Exemplos de política gerenciada pelo cliente](security_iam_id-based-policy-examples.md#customer-managed-policies).
# Usando tags para controlar o acesso aos CodePipeline recursos
As condições nas declarações de política do IAM fazem parte da sintaxe que você usa para especificar as permissões para os recursos exigidos pelas CodePipeline ações. O uso de tags em condições é uma forma de controlar o acesso a recursos e solicitações. Para obter informações sobre a marcação de CodePipeline recursos, consulte[Marcando atributos](tag-resources.md). Este tópico discute o controle de acesso com base em tags.
Ao criar políticas do IAM, você pode definir permissões granulares concedendo acesso a recursos específicos. À medida que o número de recursos que você gerencia aumenta, essa tarefa se torna mais difícil. Atribuir etiquetas a recursos e usá-las em condições de declaração de política pode facilitar essa tarefa. Você concede acesso em massa a qualquer recurso utilizando determinada etiqueta. Depois, você a aplica repetidamente a recursos relevantes durante a criação ou posteriormente.
As tags podem ser anexadas ao recurso ou passadas na solicitação para serviços compatíveis com tags. Em CodePipeline, os recursos podem ter tags e algumas ações podem incluir tags. Ao criar uma política do IAM, você poderá usar chaves de condição de tag para controlar:
+ Quais usuários podem executar ações em um recurso de pipeline, com base nas tags que o recurso já tem.
+ Quais tags podem ser transmitidas na solicitação de uma ação.
+ Se chaves de tags específicas podem ser usadas em uma solicitação.
Operadores de condição de string permitem que você construa elementos `Condition` que restringem o acesso com base na comparação de uma chave a um valor de string. Você pode adicionar `IfExists` ao final de qualquer nome de operador de condição, exceto a condição Null. Isso é feito para dizer "Se a chave de política estiver presente no contexto da solicitação, processar a chave conforme especificado na política. Se a chave não estiver presente, avalie o elemento da condição como verdadeiro." Por exemplo, você pode usar `StringEqualsIfExists` para restringir por chaves de condição que podem não estar presentes em outros tipos de recursos.
Para obter a sintaxe e a semântica completas das chaves de condição de tag, consulte [Como controlar o acesso usando tags](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_tags.html). Para obter mais informações sobre as chaves de condição, veja os recursos a seguir. Os exemplos CodePipeline de políticas nesta seção se alinham às seguintes informações sobre chaves de condição e as expandem com exemplos de nuances, CodePipeline como aninhamento de recursos.
+ [Operadores de condição de strings](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html#Conditions_String)
+ [Serviços da AWS que funcionam com o IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)
+ [Sintaxe de SCP](https://docs.aws.amazon.com/IAM/latest/UserGuide/orgs_manage_policies_scps_syntax.html)
+ [Elementos de política JSON do IAM: Condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html)
+ [aws: RequestTag /tag-key](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-requesttag)
+ [Chaves de condição para CodePipeline](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awscodepipeline.html#awscodepipeline-policy-keys)
Os exemplos a seguir demonstram como especificar condições de tag em políticas para usuários do CodePipeline .
**Example 1: Limitar ações com base em tags na solicitação**
A política de usuário `AWSCodePipeline_FullAccess` gerenciado dá aos usuários permissão ilimitada para realizar qualquer CodePipeline ação em qualquer recurso.
A política a seguir limita esse poder e nega a usuários não autorizados a permissão para criar pipelines quando tags específicas estão listadas na solicitação. Para fazer isso, ela negará a ação `CreatePipeline` se a solicitação especificar uma tag chamada `Project` com um dos valores `ProjectA` ou `ProjectB`. (A `aws:RequestTag` chave de condição é usada para controlar quais tags podem ser transmitidas em uma solicitação do IAM.)
No exemplo a seguir, a intenção da política é negar a usuários não autorizados a permissão para criar um pipeline com os valores de tag especificados. No entanto, a criação de um pipeline requer o acesso a recursos além do próprio pipeline (por exemplo, ações e estágios do pipeline). Como o `'Resource'` especificado na política é `'*'`, a política é avaliada com base em cada recurso que tem um ARN e é criada quando o pipeline está sendo criado. Esses recursos adicionais não têm a chave de condição de tag; portanto, a verificação `StringEquals` falha e o usuário não recebe a permissão para criar nenhum pipeline. Para resolver isso, use o operador de condição `StringEqualsIfExists`. Dessa forma, o teste só acontece se a chave de condição existir.
Você pode entender isso da seguinte maneira: "Se o recurso que está sendo verificado tiver uma chave de condição de tag `"RequestTag/Project"`, permita a ação apenas se o valor de chave começar com `projectA`. Se o recurso que está sendo verificado não tiver essa chave de condição, não se preocupe com isso."
Além disso, a política impede que esses usuários não autorizados interfiram nos recursos usando a chave de condição `aws:TagKeys` para não permitir que ações de modificação de tag incluam esses mesmos valores de tag. O administrador de um cliente deve anexar essa política do IAM a usuários administrativos não autorizados, além da política de usuário gerenciada.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"codepipeline:CreatePipeline",
"codepipeline:TagResource"
],
"Resource": "*",
"Condition": {
"StringEqualsIfExists": {
"aws:RequestTag/Project": ["ProjectA", "ProjectB"]
}
}
},
{
"Effect": "Deny",
"Action": [
"codepipeline:UntagResource"
],
"Resource": "*",
"Condition": {
"ForAllValues:StringEquals": {
"aws:TagKeys": ["Project"]
}
}
}
]
}
```
**Example 2: Limitar ações de marcação com base em tags de recursos**
A política de usuário `AWSCodePipeline_FullAccess` gerenciado dá aos usuários permissão ilimitada para realizar qualquer CodePipeline ação em qualquer recurso.
A seguinte política limita esse poder e nega a usuários não autorizados permissão para realizar ações em pipelines específicos do projeto. Para fazer isso, ela negará ações específicas se o recurso tiver uma tag denominada `Project` com um dos valores `ProjectA` ou `ProjectB`. (A chave de condição `aws:ResourceTag` é usada para controlar o acesso a recursos com base nas tags desses recursos.) O administrador de um cliente deve anexar essa política do IAM a usuários não autorizados do IAM, além da política de usuário gerenciada.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"codepipeline:TagResource"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/Project": ["ProjectA", "ProjectB"]
}
}
}
]
}
```
**Example 3: Permitir ações com base em tags na solicitação**
A política a seguir concede aos usuários permissão para criar pipelines de desenvolvimento no CodePipeline.
Para fazer isso, ela permitirá as ações `CreatePipeline` e `TagResource` se a solicitação especificar uma tag denominada `Project` com o valor `ProjectA`. Em outras palavras, a única chave de tag que pode ser especificada é `Project`, e seu valor deve ser `ProjectA`.
A chave de condição `aws:RequestTag` é usada para controlar quais tags podem ser transmitidas em uma solicitação do IAM. A `aws:TagKeys` condição garante que a chave de tag faça diferenciação de letras maiúsculas e minúsculas. Essa política é útil para usuários ou perfis que não têm a política de usuário gerenciada `AWSCodePipeline_FullAccess` anexada. A política gerenciada dá aos usuários permissão ilimitada para realizar qualquer CodePipeline ação em qualquer recurso.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"codepipeline:CreatePipeline",
"codepipeline:TagResource"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestTag/Project": "ProjectA"
},
"ForAllValues:StringEquals": {
"aws:TagKeys": ["Project"]
}
}
}
]
}
```
**Example 4: Limitar ações de marcação com base em tags de recursos**
A política de usuário `AWSCodePipeline_FullAccess` gerenciado dá aos usuários permissão ilimitada para realizar qualquer CodePipeline ação em qualquer recurso.
A seguinte política limita esse poder e nega a usuários não autorizados permissão para realizar ações em pipelines específicos do projeto. Para fazer isso, ela negará ações específicas se o recurso tiver uma tag denominada `Project` com um dos valores `ProjectA` ou `ProjectB`.
Além disso, a política impede que esses usuários não autorizados interfiram nos recursos, usando a chave de condição `aws:TagKeys` para não permitir que ações de modificação de tag removam completamente a tag `Project`. O administrador de um cliente deve anexar essa política do IAM a usuários ou perfis não autorizados, além da política de usuário gerenciada.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"codepipeline:UntagResource"
],
"Resource": "*",
"Condition": {
"ForAllValues:StringEquals": {
"aws:TagKeys": ["Project"]
}
}
}
]
}
```
# Permissões necessárias para usar o console
Para usar o no console do , é necessário ter um conjunto mínimo de permissões dos seguintes serviços:
+ AWS Identity and Access Management
+ Amazon Simple Storage Service
Essas permissões permitem que você descreva outros AWS recursos para sua AWS conta.
Dependendo dos outros serviços que você incorpora aos pipelines, podem ser necessárias permissões de um ou mais dos seguintes itens:
+ AWS CodeCommit
+ AWS CodeBuild
+ CloudFormation
+ AWS CodeDeploy
+ AWS Elastic Beanstalk
+ AWS Lambda
+ AWS OpsWorks
Se você criar uma política do IAM que seja mais restritiva que as permissões mínimas necessárias, o console do não funcionará como pretendido para os usuários com essa política do IAM. Para garantir que esses usuários ainda consigam usar o console, associe também a política gerenciada `AWSCodePipeline_ReadOnlyAccess` ao usuário, conforme descrito em [AWS políticas gerenciadas para AWS CodePipeline](managed-policies.md).
Você não precisa permitir permissões mínimas do console para usuários que estão fazendo chamadas para a API AWS CLI ou para a API.
# Permissões necessárias para visualizar registros computacionais no console
Para visualizar os registros na ação Comandos no CodePipeline console, a função do console deve ter permissões. Para visualizar logs no console, adicione as permissões `logs:GetLogEvents` ao perfil do console.
Na declaração de política do perfil do console, reduza as permissões até o nível do pipeline, conforme mostrado no exemplo a seguir.
```
{
"Effect": "Allow",
"Action": [
"Action": "logs:GetLogEvents"
],
"Resource": "arn:aws:logs:*:YOUR_AWS_ACCOUNT_ID:log-group:/aws/codepipeline/YOUR_PIPELINE_NAME:*"
}
```
# AWS políticas gerenciadas para AWS CodePipeline
Uma política AWS gerenciada é uma política autônoma criada e administrada por AWS. AWS as políticas gerenciadas são projetadas para fornecer permissões para muitos casos de uso comuns, para que você possa começar a atribuir permissões a usuários, grupos e funções.
Lembre-se de que as políticas AWS gerenciadas podem não conceder permissões de privilégio mínimo para seus casos de uso específicos porque elas estão disponíveis para uso de todos os AWS clientes. Recomendamos que você reduza ainda mais as permissões definindo as [ políticas gerenciadas pelo cliente](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies) que são específicas para seus casos de uso.
Você não pode alterar as permissões definidas nas políticas AWS gerenciadas. Se AWS atualizar as permissões definidas em uma política AWS gerenciada, a atualização afetará todas as identidades principais (usuários, grupos e funções) às quais a política está anexada. AWS é mais provável que atualize uma política AWS gerenciada quando uma nova AWS service (Serviço da AWS) for lançada ou novas operações de API forem disponibilizadas para serviços existentes.
Para saber mais, consulte [AWS Políticas gerenciadas pela ](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) no *Guia do usuário do IAM*.
**Importante**
As políticas gerenciadas pela AWS `AWSCodePipelineFullAccess` e `AWSCodePipelineReadOnlyAccess` foram substituídas. Use as políticas `AWSCodePipeline_FullAccess` e `AWSCodePipeline_ReadOnlyAccess`.
## AWS política gerenciada: `AWSCodePipeline_FullAccess`
Esta é uma política que concede acesso total CodePipeline a. Para ver o documento de política JSON no console do IAM, consulte [AWSCodePipeline\$1FullAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AWSCodePipeline_FullAccess).
**Detalhes das permissões**
Esta política inclui as seguintes permissões.
+ `codepipeline`— Concede permissões para CodePipeline.
+ `chatbot`: concede permissões para permitir que as entidades principais gerenciem recursos no Amazon Q Developer em aplicações de chat.
+ `cloudformation`— Concede permissões para permitir que os diretores gerenciem as pilhas de recursos no. CloudFormation
+ `cloudtrail`— Concede permissões para permitir que os diretores gerenciem CloudTrail os recursos de registro.
+ `codebuild`— Concede permissões para permitir que os diretores acessem os recursos de construção no CodeBuild.
+ `codecommit`— Concede permissões para permitir que os diretores acessem os recursos de origem em CodeCommit.
+ `codedeploy`— Concede permissões para permitir que os diretores acessem os recursos de implantação no CodeDeploy.
+ `codestar-notifications`— Concede permissões para permitir que os diretores acessem recursos nas AWS CodeStar Notificações.
+ `ec2`— Concede permissões para permitir implantações CodeCatalyst para gerenciar o balanceamento elástico de carga no Amazon EC2.
+ `ecr`: concede permissões para o acesso a recursos no Amazon ECR.
+ `elasticbeanstalk`: concede permissões para que as entidades principais acessem recursos no Elastic Beanstalk.
+ `iam`: concede permissões para que as entidades principais gerenciem perfis e políticas no IAM.
+ `lambda`: concede permissões para que as entidades principais gerenciem recursos no Lambda.
+ `events`— Concede permissões para permitir que os diretores gerenciem recursos em CloudWatch Eventos.
+ `opsworks`— Concede permissões para permitir que os diretores gerenciem recursos em AWS OpsWorks.
+ `s3`: concede permissões para que as entidades principais gerenciem recursos no Amazon S3.
+ `sns`: concede permissões para que as entidades principais gerenciem recursos de notificação no Amazon SNS.
+ `states`— Concede permissões para permitir que os diretores visualizem as máquinas de estado em AWS Step Functions. Uma máquina de estado consiste em uma coleção de estados que gerenciam tarefas e fazem a transição entre estados.
Para a política, consulte [AWSCodePipeline\$1FullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSCodePipeline_FullAccess.html).
## AWS política gerenciada: `AWSCodePipeline_ReadOnlyAccess`
Essa é uma política que concede acesso somente para leitura a. CodePipeline Para ver o documento de política JSON no console do IAM, consulte [AWSCodePipeline\$1ReadOnlyAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AWSCodePipeline_ReadOnlyAccess).
**Detalhes das permissões**
Esta política inclui as seguintes permissões.
+ `codepipeline`— Concede permissões para ações em CodePipeline.
+ `codestar-notifications`— Concede permissões para permitir que os diretores acessem recursos nas AWS CodeStar Notificações.
+ `s3`: concede permissões para que as entidades principais gerenciem recursos no Amazon S3.
+ `sns`: concede permissões para que as entidades principais gerenciem recursos de notificação no Amazon SNS.
Para a política, consulte [AWSCodePipeline\$1ReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSCodePipeline_ReadOnlyAccess.html).
## AWS política gerenciada: `AWSCodePipelineApproverAccess`
Esta é uma política que concede permissão para aprovar ou rejeitar uma ação de aprovação manual. Para ver o documento de política JSON no console do IAM, consulte [AWSCodePipelineApproverAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AWSCodePipelineApproverAccess).
**Detalhes das permissões**
Esta política inclui as seguintes permissões.
+ `codepipeline`— Concede permissões para ações em CodePipeline.
Para a política, consulte [AWSCodePipelineApproverAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSCodePipelineApproverAccess.html).
## AWS política gerenciada: `AWSCodePipelineCustomActionAccess`
Essa é uma política que concede permissão para criar ações personalizadas CodePipeline ou integrar recursos do Jenkins para criar ou testar ações. Para ver o documento de política JSON no console do IAM, consulte [AWSCodePipelineCustomActionAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AWSCodePipelineCustomActionAccess).
**Detalhes das permissões**
Esta política inclui as seguintes permissões.
+ `codepipeline`— Concede permissões para ações em CodePipeline.
Para a política, consulte [AWSCodePipelineCustomActionAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSCodePipelineCustomActionAccess.html).
## CodePipeline políticas e notificações gerenciadas
CodePipeline suporta notificações, que podem notificar os usuários sobre mudanças importantes nos pipelines. Políticas gerenciadas para CodePipeline incluir declarações de política para funcionalidade de notificação. Para obter mais informações, consulte [O que são notificações?](https://docs.aws.amazon.com/codestar-notifications/latest/userguide/welcome.html).
### Permissões relacionadas a notificações em políticas gerenciadas de acesso total
Essa política gerenciada concede permissões CodePipeline junto com os serviços relacionados CodeCommit CodeBuild, CodeDeploy, e AWS CodeStar notificações. A política também concede as permissões necessárias para trabalhar com outros serviços que se integram aos seus pipelines, como Amazon S3, Elastic Beanstalk, Amazon EC2 e. CloudTrail CloudFormation Os usuários com essa política gerenciada aplicada também podem criar e gerenciar tópicos do Amazon SNS para notificações, assinar e cancelar a assinatura de usuários dos tópicos, listar tópicos a serem escolhidos como destinos para regras de notificação e listar clientes de aplicações em chat do Amazon Q Developer configurados para o Slack.
A política gerenciada `AWSCodePipeline_FullAccess` inclui as declarações a seguir para permitir acesso total às notificações.
```
{
"Sid": "CodeStarNotificationsReadWriteAccess",
"Effect": "Allow",
"Action": [
"codestar-notifications:CreateNotificationRule",
"codestar-notifications:DescribeNotificationRule",
"codestar-notifications:UpdateNotificationRule",
"codestar-notifications:DeleteNotificationRule",
"codestar-notifications:Subscribe",
"codestar-notifications:Unsubscribe"
],
"Resource": "*",
"Condition" : {
"StringLike" : {"codestar-notifications:NotificationsForResource" : "arn:aws:codepipeline:us-west-2:111222333444:MyFirstPipeline"}
}
},
{
"Sid": "CodeStarNotificationsListAccess",
"Effect": "Allow",
"Action": [
"codestar-notifications:ListNotificationRules",
"codestar-notifications:ListTargets",
"codestar-notifications:ListTagsforResource",
"codestar-notifications:ListEventTypes"
],
"Resource": "*"
},
{
"Sid": "CodeStarNotificationsSNSTopicCreateAccess",
"Effect": "Allow",
"Action": [
"sns:CreateTopic",
"sns:SetTopicAttributes"
],
"Resource": "arn:aws:sns:*:*:codestar-notifications*"
},
{
"Sid": "SNSTopicListAccess",
"Effect": "Allow",
"Action": [
"sns:ListTopics"
],
"Resource": "*"
},
{
"Sid": "CodeStarNotificationsChatbotAccess",
"Effect": "Allow",
"Action": [
"chatbot:DescribeSlackChannelConfigurations",
"chatbot:ListMicrosoftTeamsChannelConfigurations"
],
"Resource": "*"
}
```
### Permissões relacionadas a notificações em políticas gerenciadas somente leitura
A política gerenciada `AWSCodePipeline_ReadOnlyAccess` inclui as instruções a seguir para permitir acesso somente leitura às notificações. Os usuários com essa política aplicada podem visualizar notificações de recursos, mas não podem criá-las, gerenciá-las ou inscrever-se nelas.
```
{
"Sid": "CodeStarNotificationsPowerUserAccess",
"Effect": "Allow",
"Action": [
"codestar-notifications:DescribeNotificationRule"
],
"Resource": "*",
"Condition" : {
"StringLike" : {"codestar-notifications:NotificationsForResource" : "arn:aws:codepipeline:us-west-2:111222333444:MyFirstPipeline"}
}
},
{
"Sid": "CodeStarNotificationsListAccess",
"Effect": "Allow",
"Action": [
"codestar-notifications:ListNotificationRules",
"codestar-notifications:ListEventTypes",
"codestar-notifications:ListTargets"
],
"Resource": "*"
}
```
Para obter mais informações sobre o IAM e as notificações, consulte [Identity and Access Management para o AWS CodeStar Notifications](https://docs.aws.amazon.com/codestar-notifications/latest/userguide/security-iam.html).
## AWS CodePipeline atualizações nas políticas AWS gerenciadas
Veja detalhes sobre as atualizações das políticas AWS gerenciadas CodePipeline desde que esse serviço começou a rastrear essas alterações. Para receber alertas automáticos sobre alterações realizadas nesta página, assine o feed RSS na CodePipeline página de histórico do documento do [https://docs.aws.amazon.com/codepipeline/latest/userguide/history.html](https://docs.aws.amazon.com/codepipeline/latest/userguide/history.html).
| Alteração | Descrição | Data |
| --- | --- | --- |
| [AWSCodePipeline\$1FullAccess](#security-iam-awsmanpol-AWSCodePipeline_FullAccess)— Atualizações da política existente | CodePipeline adicionou uma permissão a essa política para dar suporte ListStacks em CloudFormation. | 15 de março de 2024 |
| [AWSCodePipeline\$1FullAccess](#security-iam-awsmanpol-AWSCodePipeline_FullAccess)— Atualizações da política existente | Essa política foi atualizada a fim de adicionar permissões para o Amazon Q Developer em aplicações de chat. Para obter mais informações, consulte [CodePipeline políticas e notificações gerenciadas](#notifications-permissions). | 21 de junho de 2023 |
| [AWSCodePipeline\$1FullAccess](#security-iam-awsmanpol-AWSCodePipeline_FullAccess)e políticas [AWSCodePipeline\$1ReadOnlyAccess](#security-iam-awsmanpol-AWSCodePipeline_ReadOnlyAccess)gerenciadas — atualizações da política existente | CodePipeline adicionou uma permissão a essas políticas para oferecer suporte a um tipo de notificação adicional usando o Amazon Q Developer em aplicativos de bate-papo,`chatbot:ListMicrosoftTeamsChannelConfigurations`. | 16 de maio de 2023 |
| **AWSCodePipelineFullAccess**: descontinuada | Esta política foi substituída por `AWSCodePipeline_FullAccess`. Depois de 17 de novembro de 2022, esta política não poderá ser anexada a novos usuários, grupos ou perfis. Para obter mais informações, consulte [AWS políticas gerenciadas para AWS CodePipeline](#managed-policies). | 17 de novembro de 2022 |
| **AWSCodePipelineReadOnlyAccess**: descontinuada | Esta política foi substituída por `AWSCodePipeline_ReadOnlyAccess`. Depois de 17 de novembro de 2022, esta política não poderá ser anexada a novos usuários, grupos ou perfis. Para obter mais informações, consulte [AWS políticas gerenciadas para AWS CodePipeline](#managed-policies). | 17 de novembro de 2022 |
| CodePipeline começou a rastrear alterações | CodePipeline começou a rastrear as mudanças em suas políticas AWS gerenciadas. | 12 de março de 2021 |
## Exemplos de política gerenciada pelo cliente
Nesta seção, você encontrará exemplos de políticas de usuário que concedem permissões para diversas ações do . Essas políticas funcionam quando você está usando a API AWS SDKs,, ou AWS CLI a. Ao usar o console, você deve conceder permissões adicionais específicas para o console. Para obter mais informações, consulte [Permissões necessárias para usar o console](security-iam-permissions-console.md).
**nota**
Todos os exemplos usam a região Oeste dos EUA (Oregon) (`us-west-2`) e contêm uma conta fictícia. IDs
**Exemplos**
+ [Exemplo 1: conceder permissões para obter o estado de um pipeline](#identity-based-policies-example-1)
+ [Exemplo 2: conceder permissões para habilitar e desabilitar transições entre estágios](#identity-based-policies-example-2)
+ [Exemplo 3: conceder permissões para obter uma lista de todos os tipos de ação disponíveis](#identity-based-policies-example-3)
+ [Exemplo 4: conceder permissões para aprovar ou rejeitar ações de aprovação manual](#identity-based-policies-example-4)
+ [Exemplo 5: conceder permissões para pesquisar por trabalhos para uma ação personalizada](#identity-based-policies-example-5)
+ [Exemplo 6: anexar ou editar uma política para integração do Jenkins com AWS CodePipeline](#identity-based-policies-example-6)
+ [Exemplo 7: configurar o acesso entre contas em um pipeline](#identity-based-policies-example-7)
### Exemplo 1: conceder permissões para obter o estado de um pipeline
O exemplo a seguir concede permissões para obter o estado do pipeline chamado `MyFirstPipeline`:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"codepipeline:GetPipelineState"
],
"Resource": "arn:aws:codepipeline:us-west-2:111222333444:MyFirstPipeline"
}
]
}
```
------
### Exemplo 2: conceder permissões para habilitar e desabilitar transições entre estágios
O exemplo a seguir concede permissões para permitir e desativar transições entre todos os estágios no pipeline chamado `MyFirstPipeline`:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"codepipeline:DisableStageTransition",
"codepipeline:EnableStageTransition"
],
"Resource": "arn:aws:codepipeline:us-west-2:111222333444:MyFirstPipeline/*"
}
]
}
```
------
Para permitir que o usuário permita ou desative transições de um único estágio em um pipeline, você deve especificar o estágio. Por exemplo, para permitir que o usuário habilite e desabilite transições de um estágio chamado `Staging` em um pipeline chamado `MyFirstPipeline`:
```
"Resource": "arn:aws:codepipeline:us-west-2:111222333444:MyFirstPipeline/Staging"
```
### Exemplo 3: conceder permissões para obter uma lista de todos os tipos de ação disponíveis
O exemplo a seguir concede permissões para obter uma lista de todos os tipos de ação disponíveis para os pipelines na região `us-west-2`:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"codepipeline:ListActionTypes"
],
"Resource": "arn:aws:codepipeline:us-west-2:111222333444:actiontype:*"
}
]
}
```
------
### Exemplo 4: conceder permissões para aprovar ou rejeitar ações de aprovação manual
O exemplo a seguir concede permissões para aprovar ou rejeitar ações de aprovação manual em um estágio chamado `Staging` em um pipeline chamado `MyFirstPipeline`:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"codepipeline:PutApprovalResult"
],
"Resource": "arn:aws:codepipeline:us-west-2:111222333444:MyFirstPipeline/Staging/*"
}
]
}
```
------
### Exemplo 5: conceder permissões para pesquisar por trabalhos para uma ação personalizada
O exemplo a seguir concede permissões para pesquisar por trabalhos para a ação personalizada chamada `TestProvider`, que é um tipo de ação de `Test` na primeira versão, em todos os pipelines:
**nota**
O operador de trabalho de uma ação personalizada pode ser configurado em outra conta da AWS ou exigir um perfil do IAM específica para funcionar.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"codepipeline:PollForJobs"
],
"Resource": [
"arn:aws:codepipeline:us-west-2:111222333444:actionType:Custom/Test/TestProvider/1"
]
}
]
}
```
------
### Exemplo 6: anexar ou editar uma política para integração do Jenkins com AWS CodePipeline
Se você configurar um pipeline para usar o Jenkins para criar ou testar, crie uma identidade separada para essa integração e anexe uma política do IAM que tenha as permissões mínimas necessárias para a integração entre Jenkins e. Essa política é a mesma da política gerenciada `AWSCodePipelineCustomActionAccess`. O exemplo a seguir mostra uma política para integração do Jenkins:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"codepipeline:AcknowledgeJob",
"codepipeline:GetJobDetails",
"codepipeline:PollForJobs",
"codepipeline:PutJobFailureResult",
"codepipeline:PutJobSuccessResult"
],
"Resource": "*"
}
]
}
```
------
### Exemplo 7: configurar o acesso entre contas em um pipeline
Você pode configurar o acesso a pipelines para usuários e grupos em outra conta do AWS . A maneira recomendada é criar uma função na conta onde o pipeline foi criado. A função deve permitir que os usuários da outra AWS conta assumam essa função e acessem o pipeline. Para obter mais informações, consulte [Passo a passo: acesso entre contas usando funções](https://docs.aws.amazon.com/IAM/latest/UserGuide/walkthru_cross-account-with-roles.html).
O exemplo a seguir mostra uma política na conta 80398EXAMPLE que permite que os usuários visualizem, mas não alterem, o pipeline nomeado `MyFirstPipeline` no console. Essa política é baseada na política gerenciada `AWSCodePipeline_ReadOnlyAccess`, mas, como ela é específica ao pipeline `MyFirstPipeline`, a política gerenciada não pode ser usada diretamente. Se você não desejar restringir a política a um pipeline específico, leve em consideração usar uma das políticas gerenciadas criadas e mantidas pelo . Para obter mais informações, consulte [Como trabalhar com políticas gerenciadas](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-using.html). Você deve anexar essa política a um perfil do IAM criado para acesso, por exemplo, a um perfil chamado `CrossAccountPipelineViewers`:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"codepipeline:GetPipeline",
"codepipeline:GetPipelineState",
"codepipeline:ListActionTypes",
"codepipeline:ListPipelines",
"iam:ListRoles",
"s3:GetBucketPolicy",
"s3:GetObject",
"s3:ListAllMyBuckets",
"s3:ListBucket",
"codedeploy:GetApplication",
"codedeploy:GetDeploymentGroup",
"codedeploy:ListApplications",
"codedeploy:ListDeploymentGroups",
"elasticbeanstalk:DescribeApplications",
"elasticbeanstalk:DescribeEnvironments",
"lambda:GetFunctionConfiguration",
"lambda:ListFunctions"
],
"Resource": "arn:aws:codepipeline:us-east-2:111122223333:MyFirstPipeline"
}
]
}
```
------
Após criar essa política, crie o perfil do IAM na conta 80398EXAMPLE e anexe a política a esse perfil. Nas relações de confiança da função, você deve adicionar a AWS conta que assume essa função.
O exemplo a seguir mostra uma política criada na *111111111111* AWS conta que permite que os usuários assumam a função nomeada `CrossAccountPipelineViewers` na conta 80398EXAMPLE:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::111122223333:role/CrossAccountPipelineViewers"
}
]
}
```
------
# AWS CodePipeline exemplos de políticas baseadas em recursos
**Topics**
Outros serviços, como o Amazon S3, também aceitam políticas de permissões baseadas em recurso. Por exemplo: você pode anexar uma política a um bucket do S3 para gerenciar permissões de acesso a esse bucket. Embora CodePipeline não ofereça suporte a políticas baseadas em recursos, ele armazena artefatos para serem usados em pipelines em buckets S3 versionados.
**Example Para criar uma política para um bucket do S3 a ser usado como armazenamento de artefatos para CodePipeline**
Você pode usar qualquer bucket S3 versionado como armazenamento de artefatos para. CodePipeline Se você usar o assistente **Create Pipeline (Criar pipeline)** para criar o primeiro pipeline, esse bucket do S3 será criado para garantir que todos os objetos carregados para o armazenamento de artefatos sejam criptografados e que as conexões com o bucket sejam confiáveis. Como melhor prática, se você criar seu próprio bucket do S3, considere adicionar a política a seguir ou seus elementos ao bucket. Nessa política, o ARN do bucket do S3 é `codepipeline-us-east-2-1234567890`. Substitua esse ARN pelo ARN do seu bucket do S3:
****
```
{
"Version":"2012-10-17",
"Id": "SSEAndSSLPolicy",
"Statement": [
{
"Sid": "DenyUnEncryptedObjectUploads",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*",
"Condition": {
"StringNotEquals": {
"s3:x-amz-server-side-encryption": "aws:kms"
}
}
},
{
"Sid": "DenyInsecureConnections",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*",
"Condition": {
"Bool": {
"aws:SecureTransport": false
}
}
}
]
}
```
# Solução de problemas AWS CodePipeline de identidade e acesso
Use as informações a seguir para ajudá-lo a diagnosticar e corrigir problemas comuns que você pode encontrar ao trabalhar com CodePipeline um IAM.
**Topics**
+ [Não estou autorizado a realizar uma ação em CodePipeline](#security_iam_troubleshoot-no-permissions)
+ [Não estou autorizado a realizar iam: PassRole](#security_iam_troubleshoot-passrole)
+ [Sou administrador e quero permitir que outras pessoas acessem CodePipeline](#security_iam_troubleshoot-admin-delegate)
+ [Quero permitir que pessoas fora da minha AWS conta acessem meus CodePipeline recursos](#security_iam_troubleshoot-cross-account-access)
## Não estou autorizado a realizar uma ação em CodePipeline
Se o Console de gerenciamento da AWS indicar que você não está autorizado a realizar uma ação, entre em contato com o administrador para obter ajuda. O administrador é a pessoa que forneceu a você o seu nome de usuário e senha.
O erro de exemplo a seguir ocorre quando o usuário `mateojackson` do IAM tenta usar o console para visualizar detalhes sobre um pipeline, mas não tem permissões `codepipeline:GetPipeline`.
```
User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: codepipeline:GetPipeline on resource: my-pipeline
```
Neste caso, Mateo pede ao administrador para atualizar suas políticas para permitir a ele o acesso ao recurso `my-pipeline` usando a ação `codepipeline:GetPipeline`.
## Não estou autorizado a realizar iam: PassRole
Se você receber uma mensagem de erro informando que você não está autorizado a executar a ação `iam:PassRole`, entre em contato com o administrador para obter assistência. O administrador é a pessoa que forneceu a você o seu nome de usuário e senha. Peça a essa pessoa para atualizar suas políticas para permitir que você passe uma função para o CodePipeline.
Alguns Serviços da AWS permitem que você passe uma função existente para esse serviço, em vez de criar uma nova função de serviço ou uma função vinculada ao serviço. Para fazer isso, é preciso ter permissões para passar o perfil para o serviço.
O exemplo de erro a seguir ocorre quando uma usuária do IAM chamada `marymajor` tenta utilizar o console para executar uma ação no CodePipeline. No entanto, a ação exige que o serviço tenha permissões concedidas por um perfil de serviço. Mary não tem permissões para passar a função para o serviço.
```
User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole
```
Neste caso, Mary pede ao administrador para atualizar suas políticas para permitir que ela execute a ação `iam:PassRole`.
## Sou administrador e quero permitir que outras pessoas acessem CodePipeline
Para permitir que outras pessoas acessem CodePipeline, você deve conceder permissão às pessoas ou aplicativos que precisam de acesso. Se você estiver usando o Centro de Identidade do AWS IAM para gerenciar pessoas e aplicações, atribua conjuntos de permissões a usuários ou grupos para definir o nível de acesso. Os conjuntos de permissões criam e atribuem automaticamente políticas do IAM aos perfis do IAM associados à pessoa ou aplicação. Para ter mais informações, consulte [Conjuntos de permissões](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html) no *Guia do usuário do Centro de Identidade do AWS IAM *.
Se você não estiver usando o Centro de Identidade do IAM, deverá criar entidades do IAM (usuários ou perfis) para as pessoas ou aplicações que precisam de acesso. Você deve anexar uma política à entidade que concede a eles as permissões corretas no CodePipeline. Depois que as permissões forem concedidas, forneça as credenciais ao usuário ou desenvolvedor da aplicação. Eles usarão essas credenciais para acessar AWS. Para saber mais sobre como criar grupos, políticas, permissões e usuários do IAM, consulte [Identidades do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html) e [Políticas e permissões no IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) no *Guia do usuário do IAM*.
## Quero permitir que pessoas fora da minha AWS conta acessem meus CodePipeline recursos
É possível criar um perfil que os usuários de outras contas ou pessoas fora da organização podem usar para acessar seus recursos. É possível especificar quem é confiável para assumir o perfil. Para serviços que oferecem suporte a políticas baseadas em recursos ou listas de controle de acesso (ACLs), você pode usar essas políticas para conceder às pessoas acesso aos seus recursos.
Para saber mais, consulte:
+ Para saber se é CodePipeline compatível com esses recursos, consulte[Como AWS CodePipeline funciona com o IAM](security_iam_service-with-iam.md).
+ Para saber como fornecer acesso aos seus recursos em todos os Contas da AWS que você possui, consulte Como [fornecer acesso a um usuário do IAM em outro Conta da AWS que você possui](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html) no *Guia do usuário do IAM*.
+ Para saber como fornecer acesso aos seus recursos a terceiros Contas da AWS, consulte Como [fornecer acesso Contas da AWS a terceiros](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html) no *Guia do usuário do IAM*.
+ Para saber como conceder acesso por meio da federação de identidades, consulte [Conceder acesso a usuários autenticados externamente (federação de identidades)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html) no *Guia do usuário do IAM*.
+ Para saber a diferença entre perfis e políticas baseadas em recurso para acesso entre contas, consulte [Acesso a recursos entre contas no IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) no *Guia do usuário do IAM*.
# referência de permissões
Use a tabela a seguir como referência ao configurar o controle de acesso e escrever políticas de permissões que você pode anexar a uma identidade do IAM (políticas baseadas em identidade). A tabela lista cada operação da API do e as ações correspondentes para as quais você pode conceder permissões para executar a ação. Para operações que oferecem suporte a *permissões em nível de recurso*, a tabela lista o AWS recurso para o qual você pode conceder as permissões. Você especifica as ações no campo `Action` das políticas.
*Permissões em nível de recurso* são aquelas que permitem especificar em quais recursos os usuários podem realizar ações. AWS CodePipeline fornece suporte parcial para permissões em nível de recurso. Isso significa que, para algumas chamadas de AWS CodePipeline API, você pode controlar quando os usuários podem usar essas ações com base nas condições que devem ser atendidas ou nos recursos que os usuários podem usar. Por exemplo, você pode conceder permissões a usuários para listar as informações de execução de pipelines, mas apenas para um pipeline ou pipelines específicos.
**nota**
A coluna **Resources (Recursos)** lista o recurso necessário para chamadas de API que oferecem suporte a permissões no nível do recurso. Para chamadas de API que não oferecem suporte a permissões no nível do recurso, é possível conceder aos usuários permissão para usá-las, mas é necessário especificar um curinga (\$1) para o elemento de recurso da declaração de política.
**Operações de API e permissões necessárias para ações**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/codepipeline/latest/userguide/permissions-reference.html)
# Gerenciar a função CodePipeline de serviço
A função de serviço é configurada com uma ou mais políticas que controlam o acesso aos AWS recursos usados pelo pipeline. Talvez você queira anexar mais políticas a essa função, editar a política anexada à função ou configurar políticas para outras funções de serviço em AWS. Pode ser que você também queira anexar uma política a uma função ao configurar o acesso entre contas ao pipeline.
**Importante**
Alterar uma declaração de política ou anexar outra política à função pode impedir o funcionamento dos pipelines. Compreenda as implicações antes de alterar de alguma maneira a função de serviço do . Teste os pipelines após ter feito alterações na função de serviço.
**nota**
No console, as funções de serviço criadas antes de setembro de 2018 são criadas com o nome `oneClick_AWS-CodePipeline-Service_ID-Number`.
As funções de serviço criadas após setembro de 2018 usam o formato de nome da função de serviço `AWSCodePipelineServiceRole-Region-Pipeline_Name`. Por exemplo, para um pipeline chamado `MyFirstPipeline` na `eu-west-2`, o console nomeia a função e a política como `AWSCodePipelineServiceRole-eu-west-2-MyFirstPipeline`.
## CodePipeline política de função de serviço
A declaração de política da função de CodePipeline serviço contém as permissões mínimas para gerenciar pipelines. Você pode editar a declaração do perfil de serviço para remover ou adicionar o acesso aos recursos que você não usa. Consulte a referência de ação apropriada para ver os CodePipeline usos mínimos de permissões necessárias para cada ação.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowS3BucketAccess",
"Effect": "Allow",
"Action": [
"s3:GetBucketVersioning",
"s3:GetBucketAcl",
"s3:GetBucketLocation"
],
"Resource": [
"arn:aws:s3:::[[pipeArtifactBucketNames]]"
],
"Condition": {
"StringEquals": {
"aws:ResourceAccount": "{{accountId}}"
}
}
},
{
"Sid": "AllowS3ObjectAccess",
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:PutObjectAcl",
"s3:GetObject",
"s3:GetObjectVersion",
"s3:PutObjectTagging",
"s3:GetObjectTagging",
"s3:GetObjectVersionTagging"
],
"Resource": [
"arn:aws:s3:::[[pipeArtifactBucketNames]]/*"
],
"Condition": {
"StringEquals": {
"aws:ResourceAccount": "{{accountId}}"
}
}
}
]
}
```
------
**nota**
Na política, as seguintes permissões são necessárias quando os objetos do S3 no bucket de origem têm tags:
```
s3:PutObjectTagging
s3:GetObjectTagging
s3:GetObjectVersionTagging
```
## Remover permissões da função CodePipeline de serviço
Você pode editar a declaração da função de serviço para remover o acesso aos recursos que você não utiliza. Por exemplo, se nenhum dos pipelines incluir o Elastic Beanstalk, você poderá editar a declaração de política para remover a seção que concede acesso aos recursos do Elastic Beanstalk.
Da mesma forma, se nenhum de seus pipelines incluir CodeDeploy, você poderá editar a declaração de política para remover a seção que concede acesso aos CodeDeploy recursos:
```
{
"Action": [
"codedeploy:CreateDeployment",
"codedeploy:GetApplicationRevision",
"codedeploy:GetDeployment",
"codedeploy:GetDeploymentConfig",
"codedeploy:RegisterApplicationRevision"
],
"Resource": "*",
"Effect": "Allow"
},
```
## Adicionar permissões à função CodePipeline de serviço
Você deve atualizar a declaração de política do perfil de serviço com permissões para um AWS service (Serviço da AWS) ainda não incluído na declaração de política de perfil de serviço padrão para que possa usá-la nos pipelines.
Isso é especialmente importante se a função de serviço que você usa para seus pipelines foi criada antes da adição do suporte para um AWS service (Serviço da AWS).
A tabela a seguir mostra quando o suporte foi adicionado para outros Serviços da AWS.
****
| AWS service (Serviço da AWS) | CodePipeline data de suporte |
| --- | --- |
| CodePipeline suporte de ação de invocação adicionado. Consulte [Permissões da política de função de serviço para a CodePipeline ação de invocação](action-reference-PipelineInvoke.md#action-reference-PipelineInvoke-permissions-action). | 14 de março de 2025 |
| Suporte à ação do EC2 adicionado. Consulte [Permissões de política do perfil de serviço para a ação de implantação do EC2](action-reference-EC2Deploy.md#action-reference-EC2Deploy-permissions-action). | 21 de fevereiro de 2025 |
| Suporte à ação do EKS adicionado. Consulte [Permissões de política de perfil de serviço](action-reference-EKS.md#action-reference-EKS-service-role). | 20 de fevereiro de 2025 |
| Suporte à ação ECRBuildAndPublish ação do Amazon Elastic Container Registry adicionado. Consulte [Permissões do perfil de serviço: ação `ECRBuildAndPublish`](action-reference-ECRBuildAndPublish.md#edit-role-ECRBuildAndPublish). | 22 de novembro de 2024 |
| Suporte à ação InspectorScan do Amazon Inspector adicionado. Consulte [Permissões do perfil de serviço: ação `InspectorScan`](action-reference-InspectorScan.md#edit-role-InspectorScan). | 22 de novembro de 2024 |
| Suporte à ação de comandos adicionado. Consulte [Permissões do perfil de serviço: ação Comandos](action-reference-Commands.md#edit-role-Commands). | 3 de outubro de 2024 |
| CloudFormation suporte de ação adicionado. Consulte [Permissões do perfil de serviço: ação `CloudFormationStackSet`](action-reference-StackSets.md#edit-role-cfn-stackset) e [Permissões do perfil de serviço: ação `CloudFormationStackInstances`](action-reference-StackSets.md#edit-role-cfn-stackinstances). | 30 de dezembro de 2020 |
| CodeCommit suporte de ação de formato de artefato de saída de clone completo adicionado. Consulte [Permissões da função de serviço: CodeCommit ação](action-reference-CodeCommit.md#edit-role-codecommit). | 11 de novembro de 2020 |
| AWS CodeBuild suporte de ação de compilações em lote adicionado. Consulte [Permissões da função de serviço: CodeCommit ação](action-reference-CodeCommit.md#edit-role-codecommit). | 30 de julho de 2020 |
| AWS AppConfig suporte de ação adicionado. Consulte [Permissões do perfil de serviço: ação `AppConfig`](action-reference-AppConfig.md#edit-role-appconfig). | 22 de junho de 2020 |
| AWS Step Functions suporte de ação adicionado. Consulte [Permissões do perfil de serviço: ação `StepFunctions`](action-reference-StepFunctions.md#edit-role-stepfunctions). | 27 de maio de 2020 |
| AWS CodeStar Suporte de ação de conexões adicionado. Consulte [Permissões da função de serviço: CodeConnections ação](action-reference-CodestarConnectionSource.md#edit-role-connections). | 18 de dezembro de 2019 |
| Suporte à ação de implantação do S3 adicionado. Consulte [Permissões do perfil de serviço: ação de implantação do S3](action-reference-S3Deploy.md#edit-role-s3deploy). | 16 de janeiro de 2019 |
| O suporte à ação CodeDeployToECS foi adicionado. Consulte [Permissões do perfil de serviço: ação `CodeDeployToECS`](action-reference-ECSbluegreen.md#edit-role-codedeploy-ecs). | 27 de novembro de 2018 |
| Suporte à ação do Amazon ECR adicionado. Consulte [Permissões do perfil de serviço: ação do Amazon ECR](action-reference-ECR.md#edit-role-ecr). | 27 de novembro de 2018 |
| Suporte à ação do Service Catalog adicionado. Consulte [Permissões do perfil de serviço: ação do Service Catalog](action-reference-ServiceCatalog.md#edit-role-servicecatalog). | 16 de outubro de 2018 |
| AWS Device Farm suporte de ação adicionado. Consulte [Permissões da função de serviço: AWS Device Farm ação](action-reference-DeviceFarm.md#edit-role-devicefarm). | 19 de julho de 2018 |
| Suporte à ação do Amazon ECS adicionado. Consulte [Permissões do perfil de serviço: ação padrão do Amazon ECS](action-reference-ECS.md#edit-role-ecs). | 12 de dezembro de 2017//Atualização para aceitar a autorização de marcação em 21 de julho de 2017 |
| CodeCommit suporte de ação adicionado. Consulte [Permissões da função de serviço: CodeCommit ação](action-reference-CodeCommit.md#edit-role-codecommit). | 18 de abril de 2016 |
| AWS OpsWorks suporte de ação adicionado. Consulte [Permissões da função de serviço: AWS OpsWorks ação](action-reference-OpsWorks.md#edit-role-opsworks). | 2 de junho de 2016 |
| CloudFormation suporte de ação adicionado. Consulte [Permissões da função de serviço: CloudFormation ação](action-reference-CloudFormation.md#edit-role-cloudformation). | 3 de novembro de 2016 |
| AWS CodeBuild suporte de ação adicionado. Consulte [Permissões da função de serviço: CodeBuild ação](action-reference-CodeBuild.md#edit-role-codebuild). | 1º de dezembro de 2016 |
| Suporte à ação do Elastic Beanstalk adicionado. Consulte [Permissões do perfil de serviço: ação de implantação do `ElasticBeanstalk`](action-reference-Beanstalk.md#edit-role-beanstalk). | Lançamento do serviço inicial |
| CodeDeploy suporte de ação adicionado. Consulte [Permissões da função de serviço: AWS CodeDeploy ação](action-reference-CodeDeploy.md#edit-role-codedeploy). | Lançamento do serviço inicial |
| Suporte à ação de origem do S3 adicionado. Consulte [Permissões do perfil de serviço: ação de origem do S3](action-reference-S3.md#edit-role-s3source). | Lançamento do serviço inicial |
Siga estes passos para adicionar permissões para um serviço compatível:
1. Faça login no Console de gerenciamento da AWS e abra o console do IAM em [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. No console do IAM, no painel de navegação, escolha **Perfis** e, em seguida, escolha o perfil `AWS-CodePipeline-Service` na lista de perfis.
1. Na guia **Permissões**, em **Políticas em linha**, na linha da sua política de perfil de serviço, escolha **Editar política**.
1. Adicione as permissões necessárias na caixa **Documento da política**.
**nota**
Ao criar políticas do IAM, siga as dicas de segurança padrão de concessão de privilégio mínimo, ou seja, conceda apenas as permissões necessárias à execução de uma tarefa. Determinadas chamadas de API são compatíveis com permissões baseadas em recursos e permitem que o acesso seja limitado. Por exemplo, neste caso, para limitar as permissões quando chamar `DescribeTasks` e `ListTasks`, você pode substituir o caractere curinga (\$1) por um ARN de recurso ou um ARN de recurso que contenha um caractere curinga (\$1). Para obter mais informações sobre a criação de uma política que conceda acesso com privilégios mínimos, consulte [https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege).
1. Selecione **Review policy (Revisar política)** para garantir que a política não contenha erros. Quando a política não tiver erros, selecione **Aplicar política**.
# Registro e monitoramento em CodePipeline
Você pode usar os recursos de login AWS para determinar as ações que os usuários realizaram em sua conta e os recursos que foram usados. Os arquivos de log mostram:
+ A data e hora das ações.
+ O endereço IP de origem de uma ação.
+ As ações que falharam devido a permissões inadequadas.
Os atributos de registro em log estão disponíveis nos seguintes Serviços da AWS:
+ AWS CloudTrail pode ser usado para registrar chamadas de AWS API e eventos relacionados feitos por ou em nome de um Conta da AWS. Para obter mais informações, consulte [Registrando chamadas de CodePipeline API com AWS CloudTrail](monitoring-cloudtrail-logs.md).
+ O Amazon CloudWatch Events pode ser usado para monitorar seus Nuvem AWS recursos e os aplicativos em que você executa AWS. Você pode criar alertas no Amazon CloudWatch Events com base nas métricas que você define. Para obter mais informações, consulte [Monitoramento de CodePipeline eventos](detect-state-changes-cloudwatch-events.md).
# Validação de conformidade para AWS CodePipeline
Para saber se um AWS service (Serviço da AWS) está dentro do escopo de programas de conformidade específicos, consulte [Serviços da AWS Escopo por Programa de Conformidade Serviços da AWS](https://aws.amazon.com/compliance/services-in-scope/) e escolha o programa de conformidade em que você está interessado. Para obter informações gerais, consulte Programas de [AWS conformidade Programas AWS](https://aws.amazon.com/compliance/programs/) de .
Você pode baixar relatórios de auditoria de terceiros usando artefatos. Para obter mais informações, consulte [Baixar relatórios em AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html) .
Sua responsabilidade de conformidade ao usar Serviços da AWS é determinada pela confidencialidade de seus dados, pelos objetivos de conformidade de sua empresa e pelas leis e regulamentações aplicáveis. Para obter mais informações sobre sua responsabilidade de conformidade ao usar Serviços da AWS, consulte a [Documentação AWS de segurança](https://docs.aws.amazon.com/security/).
# Resiliência em AWS CodePipeline
A infraestrutura AWS global é construída em torno de AWS regiões e zonas de disponibilidade. AWS As regiões fornecem várias zonas de disponibilidade fisicamente separadas e isoladas, conectadas a redes de baixa latência, alta taxa de transferência e alta redundância. Com as zonas de disponibilidade, é possível projetar e operar aplicações e bancos de dados que automaticamente executam o failover entre as zonas sem interrupção. As zonas de disponibilidade são altamente disponíveis, tolerantes a falhas e escaláveis que uma ou várias infraestruturas de data center tradicionais.
Para obter mais informações sobre AWS regiões e zonas de disponibilidade, consulte [Infraestrutura AWS global](https://aws.amazon.com/about-aws/global-infrastructure/).
# Segurança da infraestrutura em AWS CodePipeline
Como serviço gerenciado, AWS CodePipeline é protegido pela segurança de rede AWS global. Para obter informações sobre serviços AWS de segurança e como AWS proteger a infraestrutura, consulte [AWS Cloud Security](https://aws.amazon.com/security/). Para projetar seu AWS ambiente usando as melhores práticas de segurança de infraestrutura, consulte [Proteção](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html) de infraestrutura no *Security Pillar AWS Well‐Architected* Framework.
Você usa chamadas de API AWS publicadas para acessar CodePipeline pela rede. Os clientes devem oferecer compatibilidade com:
+ Transport Layer Security (TLS). Exigimos TLS 1.2 e recomendamos TLS 1.3.
+ Conjuntos de criptografia com perfect forward secrecy (PFS) como DHE (Ephemeral Diffie-Hellman) ou ECDHE (Ephemeral Elliptic Curve Diffie-Hellman). A maioria dos sistemas modernos, como Java 7 e versões posteriores, comporta esses modos.
# Práticas recomendadas de segurança
**Topics**
CodePipeline fornece vários recursos de segurança a serem considerados ao desenvolver e implementar suas próprias políticas de segurança. As práticas recomendadas a seguir são diretrizes gerais e não representam uma solução completa de segurança. Como essas práticas recomendadas podem não ser adequadas ou suficientes para o seu ambiente, trate-as como considerações úteis em vez de prescrições.
Você usa criptografia e autenticação para os repositórios de origem que se conectam a seus pipelines. Estas são as CodePipeline melhores práticas de segurança:
+ Se você criar uma configuração de pipeline ou ação que precise incluir segredos, como tokens ou senhas, não insira segredos diretamente na configuração da ação ou nos valores padrão das variáveis definidas no nível do pipeline ou na configuração do CloudFormation , pois as informações serão exibidas nos logs. Use o Secrets Manager para configurar e armazenar segredos e, em seguida, use o segredo referenciado na configuração do pipeline e da ação, conforme descrito em [Use AWS Secrets Manager para rastrear senhas de bancos de dados ou chaves de API de terceiros](parameter-store-encryption.md).
+ Se você criar um pipeline que usa um bucket de origem do S3, configure a criptografia do lado do servidor para artefatos armazenados no Amazon S3 por CodePipeline meio do gerenciamento, conforme descrito em. AWS KMS keys[Configure a criptografia do lado do servidor para artefatos armazenados no Amazon S3 para CodePipeline](S3-artifact-encryption.md)
+ Se estiver usando um provedor de ação do Jenkins, ao usar um provedor de compilação do Jenkins para a ação de teste ou compilação do pipeline, instale o Jenkins em uma instância do EC2 e configure um perfil de instância do EC2 separado. Certifique-se de que o perfil da instância conceda ao Jenkins somente as AWS permissões necessárias para realizar tarefas para seu projeto, como recuperar arquivos do Amazon S3. Para saber como criar a função para o seu perfil de instância do Jenkins, consulte as etapas em [Criar um perfil do IAM a ser usado na integração do Jenkins](tutorials-four-stage-pipeline.md#tutorials-four-stage-pipeline-prerequisites-jenkins-iam-role).