Gestão de segurança melhorada
Com esta atualização, tem agora a opção de ativar ou desativar a Segurança Avançada para todo o projeto ou organização. Também pode ativar automaticamente a Segurança Avançada para quaisquer repositórios ou projetos criados recentemente.
Nos Pipelines do Azure, adicionámos um controlo centralizado para melhorar a segurança dos pedidos Pull criados a partir de repositórios do GitHub bifurcados.
Consulte as notas de versão para saber mais sobre estas funcionalidades.
Geral
Ativação ao nível do projeto e da organização para a Segurança Avançada
Contagem estimada de consolidações durante a ativação da Segurança Avançada
Pipelines do Azure
Repetir uma fase em que as aprovações e verificam o tempo limite
Controlo centralizado para a criação de PRs a partir de repositórios do GitHub bifurcados
Repositórios do Azure
Artefactos do Azure
Geral
Ativação ao nível do projeto e da organização para a Segurança Avançada
Agora, pode ativar ou desativar a Segurança Avançada para todo o projeto ou organização. Em conjunto com a nova adição da apresentação da contagem de consolidadores antes da ativação, selecionar "Ativar tudo" ao nível do projeto ou da organização irá fornecer-lhe uma estimativa de quantos novos consolidadores ativos podem ser faturados. Também pode optar por ativar automaticamente a Segurança Avançada para quaisquer repositórios ou projetos recentemente criados no âmbito do respetivo projeto ou organização. Todos os repositórios ativados através desta definição terão a análise secreta do repositório e a proteção push ativa.
Ativação ao nível do projeto:
Ativação ao nível da organização:
Contagem estimada de consolidações durante a ativação da Segurança Avançada
Como parte da sua experiência de integração de Segurança Avançada , agora pode ver uma estimativa de quantos consolidadores ativos podem ter sido adicionados como resultado da ativação da Segurança Avançada para um repositório, projeto ou organização específico. Esta contagem é uma aproximação e poderá ver ligeiras discrepâncias entre a estimativa fornecida e o que é comunicado para faturação após a ativação. Esta estimativa também pode ser obtida através da API com documentação adicional que explica este processo em breve.
Pipelines do Azure
Repetir uma fase em que as aprovações e verificam o tempo limite
Quando as aprovações e verificam o tempo limite, a fase à qual pertencem é ignorada. As fases que têm uma dependência na fase ignorada também são ignoradas.
Agora, pode repetir uma fase em que as aprovações e verificam o tempo limite. Anteriormente, tal só era possível quando uma aprovação excedeu o limite de tempo.
Função de administrador para todos os Ambientes
Os ambientes em pipelines YAML representam um recurso de computação no qual implementa a sua aplicação, por exemplo, um cluster do AKS ou um conjunto de VMs. Fornecem-lhe controlos de segurança e rastreabilidade para as suas implementações.
Gerir ambientes pode ser bastante desafiante. Isto acontece porque, quando um ambiente é criado, a pessoa que o cria torna-se automaticamente o único administrador. Por exemplo, se quiser gerir as aprovações e verificações de todos os ambientes de forma centralizada, terá de pedir a todos os administradores de ambiente que adicionem um utilizador ou grupo específico como administrador e, em seguida, utilize a API REST para configurar as verificações. Esta abordagem é aborrecida, propensa a erros e não dimensiona quando são adicionados novos ambientes.
Com este sprint, adicionámos uma função de Administrador ao nível do hub de ambientes. Isto coloca os ambientes em paridade com ligações de serviço ou conjuntos de agentes. Para atribuir a função de Administrador a um utilizador ou grupo, tem de ser já um administrador do hub de ambientes ou proprietário da organização.
Um utilizador com esta função de Administrador pode administrar permissões, gerir, ver e utilizar qualquer ambiente. Isto inclui a abertura de ambientes para todos os pipelines.
Quando concede uma função de Administrador de utilizador ao nível do hub de ambientes, estes tornam-se administradores para todos os ambientes existentes e para quaisquer ambientes futuros.
Controlo centralizado para a criação de PRs a partir de repositórios do GitHub bifurcados
Se criar repositórios públicos a partir do GitHub, tem de considerar a sua posição sobre as compilações de forks. Os forks são especialmente perigosos, uma vez que vêm de fora da sua organização.
Pode melhorar a segurança dos pipelines que criam repositórios públicos do GitHub ao rever as nossas recomendações sobre como Criar repositórios do GitHub e proteção do Repositório. Infelizmente, a gestão de numerosos pipelines e a garantia da sua adesão às melhores práticas podem exigir um esforço substancial.
Para melhorar a segurança dos seus pipelines, adicionámos um controlo ao nível da organização para definir a forma como os pipelines criam PRs a partir de repositórios do GitHub bifurcados. A nova definição chama-se Limitar pedidos Pull de compilação de repositórios do GitHub bifurcados e funciona ao nível da organização e do projeto.
A definição ao nível da organização restringe as definições que os projetos podem ter e a definição ao nível do projeto restringe as definições que os pipelines podem ter.
Vamos ver como funciona o botão de alternar ao nível da organização. O novo controlo está desativado por predefinição, pelo que não são impostas definições universalmente.
Quando ativa o botão de alternar, pode optar por desativar a criação de PRs a partir de repositórios do GitHub bifurcados. Isto significa que nenhum pipeline será executado quando tal PR for criado.
Quando escolhe a opção Criar pedidos Pull de forma segura a partir de repositórios bifurcados , todos os pipelines, em toda a organização, não podem disponibilizar segredos para compilações de PRs a partir de repositórios bifurcados, não podem fazer com que estas compilações tenham as mesmas permissões que as compilações normais e têm de ser acionadas por um comentário de PR. Os projetos ainda podem decidir não permitir que os pipelines criem esses PRs.
Ao escolher a opção Personalizar , pode definir como restringir as definições do pipeline. Por exemplo, pode garantir que todos os pipelines necessitam de um comentário para criar um PR a partir de um repositório do GitHub bifurcado, quando o PR pertence a membros não pertencentes à equipa e não contribuidores. Contudo, pode optar por permitir que disponibilizem segredos para essas compilações. Os projetos podem decidir não permitir que os pipelines criem esses PRs, compilá-los de forma segura ou ter definições ainda mais restritivas que o que é especificado ao nível da organização.
Repositórios do Azure
Nova "Política de ramo" que impede os utilizadores de aprovarem as suas próprias alterações
Para melhorar o controlo sobre as alterações que o utilizador aprova e corresponde a requisitos regulamentares/de conformidade mais rigorosos, fornecemos uma opção para impedir que o utilizador aprove as suas próprias alterações, a menos que seja explicitamente permitido.
O utilizador com capacidade para gerir as políticas de ramo pode agora mudar a opção recentemente adicionada "Exigir pelo menos uma aprovação em cada iteração" em "Quando são enviadas novas alterações". Quando esta opção estiver selecionada, é necessário, pelo menos, um voto de aprovação para a última alteração do ramo de origem. A aprovação do utilizador não é contabilizada em relação a qualquer iteração não aprovada anterior enviada por esse utilizador. Como resultado, a aprovação adicional na última iteração tem de ser efetuada por outro utilizador.
A imagem seguinte mostra o pedido Pull criado pelo utilizador A e 4 consolidações adicionais (iterações) efetuadas a esse pedido Pull pelos utilizadores B, C, A novamente e C. Após a conclusão da segunda iteração (consolidação feita pelo utilizador B), o utilizador C aprovou-a. Nessa altura, implicava a aprovação da primeira consolidação do utilizador A (quando o pedido Pull foi criado) e a política recentemente introduzida terá êxito. Após a quinta iteração (última consolidação do utilizador C), a aprovação foi efetuada pelo utilizador A. Esta aprovação implícita para consolidação anterior feita pelo utilizador C, mas não implicava aprovação para a segunda consolidação feita pelo utilizador A na quarta iteração. Para que a política recentemente introduzida seja bem-sucedida, a iteração não aprovada quatro tem de ser aprovada através da aprovação do utilizador B, C ou de qualquer outro utilizador que não tenha feito qualquer alteração ao pedido Pull.
Artefactos do Azure
Introdução ao suporte dos Artefactos do Azure para Caixas de Carga (pré-visualização pública)
Estamos entusiasmados por anunciar que os Artefactos do Azure oferecem agora suporte nativo para caixas de carga. Este suporte inclui paridade de funcionalidades relativamente aos nossos protocolos existentes, além de crates.io estar disponível como uma origem a montante. Os programadores e equipas rust podem agora consumir, publicar, gerir e partilhar as respetivas Caixas de carga de forma totalmente integrada, tudo ao mesmo tempo que utilizam a infraestrutura robusta do Azure e permanecem no ambiente familiar do Azure DevOps.
Não é necessária qualquer inscrição para a pré-visualização; Pode começar por navegar para o seu projeto do Azure DevOps, selecionar Artefactos e seguir as instruções para ligar o projeto Rust ao seu feed de Artefactos do Azure.
Passos seguintes
Nota
Estas funcionalidades serão implementadas nas próximas duas a três semanas.
Aceda ao Azure DevOps e dê uma vista de olhos.
Como fornecer comentários
Gostaríamos de ouvir o que pensa sobre estas funcionalidades. Utilize o menu de ajuda para comunicar um problema ou fornecer uma sugestão.
Também pode obter conselhos e as suas perguntas respondidas pela comunidade no Stack Overflow.
Obrigado,
Silviu Andrica