Gerenciamento de segurança aprimorado
Com essa atualização, agora você tem a opção de habilitar ou desabilitar a Segurança Avançada para todo o projeto ou organização. Você também pode habilitar automaticamente a Segurança Avançada para quaisquer repositórios ou projetos recém-criados.
No Azure Pipelines, adicionamos um controle centralizado para melhorar a segurança de solicitações de pull criadas a partir de repositórios GitHub bifurcados.
Confira as notas sobre a versão para saber mais sobre esses recursos.
Geral
Habilitação no nível do projeto e da organização para Segurança Avançada
Contagem estimada de committer durante a habilitação de Segurança Avançada
Azure Pipelines
Repetir um estágio quando aprovações e verificações atingirem o tempo limite
Controle centralizado para a criação de PRs de repositórios github bifurcar
Azure Repos
Azure Artifacts
Geral
Habilitação no nível do projeto e da organização para Segurança Avançada
Agora você pode habilitar ou desabilitar a Segurança Avançada para todo o seu projeto ou organização. Em conjunto com a nova adição de exibição da contagem de committer antes da habilitação, selecionar "Habilitar tudo" no projeto ou no nível da organização fornecerá uma estimativa de quantos novos committers ativos você pode ser cobrado. Você também pode optar por habilitar automaticamente a Segurança Avançada para quaisquer repositórios ou projetos recém-criados em seu respectivo projeto ou organização. Todos os repositórios habilitados por meio dessa configuração terão a verificação do repositório secreto e a proteção por push ativada.
Habilitação no nível do projeto:
Habilitação no nível da organização:
Contagem estimada de committer durante a habilitação de Segurança Avançada
Como parte de sua experiência de integração de Segurança Avançada , agora você pode ver uma estimativa de quantos committers ativos podem ter sido adicionados como resultado da habilitação da Segurança Avançada para um repositório, projeto ou organização específico. Essa contagem é uma aproximação e você pode ver pequenas discrepâncias entre a estimativa fornecida e o que é relatado para cobrança após a habilitação. Essa estimativa também pode ser obtida por meio da API com documentação adicional explicando esse processo em breve.
Azure Pipelines
Repetir um estágio quando aprovações e verificações atingirem o tempo limite
Quando aprovações e verificações atingirem o tempo limite, o estágio ao qual pertencem é ignorado. Estágios que têm uma dependência no estágio ignorado também são ignorados.
Agora você pode repetir um estágio quando aprovações e verifica o tempo limite. Anteriormente, isso só era possível quando uma aprovação atingia o tempo limite.
Função de administrador para todos os Ambientes
Ambientes em pipelines YAML representam um recurso de computação no qual você implanta seu aplicativo, por exemplo, um cluster do AKS ou um conjunto de VMs. Eles fornecem controles de segurança e rastreabilidade para suas implantações.
O gerenciamento de ambientes pode ser bastante desafiador. Isso ocorre porque, quando um ambiente é criado, a pessoa que o cria automaticamente se torna o único administrador. Por exemplo, se você quiser gerenciar as aprovações e verificações de todos os ambientes de forma centralizada, precisará pedir a cada administrador de ambiente para adicionar um usuário ou grupo específico como administrador e, em seguida, usar a API REST para configurar as verificações. Essa abordagem é tediosa, propensa a erros e não é dimensionada quando novos ambientes são adicionados.
Com esse sprint, adicionamos uma função administrador no nível de ambientes-hub. Isso faz com que os ambientes se analisem com conexões de serviço ou pools de agentes. Para atribuir a função administrador a um usuário ou grupo, você já precisa ser um administrador de ambientes-hub ou proprietário da organização.
Um usuário com essa função de Administrador pode administrar permissões, gerenciar, exibir e usar qualquer ambiente. Isso inclui a abertura de ambientes para todos os pipelines.
Quando você concede uma função de administrador de usuário no nível de ambientes-hub, eles se tornam administradores para todos os ambientes existentes e para ambientes futuros.
Controle centralizado para a criação de PRs de repositórios github bifurcar
Se você cria repositórios públicos do GitHub, deve considerar sua posição nos builds de bifurcação. Os forks são especialmente perigosos, pois vêm de fora da sua organização.
Você pode melhorar a segurança de pipelines que criam repositórios públicos do GitHub examinando nossas recomendações sobre como criar repositórios github e proteção de repositório. Infelizmente, gerenciar vários pipelines e garantir sua adesão às práticas recomendadas pode exigir uma quantidade substancial de esforço.
Para aprimorar a segurança de seus pipelines, adicionamos um controle no nível da organização para definir como os pipelines criam PRs de repositórios do GitHub bifurcados. A nova configuração é denominada Limitar solicitações de pull de criação de repositórios GitHub bifurcados e funciona no nível da organização e do projeto.
A configuração no nível da organização restringe as configurações que os projetos podem ter e a configuração no nível do projeto restringe as configurações que os pipelines podem ter.
Vamos ver como a alternância funciona no nível da organização. O novo controle está desativado por padrão, portanto, nenhuma configuração é imposta universalmente.
Ao ativar a alternância, você pode optar por desabilitar a criação de PRs de repositórios do GitHub bifurcados. Isso significa que nenhum pipeline será executado quando essa PR for criada.
Quando você escolhe a opção Compilar solicitações de pull com segurança de repositórios bifurcados , todos os pipelines, em toda a organização, não podem disponibilizar segredos para builds de PRs de repositórios bifurcados, não podem fazer com que esses builds tenham as mesmas permissões que os builds normais e devem ser disparados por um comentário de PR. Os projetos ainda podem decidir não permitir que pipelines criem esses PRs.
Ao escolher a opção Personalizar , você pode definir como restringir as configurações de pipeline. Por exemplo, você pode garantir que todos os pipelines exijam um comentário para criar uma PR de um repositório GitHub bifurcado, quando a PR pertence a membros que não são da equipe e não colaboradores. Porém, você pode optar por permitir que eles disponibilizem segredos para tais builds. Os projetos podem decidir não permitir que pipelines criem esses PRs ou compilá-los com segurança ou ter configurações ainda mais restritivas especificadas no nível da organização.
Azure Repos
Nova "política de ramificação" impedindo que os usuários aprovem suas próprias alterações
Para melhorar o controle sobre quais alterações o usuário aprova e corresponde aos requisitos mais rigorosos de regulamentação/conformidade, fornecemos uma opção para impedir que o usuário aprove suas próprias alterações, a menos que seja explicitamente permitido.
O usuário com a capacidade de gerenciar as políticas de branch agora pode alternar a opção recém-adicionada "Exigir pelo menos uma aprovação em cada iteração" em "Quando novas alterações forem enviadas por push". Quando essa opção é selecionada, pelo menos um voto de aprovação para a última alteração do branch de origem é necessário. A aprovação do usuário não é contada em relação a nenhuma iteração não aprovada anterior enviada por push por esse usuário. Como resultado, a aprovação adicional na última iteração é necessária para ser feita por outro usuário.
A imagem a seguir mostra a solicitação de pull criada pelo usuário A e 4 confirmações adicionais (iterações) feitas nessa solicitação de pull pelos usuários B, C, A novamente e C. Depois que a segunda iteração (confirmação feita pelo usuário B) foi feita, o usuário C aprovou isso. Nesse momento, ele insinuou a aprovação do primeiro commit do usuário A (quando a solicitação de pull foi criada) e a política recém-introduzida terá êxito. Após a quinta iteração (última confirmação do usuário C), a aprovação foi feita pelo usuário A. Essa aprovação implícita para confirmação anterior feita pelo usuário C, mas não estava implicando aprovação para o segundo commit feito pelo usuário A na quarta iteração. Para que a política recém-introduzida tenha êxito, a iteração não aprovada quatro deve ser aprovada pela aprovação do usuário B, C ou de qualquer outro usuário que não tenha feito nenhuma alteração na solicitação de pull.
Azure Artifacts
Introdução ao suporte do Azure Artifacts para o Cargo Crates (versão prévia pública)
Estamos felizes em anunciar que o Azure Artifacts agora oferece suporte nativo para caixas de carga. Esse suporte inclui paridade de recursos em relação aos nossos protocolos existentes, além de crates.io estar disponível como uma fonte upstream. Os desenvolvedores e equipes do Rust agora podem consumir, publicar, gerenciar e compartilhar seus crates de carga perfeitamente, tudo isso usando a infraestrutura robusta do Azure e permanecendo no ambiente familiar do Azure DevOps.
Nenhuma inscrição é necessária para a versão prévia; você pode começar navegando até seu projeto do Azure DevOps, selecionando Artefatos e seguindo as instruções para conectar seu projeto rust ao feed do Azure Artifacts.
Próximas etapas
Observação
Esses recursos serão lançados nas próximas duas a três semanas.
Vá até o Azure DevOps e dê uma olhada.
Como fornecer comentários
Adoraríamos ouvir o que você pensa sobre esses recursos. Use o menu de ajuda para relatar um problema ou fornecer uma sugestão.
Você também pode receber conselhos e suas perguntas respondidas pela comunidade no Stack Overflow.
Obrigada,
Silviu Andrica