Partilhar via

Novas políticas para tokens de acesso pessoal

  • Artigo

Neste sprint, adicionámos novas políticas para restringir o âmbito e o tempo de vida dos tokens de acesso pessoal (PAT). Além disso, atualizámos a extensão do Team Foundation Version Control (TFVC) do Windows Shell para suportar o Visual Studio 2019.

Consulte as seguintes descrições de funcionalidades para obter detalhes.

Geral

Pipelines do Azure

Repositórios do Azure

Geral

Restringir o âmbito e o tempo de vida do token de acesso pessoal (PAT) através da política de inquilino Azure AD

Os tokens de acesso pessoal (PATs) facilitam a autenticação no Azure DevOps para integração com as suas ferramentas e serviços. No entanto, os tokens vazados podem comprometer a sua conta e dados do Azure DevOps, colocando as suas aplicações e serviços em risco.

Recebemos comentários sobre administradores que não têm os controlos necessários para limitar a área de superfície de ameaças colocada por PATs vazados. Com base nestes comentários, adicionámos um novo conjunto de políticas que podem ser utilizadas para restringir o âmbito e o tempo de vida dos tokens de acesso pessoal (PATs) do Azure DevOps da sua organização! Eis como funcionam:

Os utilizadores atribuídos à função de Administrador do Azure DevOps no Azure Active Directory podem navegar para o separador Azure Active Directory nas definições da organização de qualquer organização do Azure DevOps ligada ao respetivo Azure AD.

Controlos PAT de imagem

Aí, os administradores podem:

  1. restringir a criação de tokens de acesso pessoal globais (tokens que funcionam para todas as organizações Azure DevOps acessíveis pelo utilizador)
  2. restringir a criação de tokens de acesso pessoal de âmbito total
  3. definir uma validade máxima para os novos tokens de acesso pessoal

Estas políticas serão aplicadas a todos os novos PATs criados pelos utilizadores para organizações do Azure DevOps ligadas ao inquilino Azure AD. Cada uma das políticas tem uma lista de permissões para utilizadores e grupos que devem ser excluídos da política. A lista de utilizadores e grupos na lista Permitir não terá acesso para gerir a configuração da política.

Estas políticas só se aplicam aos novos tokens de acesso pessoal e não afetarão os tokens de acesso pessoal existentes que já tenham sido criados e que estejam a ser utilizados. No entanto, após a ativação das políticas, todos os PATs existentes e agora não conformes têm de ser atualizados para estarem dentro das restrições antes de poderem ser renovados.

Suporte de política de acesso condicional para tráfego IPv6

Estamos agora a alargar o suporte da política de acesso condicional (CAP) para incluir políticas de esgrima IPv6. À medida que vemos que as pessoas acedem cada vez mais aos recursos do Azure DevOps em dispositivos a partir de endereços IPv6, queremos garantir que as suas equipas estão equipadas para conceder e remover acesso de qualquer endereço IP, incluindo os provenientes do tráfego IPv6.

Pipelines do Azure

Reter pipelines consumidos noutros pipelines

As versões clássicas tinham a capacidade de reter automaticamente as compilações que consomem. Esta foi uma das lacunas entre os lançamentos clássicos e os pipelines YAML e impediu que alguns de vocês se deslocassem para o YAML. Com esta versão, resolvemos esta lacuna.

Agora, pode criar um pipeline YAML de várias fases para representar a sua versão e consumir outro pipeline YAML no mesmo como um recurso. Quando o fizer, os Pipelines do Azure irão reter automaticamente o pipeline de recursos, desde que o pipeline de versão seja mantido. Quando o pipeline de versão é eliminado, a concessão no pipeline de recursos é lançada e as suas próprias políticas de retenção são seguidas.

Alterações na criação automática de ambientes

Quando cria um pipeline YAML e se refere a um ambiente que não existe, o Azure Pipelines cria automaticamente o ambiente. Esta criação automática pode ocorrer no contexto do utilizador ou no contexto do sistema. Nos seguintes fluxos, o Azure Pipelines sabe sobre o utilizador que está a executar a operação:

  • Quando utiliza o assistente de criação de pipelines YAML na experiência Web do Azure Pipelines e referencia um ambiente que ainda não foi criado.
  • Quando atualiza o ficheiro YAML com o editor Web do Azure Pipelines e guarda o pipeline depois de adicionar uma referência a um ambiente que não existe.

Em cada um dos casos acima, o Azure Pipelines tem uma compreensão clara do utilizador que executa a operação. Assim, cria o ambiente e adiciona o utilizador à função de administrador do ambiente. Este utilizador tem todas as permissões para gerir o ambiente e/ou para incluir outros utilizadores em várias funções para gerir o ambiente.

Nos seguintes fluxos, o Azure Pipelines não tem informações sobre o utilizador que está a criar o ambiente: o utilizador atualiza o ficheiro YAML com outro editor de código externo, adiciona uma referência a um ambiente que não existe e, em seguida, faz com que seja acionado um pipeline de integração manual ou contínua. Neste caso, o Azure Pipelines não conhece o utilizador. Anteriormente, para lidar com este caso, adicionávamos todos os contribuidores do projeto à função de administrador do ambiente. Desta forma, qualquer membro do projeto podia alterar estas permissões e impedir que outras pessoas acedessem ao ambiente.

Recebemos o seu feedback sobre a concessão de permissões de administrador num ambiente a todos os membros de um projeto. À medida que ouvimos os seus comentários, ouvimos dizer que não devemos criar automaticamente um ambiente se não for claro quem é o utilizador que está a executar a operação. Com esta versão, fizemos alterações à forma como os ambientes serão criados automaticamente:

  • No futuro, as execuções de pipeline não criarão automaticamente um ambiente se não existir e se o contexto do utilizador não for conhecido. Nestes casos, o pipeline falhará com um erro Ambiente não encontrado. Tem de pré-criar os ambientes com a segurança correta e verificar a configuração antes de o utilizar num pipeline.
  • Os pipelines com contexto de utilizador conhecido continuarão a criar automaticamente ambientes, tal como fizeram no passado.
  • Por fim, deve observar-se que a funcionalidade para criar automaticamente um ambiente só foi adicionada para simplificar o processo de introdução aos Pipelines do Azure. Destina-se a cenários de teste e não a cenários de produção. Deve sempre pré-criar ambientes de produção com as permissões e verificações certas e, em seguida, utilizá-los em pipelines.

Remover o diálogo informações do Pipeline de Compilação

Com base nos seus comentários, a caixa de diálogo informações de tarefa/pipeline que é apresentada ao navegar no Pipeline de Compilação foi removida para melhorar o fluxo de trabalho. A análise de pipelines ainda está disponível para que tenha as informações de que precisa.

Repositórios do Azure

Atualizações para a extensão do Windows Shell do Controlo de Versões do Team Foundation (TFVC) para Visual Studio 2019

A versão anterior da extensão TFVC do Windows Shell só funcionava em computadores com o Visual Studio 2017 instalado.

Lançámos uma nova versão desta ferramenta compatível com o Visual Studio 2019. A extensão fornece integração com o Explorador do Windows e as caixas de diálogo de ficheiro comuns. Com esta integração, pode realizar muitas operações de controlo de origem sem ter de executar o Visual Studio ou uma ferramenta de linha de comandos do Team Foundation.

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.

Aceda ao Azure DevOps

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.

Fazer uma sugestão

Também pode obter conselhos e as suas perguntas respondidas pela comunidade no Stack Overflow.

Obrigado,

Vijay Machiraju