Na Uber, a equipe Engenharia de Plataforma do Cliente (CPE) é responsável por construir tanto a nossa infraestrutura de TI quanto por como pensamos em gerenciar os endpoints para a produtividade de local de trabalho.

Com mais de 20.000 funcionários globais, centenas de escritórios e um número cada vez maior de tipos de dispositivos, precisamos construir pipelines flexíveis que nos permitam injetar facilmente novos fluxos de trabalho de gerenciamento sem nos atrasar ou causar dívida técnica.

Nos últimos anos, a equipe de CPE da Uber implantou o Chef, um sistema singular que pode ser dimensionado para vários sistemas operacionais e, ao mesmo tempo, exigir revisão de código para todas as alterações implementadas como a principal plataforma de gerenciamento de endpoint.

Ao contrário das tradicionais plataformas de gerenciamento baseadas em GUI, o Chef permitiu que a equipe criasse fluxos de trabalho determinísticos com base nos requisitos exclusivos da Uber.

Enquanto o Chef continua sendo a principal ferramenta de gerenciamento da Uber, a implementação de novos recursos de segurança da Apple, como Registro de Dispositivos, Extensões de Kernel Seguro e Controle de Política de Preferências de Privacidade, restringiu algumas porções de administração por trás do gerenciamento de dispositivos móveis (MDM).

Neste artigo, discutiremos como a equipe de CPE escalou o MDM no macOS na Uber por meio da padronização de registro e controle de versão de usuários, bem como aproveitando os livros de receitas Chef orientados por API para orquestrar e configurar serviços para usuários em toda a empresa.

Gerenciamento de Dispositivos Móveis (MDM) na Uber

Embora usemos o Chef como nossa principal ferramenta de gerenciamento, nos últimos anos – especialmente no que diz respeito ao macOS – precisamos adotar um sistema de MDM para complementar nossos fluxos de trabalho.

Depois de analisar muitas soluções de MDM de código aberto e de terceiros, decidimos ampliar nossa parceria com um fornecedor de terceiros e adicionar endpoints do MacOS à sua plataforma de espaço de trabalho digital.

Chegamos a essa decisão pelas seguintes razões:

• Força em números: poderíamos alavancar nossos engenheiros de mobilidade durante os estágios de implementação e design, já que essa solução de espaço de trabalho digital já estava sendo usada para dispositivos com sistemas operacionais iOS e Android.
• APIs poderosas: poderíamos aproveitar as APIs InstallApplication e InstallEnterpriseApplication para instalar nossas ferramentas personalizadas. Mover nossas ferramentas personalizadas para o MDM significa que os funcionários devem estar inscritos no MDM para obter acesso a outras ferramentas.
• Perfis de nível de usuário: como essa solução de espaço de trabalho digital era tão proximamente acoplada aos usuários inscritos, pudemos implementar perfis de MDM baseados em dispositivo e perfis de MDM baseados no usuário. As ferramentas de código aberto, como Chef, munki e Puppet, geralmente só suportam perfis locais baseados em dispositivo. Os perfis em nível de usuário nos permitiram melhorar nosso pipeline de instalação de certificados para acesso a ferramentas internas.
• Recursos de segurança: recursos de segurança úteis nos permitiram segmentar máquinas instantaneamente usando o Apple Push Notification Service/Serviço de Notificação por Push da Apple (APNS).

Apesar do MDM estar mais maduro do que nunca, o Chef ainda é nossa principal ferramenta de gerenciamento para garantir que nossas máquinas estejam em um estado conhecido e tenham uma trilha de auditoria clara de todas as alterações feitas na frota.

Padronizando o registro do MDM no macOS

Embora a Apple ofereça o Programa de Registro de Dispositivos (DEP) para registrar dispositivos no MDM, as empresas maiores podem se encontrar em uma posição única, onde um processo de registro bifurcado é o único resultado possível.

Alguns problemas com a aquisição de dispositivos com capacidade de DEP incluem:

