Novas políticas para tokens de acesso pessoal
Neste sprint, adicionamos novas políticas para restringir o escopo e o tempo de vida dos tokens de acesso pessoal (PAT). Além disso, atualizamos a extensão do Windows Shell do Controle de Versão do Team Foundation (TFVC) para dar suporte ao Visual Studio 2019.
Confira as descrições de recursos a seguir para obter detalhes.
Geral
- Restringir o escopo e o tempo de vida do PAT (token de acesso pessoal) por meio de Azure AD política de locatário
- Suporte à política de acesso condicional para tráfego IPv6
Azure Pipelines
- Reter pipelines que são consumidos em outros pipelines
- Alterações na criação automática de ambientes
- Remover o diálogo insights do Build Pipeline
Azure Repos
Geral
Restringir o escopo e o tempo de vida do PAT (token de acesso pessoal) por meio de Azure AD política de locatário
Os PATs (tokens de acesso pessoal) facilitam a autenticação no Azure DevOps para integração com suas ferramentas e serviços. No entanto, tokens vazados podem comprometer sua conta e dados do Azure DevOps, colocando seus aplicativos e serviços em risco.
Recebemos comentários sobre os administradores não terem os controles necessários para limitar a área de superfície de ameaça representada por PATs vazadas. Com base nesses comentários, adicionamos um novo conjunto de políticas que podem ser usadas para restringir o escopo e o tempo de vida dos PATs (tokens de acesso pessoal) do Azure DevOps da sua organização! Veja como eles funcionam:
Os usuários atribuídos à função administrador do Azure DevOps no Azure Active Directory podem navegar até a guia Azure Active Directory nas configurações da organização de qualquer organização do Azure DevOps vinculada à Azure AD.
Lá, os administradores podem:
- restringir a criação de tokens de acesso pessoal global (tokens que funcionam para todas as organizações do Azure DevOps que podem ser acessados pelo usuário)
- restringir a criação de tokens de acesso pessoal com escopo completo
- definir um tempo de vida máximo para novos tokens de acesso pessoal
Essas políticas serão aplicadas a todos os novos PATs criados por usuários para organizações do Azure DevOps vinculadas ao locatário Azure AD. Cada uma das políticas tem uma lista de permissões para usuários e grupos que devem ser isentos da política. A lista de usuários e grupos na lista Permitir não terá acesso para gerenciar a configuração da política.
Essas políticas se aplicam apenas a novos PATs e não afetarão os PATs existentes que já foram criados e estão em uso. No entanto, depois que as políticas tiverem sido habilitadas, todos os PATs existentes e agora não compatíveis deverão ser atualizados para estar dentro das restrições antes que possam ser renovados.
Suporte à política de acesso condicional para tráfego IPv6
Agora estamos estendendo o suporte à CAP (política de acesso condicional) para incluir políticas de isolamento IPv6. Como vemos as pessoas acessarem cada vez mais os recursos do Azure DevOps em dispositivos de endereços IPv6, queremos garantir que suas equipes estejam equipadas para conceder e remover o acesso de qualquer endereço IP, incluindo aqueles provenientes do tráfego IPv6.
Azure Pipelines
Reter pipelines que são consumidos em outros pipelines
As versões clássicas tinham a capacidade de reter automaticamente os builds que consomem. Essa foi uma das lacunas entre versões clássicas e pipelines YAML e impediu que alguns de vocês se migrassem para YAML. Com esta versão, resolvemos essa lacuna.
Agora você pode criar um pipeline YAML de vários estágios para representar sua versão e consumir outro pipeline YAML nele como um recurso. Quando você fizer isso, o Azure Pipelines manterá automaticamente o pipeline de recursos, desde que o pipeline de lançamento seja retido. Quando o pipeline de lançamento é excluído, a concessão no pipeline de recursos é lançada e suas próprias políticas de retenção são seguidas.
Alterações na criação automática de ambientes
Quando você cria um pipeline YAML e se refere a um ambiente que não existe, o Azure Pipelines cria automaticamente o ambiente. Essa criação automática pode ocorrer no contexto do usuário ou no contexto do sistema. Nos seguintes fluxos, o Azure Pipelines sabe sobre o usuário que está executando a operação:
- Você usa o assistente de criação de pipeline YAML na experiência Web do Azure Pipelines e se refere a um ambiente que ainda não foi criado.
- Atualize o arquivo YAML usando o editor Web do Azure Pipelines e salve 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 usuário que está executando a operação. Portanto, ele cria o ambiente e adiciona o usuário à função de administrador para o ambiente. Esse usuário tem todas as permissões para gerenciar o ambiente e/ou incluir outros usuários em várias funções para gerenciar o ambiente.
Nos fluxos a seguir, o Azure Pipelines não tem informações sobre o usuário que está criando o ambiente: você atualize o arquivo YAML usando outro editor de código externo, adiciona uma referência a um ambiente que não existe e, em seguida, faz com que um pipeline de integração seja disparado. Nesse caso, o Azure Pipelines não conhece o usuário. Anteriormente, tratamos desse caso adicionando todos os colaboradores do projeto à função de administrador do ambiente. Qualquer membro do ambiente poderia alterar essas permissões e impedir que outras pessoas acessassem o ambiente.
Recebemos seus comentários sobre como conceder permissões de administrador em um ambiente a todos os membros de um projeto. Enquanto ouvimos seus comentários, ouvimos que não deveríamos criar automaticamente um ambiente se não estiver claro quem é o usuário que está executando a operação. Com esta versão, fizemos alterações na forma como os ambientes serão criados automaticamente:
- Daqui para frente, as execuções de pipeline não criarão automaticamente um ambiente se ele não existir e se o contexto do usuário não for conhecido. Nesses casos, o pipeline falhará com um erro Ambiente não encontrado. Você precisa criar previamente os ambientes com a segurança certa e verificar a configuração antes de usá-los em um pipeline.
- Pipelines com contexto de usuário conhecido ainda criarão ambientes automaticamente, assim como fizeram no passado.
- Por fim, deve-se observar que o recurso para criar automaticamente um ambiente só foi adicionado para simplificar o processo de introdução ao Azure Pipelines. Destinava-se a cenários de teste e não a cenários de produção. Você sempre deve pré-criar ambientes de produção com as permissões e verificações certas e usá-los em pipelines.
Remover o diálogo insights do Build Pipeline
Com base em seus comentários, a caixa de diálogo Insights de tarefa/pipeline exibida ao navegar pelo Pipeline de Build foi removida para melhorar o fluxo de trabalho. A análise de pipeline ainda está disponível para que você tenha os insights necessários.
Azure Repos
Atualizações para a extensão do Windows Shell do TFVC (Controle de Versão do Team Foundation) para Visual Studio 2019
A versão anterior da extensão do Windows Shell do TFVC funcionava apenas em computadores que tinham o Visual Studio 2017 instalado.
Lançamos uma nova versão dessa ferramenta compatível com o Visual Studio 2019. A extensão fornece integração com o Windows Explorer e as caixas de diálogo de arquivo comuns. Com essa integração, você pode executar muitas operações de controle do código-fonte sem precisar executar o Visual Studio ou uma ferramenta de linha de comando do Team Foundation.
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,
Vijay Machiraju