• Disponibilidade mundial: sua empresa pode ter escritórios ou funcionários onde o DEP não está disponível. Em alguns países, sua única possibilidade é comprar produtos da Apple marcados como dispositivos de “consumo”. Dispositivos de consumo não podem ser atualmente movidos para o fluxo de trabalho DEP.
• DEP Provisório: o DEP Provisório é um processo pelo qual você pode converter um dispositivo de consumo em um dispositivo corporativo. Infelizmente, isso é oferecido apenas para dispositivos iOS (por exemplo, iPads, iPhones e iPods).
• Revendedores Autorizados da Apple: embora muitos países tenham autorizado revendedores da Apple, seus termos podem não estar alinhados com sua empresa ou simplesmente não ser um parceiro recomendado. Se o país tiver apenas um revendedor autorizado da Apple, você será forçado a comprar dispositivos de consumo.

Além desses pontos de atrito, a escala global da Uber levou a problemas adicionais com a experiência do usuário do MDM. Em nossa escala, sabíamos que fazer com que todos os usuários do macOS lessem um e-mail ou uma mensagem em nossos sistemas internos era impossível no limite.

Para piorar a situação, devido ao nosso processo de aquisição mundial (o DEP não está disponível em todo o mundo), alguns usuários precisariam seguir um fluxo de trabalho DEP MDM e outros precisariam seguir um procedimento padrão de inscrição do MDM.

Além disso, durante os testes internos de nosso sistema MDM, alguns usuários com extensões do Google Chrome, como o Google Music, seriam marcados como tendo uma ferramenta rotulada como “configuração remota”, acionando um novo sistema da Apple chamado MDM aprovado pelo usuário. Isso significava que mesmo que os usuários seguissem as instruções, precisariam de instruções adicionais para alcançar a conformidade total.

Depois de muita discussão, a equipe do CPE chegou à conclusão de que precisaríamos escrever um wrapper personalizado em torno do registro do MDM. Depois de algumas longas e tediosas sessões de codificação, decidimos aproveitar o UMAD, ou Universal MDM Approval Dialog/ UMAD, ou Diálogo de Aprovação Universal MDM, implantado via Chef.

O wrapper UMAD oferece os seguintes recursos:

• Registro de DEP dinâmico suportado pelo macOS 10.9.5 e superior
• Registro do MDM de fallback se o DEP não for acionado em dispositivos com capacidade de DEP
• Registro do MDM para dispositivos não dependentes de DEP
• Detecção de MDM aprovada pelo usuário e mensagens de falha.

Uma data limite, com solicitações de interface do usuário cada vez mais agressivas à medida que a data limite se aproxima.

Com o UMAD testado, nós o implantamos gradualmente em nossos dispositivos usando o livro de receitas cpe_umad.

Percebemos um impacto imediato na velocidade e eficiência do MDM da Uber. Em uma semana, o UMAD ajudou 7.000 funcionários a se inscreverem no MDM e, em seis semanas, o UMAD ajudou 16.000 funcionários a se inscreverem no MDM.

Desses 16.000 usuários, aproximadamente 4.000 tinham algum tipo de configuração incorreta em suas máquinas que foi rapidamente corrigida ao se inscrever no MDM usando o UMAD. Em 10 semanas, o UMAD ajudou 92% dos funcionários da Uber a inscreverem seus dispositivos no MDM.

Padronizando as versões do macOS

Apesar de frequentemente atualizar e aprimorar nossa plataforma Chef, bem como implantar o UMAD em toda a empresa, um dos maiores desafios que enfrentamos envolveu lidar com as complexidades de suportar várias versões do macOS em dispositivos de funcionários.

Em 2018, a quantidade de versões do macOS que estávamos apoiando era bastante grande. Semelhante à forma como padronizamos o registro do macOS MDM com o UMAD, precisávamos de um sistema semelhante para atualizações e melhorias do sistema. Isso seria crítico para proteger os dados da Uber, além de ter uma plataforma de desenvolvimento consistente para a empresa.

Embora usássemos o munki tanto para aplicativos de autoatendimento quanto para atualizações de software da Apple, alguns membros da nossa equipe tinham visto vários problemas com as atualizações do sistema operacional:

• FileVault: dispositivos com FileVault podem não ter uma reinicialização autenticada. Um usuário iniciaria a atualização e iria almoçar, apenas para atingir o tempo limite ou ocorrer uma falha enquanto aguardava a autenticação do usuário.
• Dispositivos T1: os dispositivos macOS T1 exigiam acesso à Internet no momento da instalação e munki pode não conseguir se conectar à Internet no LoginWindow, resultando em possíveis problemas de falha.
• Dispositivos T2: os dispositivos macOS T2 incluíam segurança adicional em relação aos requisitos T1. Atualizações e melhorias do MacOS agora exigem que a máquina pare (desligue) e não reinicialize. Naquele momento, munki não conseguia lidar com dispositivos T2 de parada, resultando em possíveis falhas de instalação.
• Disparidades na Experiência do Usuário: a experiência do usuário do MacOS difere entre sistemas operacionais: dispositivos 10.5 a 10.8 tiveram um painel de preferências Atualização de Software, dispositivos 10.9 até 10.13 tiveram uma atualização unificada da Mac App Store e aba de atualização e dispositivos 10.14 removeram a unificação e reintroduziram a Atualização do painel de preferências de Atualização de Software, mas modernizado para parecer semelhante ao iOS.
• Disparidades durante o teste em dispositivos Apple: a experiência do usuário dentro do munki é diferente da experiência do usuário ao acessar o painel de preferências pela Mac App Store ou Atualização de Software e pode resultar em comportamento inesperado.

Em nossa escala, até 1% das falhas de atualização/melhoria de dispositivos podem resultar em centenas de dispositivos sendo afetados.

Por isso, decidimos usar o Nudge, uma ferramenta de software livre autônoma para lidar com atualizações. Da mesma forma que implementamos o UMAD, o Nudge também seria configurado e implantado via Chef.

O Nudge é um wrapper unificado de código aberto para atualizações principais do MacOS (10.13 a 10.14), atualizações deltas menores do macOS (10.14.0 a 10.14.1) e atualizações combinadas menores do macOS menores (10.14.0 a 10.14.2).

Um administrador precisa apenas garantir que o instalador do macOS esteja disponível nos dispositivos e configurar o Nudge com o sistema operacional mínimo que os dispositivos devem estar executando.

O Nudge nos permite unificar a melhoria e a experiência de atualização em uma única janela ou mensagem e, então, vincular sistematicamente nossa interface às várias interfaces e ferramentas usadas pela Apple.

Ao vincular-se diretamente aos próprios binários da Apple, não precisamos mais nos preocupar com comportamentos inesperados e podemos garantir uma experiência do usuário que seja um reflexo direto do que os clientes da Apple não corporativos verão.

Em termos mais simples, a menos que haja um problema com o instalador ou o processo de instalação da própria Apple, o Nudge não apresentará qualquer nova complexidade ou procedimento não testado que a Apple não possa manipular normalmente.

Por volta do final de 2018, nos sentimos confiantes o suficiente em nossas cadeias de ferramentas de que poderíamos padronizar no macOS 10.14.1.

Na época, o Nudge só oferecia suporte para melhorias do macOS, portanto, não segmentávamos máquinas que executavam o 10.14.0, e nosso sistema operacional mais usado na época era o High Sierra 10.13.6, com cerca de 9.000 dispositivos executando o software.

No quinto dia de implantação do Nudge no início de novembro de 2018, o 10.14.1 havia assumido a liderança com mais de 7.000 dispositivos. No final de 2018, com a ajuda do Airbnb, o Nudge recebeu um apoio menor de atualização.

Agora que estamos além do 90º dia do Nudge sendo implantado, o 10.14.3 (a versão mais atual do macOS em março de 2019) é o nosso sistema operacional mais usado e mais de 87% dos sistemas da Uber estão usando alguma versão do Mojave.

O melhor de tudo é que o nosso service desk (ainda) não emitiu nenhum ticket para a nossa equipe em relação às falhas de melhoria do Nudge.

Na Uber, gerenciamos o Nudge com nosso livro de receitas cpe_nudge, que você também pode encontrar em nosso GitHub.

Chef como um serviço

O principal princípio de design que estamos seguindo no Chef é o conceito de livros de receitas de API. Essa ideia tem sido defendida pelas equipes de Engenharia de Produção do Facebook e Engenharia de Plataformas Clientes do Facebook ao longo dos anos.

Alguns benefícios dos livros de receitas de API incluem:

• Em vez de usar valores padrão codificados, os valores são “nulo” ou “falso”. Ao abstrair esses valores, você não precisa continuar a escrever um novo código principal se o conteúdo que está manipulando mudar – você simplesmente atualiza os pares chave/valor .
• Pares de chave/valor podem ser condicionalmente substituídos. Isso permite a você aproveitar um único livro de receitas que pode funcionar em vários sistemas operacionais.
• Como cada valor pode ser substituído, você pode estender essas mesmas APIs para seus usuários finais, permitindo que eles gravem seus próprios valores para recursos. Por exemplo, cpe_user_customizations é o que usamos para permitir que nossos usuários finais personalizem ações como suas instalações de software e protetores de tela padrão. Eles persistem em todos os computadores aproveitados por um único usuário final.
• As APIs permitem que você abstraia o código para outras equipes que podem não entender completamente como usar o Chef, mas podem entender os pares chave/valor. Isso reduz muito o custo de engenharia para manutenção.

Dada a forma como os livros de receitas de código aberto foram benéficos para a nossa equipe, a Uber aborda a criação de livros de receitas de API com o código aberto em mente; na verdade, não existem configurações padrão opinativas que se aplicam apenas ao incluir o livro de receitas em uma lista de execução.

Cada livro de receitas da API está desativado por padrão e deve estar ativado e passar uma configuração antes que qualquer estado seja gerenciado.

Abaixo, descrevemos as principais razões pelas quais a Uber alavanca essa abordagem para o desenvolvimento de livros de receitas:

• Ser um bom membro da comunidade de software livre (contribuindo com código, não apenas consumindo-o) melhora a qualidade do código e pode criar conjuntos de recursos robustos.
• Escrever livros de receita generalizados força a abstração, o que diminui a lógica específica e a dívida técnica potencial, ao mesmo tempo em que diminui a probabilidade de vazamento de informações proprietárias por acidente.

Os trechos de código a seguir são um exemplo do que um engenheiro de endpoint pode usar para implantar o Sal (uma ferramenta de geração de relatórios de software livre modular para endpoints) em seu ambiente. cpe_sal seria executado primeiro, seguido por cpe_profiles e cpe_launchd, ambos os livros de receitas necessários para serem consumidos pelo cpe_sal.

Um engenheiro de endpoint pode assumir que três livros de receitas estão sendo executados e, embora isso seja tecnicamente verdadeiro, se detalharmos o livro de receitas, veremos um padrão: cpe_sal tem um arquivo de atributos e os principais atributos são falsos ou nulos.

No arquivo de recurso cpe_sal real (o código principal para cpe_sal), há protetores `return` em torno de cada ação. Se os valores forem falsos, essa função específica não fará nada.

Isso nos permite colocar cpe_sal em nossa run_list global, sem qualquer preocupação de que ela realmente aplicará configurações aos dispositivos. Você deve marcá-los explicitamente como verdadeiros.

Desde Chef permite que você crie qualquer livro de receitas, você pode simplesmente criar um livro de receitas que se aplica os atributos que seus livros de receitas de código aberto precisam consumir.

No exemplo abaixo, criamos um livro de receitas cpe_base que possui alguns dos atributos que o cpe_sal precisaria para executar uma configuração.

Esse tipo de livro de receitas será diferente por empresa, com base nos livros de receitas de código aberto que você consome, portanto, crie o que quiser aqui e adicione-o à sua lista de execução.

O livro de culinária cpe_base agora está adicionado à lista de execução original e precisa vir antes de cpe_sal, para que cpe_sal possa consumir os atributos que você modificou.

Ao usar essa abordagem, podemos abrir o cpe_sal de código aberto sem expor nenhum código personalizado que implementamos. Esses snippets são apenas um pequeno exemplo de como os poderosos livros de receita controlados por API podem ser aproveitados corretamente.

Avançando

O escalonamento do gerenciamento de dispositivos móveis em uma empresa de hiper-crescimento como a Uber facilitou uma mentalidade criativa que dependia muito das ferramentas de MDM existentes, como o Chef.

Nossa experiência no desenvolvimento de sistemas de MDM em escala nos deu exposição a soluções de código aberto que talvez não tenhamos considerado anteriormente para ambientes de produção.

Com este espírito, nós encorajamos você a conferir o Nudge e nossos livros de receita do Chef CPE para você mesmo e começar a construir um sistema de MDM mais eficiente para o seu local de trabalho.

Se enfrentar problemas de engenharia de TI em larga escala te interessa, considere se candidatar a um cargo em nossa equipe!

***

Este artigo é do Uber Engineering. Ele foi escrito por Erik Gomez e Nate Walck. A tradução foi feita pela Redação iMasters com autorização. Você pode conferir o original em: https://eng.uber.com/scaling-mobile-device-management-at-uber/.