Gerenciamento de equipes e usuários com Amazon SageMaker e AWS SSO

Estúdio Amazon SageMaker é um ambiente de desenvolvimento integrado (IDE) baseado na Web para aprendizado de máquina (ML) que permite criar, treinar, depurar, implantar e monitorar seus modelos de ML. Cada usuário integrado no Studio tem seu próprio conjunto dedicado de recursos, como instâncias de computação, um diretório inicial em um Sistema de arquivos elástico da Amazon (Amazon EFS) e um volume dedicado Gerenciamento de acesso e identidade da AWS (IAM) função de execução.

Um dos desafios mais comuns do mundo real na configuração do acesso do usuário para o Studio é como gerenciar vários usuários, grupos e equipes de ciência de dados para acesso a dados e isolamento de recursos.

Muitos clientes implementam o gerenciamento de usuários usando identidades federadas com Logon único da AWS (AWS SSO) e um provedor de identidade externo (IdP), como Active Directory (AD) ou diretório AWS Managed Microsoft AD. Está alinhado com a AWS prática recomendada de usar credenciais temporárias para acessar contas da AWS.

An Amazon Sage Maker domínio oferece suporte ao AWS SSO e pode ser configurado no AWS SSO modo de autenticação. Nesse caso, cada usuário autorizado do AWS SSO tem seu próprio Perfil de usuário do Studio. Os usuários com acesso ao Studio têm um URL de login exclusivo que abre diretamente o Studio e fazem login com suas credenciais do AWS SSO. As organizações gerenciam seus usuários no AWS SSO em vez do domínio do SageMaker. Você pode atribuir o acesso de vários usuários ao domínio ao mesmo tempo. Você pode usar os perfis de usuário do Studio para cada usuário para definir suas permissões de segurança nos notebooks do Studio por meio de uma função do IAM anexada ao perfil do usuário, chamada de papel de execução. Essa função controla as permissões para operações do SageMaker de acordo com suas políticas de permissão do IAM.

No modo de autenticação do AWS SSO, sempre há um mapeamento de um para um entre usuários e perfis de usuário. O domínio do SageMaker gerencia a criação de perfis de usuário com base no ID de usuário do AWS SSO. Você não pode criar perfis de usuário por meio do Console de gerenciamento da AWS. Isso funciona bem no caso de um usuário ser membro de apenas uma equipe de ciência de dados ou se os usuários tiverem requisitos de acesso iguais ou muito semelhantes em seus projetos e equipes. Em um caso de uso mais comum, quando um usuário pode participar de vários projetos de ML e ser membro de várias equipes com requisitos de permissão ligeiramente diferentes, o usuário requer acesso a diferentes perfis de usuário do Studio com diferentes funções de execução e políticas de permissão. Como não é possível gerenciar perfis de usuário independentemente do AWS SSO no modo de autenticação do AWS SSO, você não pode implementar um mapeamento de um para muitos entre usuários e perfis de usuário do Studio.

Se você precisar estabelecer uma forte separação de contextos de segurança, por exemplo, para diferentes categorias de dados, ou precisar impedir totalmente a visibilidade de um grupo de atividades e recursos de usuários para outro, a abordagem recomendada é criar vários domínios do SageMaker. No momento da redação deste artigo, você pode criar apenas um domínio por conta da AWS por região. Para implementar a separação forte, você pode usar várias contas da AWS com um domínio por conta como solução alternativa.

O segundo desafio é restringir o acesso ao Studio IDE apenas para usuários de dentro de uma rede corporativa ou de uma VPC designada. Você pode conseguir isso usando Políticas de controle de acesso baseadas em IAM. Neste caso, o domínio SageMaker deve ser configurado com Modo de autenticação do IAM, porque as políticas baseadas em identidade do IAM não são compatíveis com o mecanismo de login no modo AWS SSO. A postagem Acesso seguro ao Amazon SageMaker Studio com AWS SSO e um aplicativo SAML resolve esse desafio e demonstra como controlar o acesso de rede a um domínio SageMaker.

Essa solução aborda esses desafios do gerenciamento de usuários do AWS SSO para Studio para um caso de uso comum de vários grupos de usuários e um mapeamento de muitos para muitos entre usuários e equipes. A solução descreve como usar um aplicativo SAML 2.0 personalizado como o mecanismo para acionar a autenticação do usuário para o Studio e oferecer suporte a vários perfis de usuário do Studio por usuário do AWS SSO.

Você pode usar essa abordagem para implementar um portal de usuário personalizado com aplicativos apoiados pelo processo de autorização SAML 2.0. Seu portal de usuário personalizado pode ter flexibilidade máxima sobre como gerenciar e exibir aplicativos de usuário. Por exemplo, o portal do usuário pode mostrar alguns metadados do projeto de ML para facilitar a identificação de um aplicativo para acesso.

Você pode encontrar o código-fonte da solução em nosso Repositório GitHub.

Visão geral da solução

A solução implementa a seguinte arquitetura.

Os principais componentes de arquitetura de alto nível são os seguintes:

1. Provedor de identidade – Os usuários e grupos são gerenciados em uma fonte de identidade externa, por exemplo, no Azure AD. As atribuições de usuários a grupos do AD definem quais permissões um determinado usuário tem e a qual equipe do Studio ele tem acesso. A fonte de identidade deve ser sincronizada com o AWS SSO.
2. AWSSSO – O AWS SSO gerencia usuários de SSO, conjuntos de permissões de SSO e aplicativos. Esta solução usa um aplicativo SAML 2.0 personalizado para fornecer acesso ao Studio para usuários autorizados do AWS SSO. A solução também usa o mapeamento de atributo SAML para preencher a declaração SAML com dados relevantes de acesso específicos, como ID do usuário e equipe do usuário. Como a solução cria uma API SAML, você pode usar qualquer IdP compatível com asserções SAML para criar essa arquitetura. Por exemplo, você pode usar o Okta ou até mesmo seu próprio aplicativo da web que fornece uma página de destino com um portal de usuário e aplicativos. Para esta postagem, usamos o AWS SSO.
3. Aplicativos SAML 2.0 personalizados – A solução cria um aplicativo por equipe do Studio e atribui um ou vários aplicativos a um usuário ou grupo de usuários com base em direitos. Os usuários podem acessar esses aplicativos de dentro do portal do usuário do AWS SSO com base nas permissões atribuídas. Cada aplicativo é configurado com o Gateway de API da Amazon URL do endpoint como seu back-end SAML.
4. Domínio do SageMaker – A solução provisiona um domínio do SageMaker em uma conta da AWS e cria um perfil de usuário dedicado para cada combinação de usuário do AWS SSO e equipe do Studio à qual o usuário é atribuído. O domínio deve ser configurado no IAM modo de autenticação.
5. Perfis de usuário do Studio – A solução cria automaticamente um perfil de usuário dedicado para cada combinação de usuário-equipe. Por exemplo, se um usuário for membro de duas equipes do Studio e tiver permissões correspondentes, a solução fornecerá dois perfis de usuário separados para esse usuário. Cada perfil sempre pertence a um e apenas um usuário. Como você tem um perfil de usuário do Studio para cada combinação possível de usuário e equipe, deve considerar os limites de sua conta para perfis de usuário antes de implementar essa abordagem. Por exemplo, se seu limite for de 500 perfis de usuário e cada usuário for membro de duas equipes, você consumirá esse limite 2.5 vezes mais rápido e, como resultado, poderá integrar 250 usuários. Com um grande número de usuários, recomendamos a implementação de vários domínios e contas para separação de contexto de segurança. Para demonstrar a prova de conceito, usamos dois usuários, Usuário 1 e Usuário 2, e duas equipes Studio, Equipe 1 e Equipe 2. O Usuário 1 pertence a ambas as equipes, enquanto o Usuário 2 pertence apenas à Equipe 2. O usuário 1 pode acessar os ambientes do Studio para ambas as equipes, enquanto o usuário 2 pode acessar apenas o ambiente do Studio para a equipe 2.
6. Funções de execução do Studio – Cada perfil de usuário do Studio usa uma função de execução dedicada com políticas de permissão com o nível de acesso necessário para a equipe específica à qual o usuário pertence. As funções de execução do Studio implementam um isolamento de permissão eficaz entre usuários individuais e suas funções de equipe. Você gerencia o acesso a dados e recursos para cada função e não em um nível de usuário individual.

A solução também implementa um controle de acesso baseado em atributos (ABAC) usando atributos SAML 2.0, tags nos perfis de usuário do Studio e tags nas funções de execução do SageMaker.

Nesta configuração específica, presumimos que os usuários do AWS SSO não tenham permissões para fazer login na conta da AWS e não tenham funções correspondentes do IAM controladas pelo AWS SSO na conta. Cada usuário faz login em seu ambiente Studio por meio de um URL pré-assinado de um portal do AWS SSO sem a necessidade de acessar o console em sua conta da AWS. Em um ambiente do mundo real, talvez seja necessário configurar Conjuntos de permissões do AWS SSO para que os usuários permitam que os usuários autorizados assumam uma função do IAM e façam login em uma conta da AWS. Por exemplo, você pode fornecer permissões de função de cientista de dados para que um usuário possa interagir com os recursos da conta e ter o nível de acesso necessário para cumprir sua função.

Arquitetura da solução e fluxo de trabalho

O diagrama a seguir apresenta o fluxo de login de ponta a ponta para um usuário do AWS SSO.

Um usuário do AWS SSO escolhe um aplicativo Studio correspondente em seu portal do AWS SSO. O AWS SSO prepara uma declaração SAML (1) com mapeamentos de atributos SAML configurados. Um aplicativo SAML personalizado é configurado com o URL do endpoint do API Gateway como seu Assertion Consumer Service (ACS) e precisa de atributos de mapeamento contendo o ID de usuário e o ID de equipe do AWS SSO. Nós usamos ssouserid e teamid atributos personalizados para enviar todas as informações necessárias ao back-end SAML.

O API Gateway chama uma API de back-end SAML. Um AWS Lambda A função (2) implementa a API, analisa a resposta SAML para extrair o ID do usuário e o ID da equipe. A função os usa para recuperar uma configuração específica da equipe, como uma função de execução e um ID de domínio do SageMaker. A função verifica se existe um perfil de usuário obrigatório no domínio e cria um novo com as definições de configuração correspondentes se não existir nenhum perfil. Depois, a função gera um URL pré-assinado do Studio para um perfil de usuário específico do Studio chamando CreatePresignedDomainUrl API (3) por meio de um VPC endpoint da API SageMaker. A função Lambda finalmente retorna o URL pré-assinado com a resposta de redirecionamento HTTP 302 para conectar o usuário ao Studio.

A solução implementa uma versão de amostra de não produção de um back-end SAML. A função Lambda analisa a declaração SAML e usa apenas atributos no <saml2:AttributeStatement> elemento para construir um CreatePresignedDomainUrl chamada de API. Em sua solução de produção, você deve usar uma implementação de back-end SAML adequada, que deve incluir uma validação de uma resposta SAML, uma assinatura e certificados, prevenção de repetição e redirecionamento e quaisquer outros recursos de um processo de autenticação SAML. Por exemplo, você pode usar um Implementação de back-end SAML python3-saml or Kit de ferramentas SAML de código aberto OneLogin para implementar um back-end SAML seguro.

Criação dinâmica de perfis de usuário do Studio

A solução cria automaticamente um perfil de usuário do Studio para cada combinação de usuário e equipe, assim que o processo de login do AWS SSO solicita um URL pré-assinado. Para esta prova de conceito e simplicidade, a solução cria perfis de usuários com base nos metadados configurados na AWS Modelo SAM:

Metadata:
  Team1:
    DomainId: !GetAtt SageMakerDomain.Outputs.SageMakerDomainId
    SessionExpiration: 43200
    Tags:
      - Key: Team
        Value: Team1
    UserSettings:
      ExecutionRole: !GetAtt IAM.Outputs.SageMakerStudioExecutionRoleTeam1Arn
  Team2:
    DomainId !GetAtt SageMakerDomain.Outputs.SageMakerDomainId
    SessionExpiration: 43200
    Tags:
      - Key: Team
        Value: Team2
    UserSettings:
      ExecutionRole: !GetAtt IAM.Outputs.SageMakerStudioExecutionRoleTeam2Arn

Você pode definir suas próprias equipes, configurações personalizadas e tags adicionando-as à configuração de metadados do recurso AWS CloudFormation GetUserProfileMetadata.

Para obter mais informações sobre elementos de configuração de UserSettings, referir-se create_user_profile no boto3.

Papéis IAM

O diagrama a seguir mostra as funções do IAM nesta solução.

Os papéis são os seguintes:

1. Função de execução do Studio – Um perfil de usuário do Studio usa uma função de execução dedicada do Studio com permissões de dados e recursos específicas para cada equipe ou grupo de usuários. Essa função também pode usar tags para implementar o ABAC para acesso a dados e recursos. Para obter mais informações, consulte Funções do SageMaker.
2. Função de execução do Lambda de back-end SAML – Esta função de execução contém permissão para chamar o CreatePresignedDomainUrl API. Você pode configurar a política de permissão para incluir verificações condicionais adicionais usando Condition chaves. Por exemplo, para permitir o acesso ao Studio apenas a partir de um intervalo designado de endereços IP em sua rede corporativa privada, use o seguinte código:

   {
       "Version": "2012-10-17",
       "Statement": [
           {
               "Action": [
                   "sagemaker:CreatePresignedDomainUrl"
               ],
               "Resource": "arn:aws:sagemaker:<Region>:<Account_id>:user-profile/*/*",
               "Effect": "Allow"
           },
           {
               "Condition": {
                   "NotIpAddress": {
                       "aws:VpcSourceIp": "10.100.10.0/24"
                   }
               },
               "Action": [
                   "sagemaker:*"
               ],
               "Resource": "arn:aws:sagemaker:<Region>:<Account_id>:user-profile/*/*",
               "Effect": "Deny"
           }
       ]
   }

   Para obter mais exemplos sobre como usar condições em políticas do IAM, consulte Controle o acesso à API do SageMaker usando políticas baseadas em identidade.

3. SageMaker – O SageMaker assume a função de execução do Studio em seu nome, conforme controlado por uma política de confiança correspondente na função de execução. Isso permite que o serviço acesse dados e recursos e execute ações em seu nome. A função de execução do Studio deve conter uma política de confiança que permita ao SageMaker assumir essa função.
4. Função do IAM do conjunto de permissões do AWS SSO – Você pode atribuir seus usuários do AWS SSO a contas da AWS em sua organização da AWS por meio de Conjuntos de permissões do AWS SSO. Um conjunto de permissões é um modelo que define uma coleção de políticas do IAM específicas da função do usuário. Você gerencia conjuntos de permissões no AWS SSO e o AWS SSO controla as funções do IAM correspondentes em cada conta.
5. Políticas de controle de serviço do AWS Organizations - Se você usar Organizações AWS, você pode implementar Políticas de controle de serviço (SCPs) para controlar centralmente o máximo de permissões disponíveis para todas as contas e todas as funções do IAM em sua organização. Por exemplo, para impedir centralmente o acesso ao Studio por meio do console, você pode implementar o seguinte SCP e anexá-lo às contas com o domínio SageMaker:

   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Action": [
           "sagemaker:*"
         ],
         "Resource": "*",
         "Effect": "Allow"
       },
       {
         "Condition": {
           "NotIpAddress": {
             "aws:VpcSourceIp": "<AuthorizedPrivateSubnet>"
           }
         },
         "Action": [
           "sagemaker:CreatePresignedDomainUrl"
         ],
         "Resource": "*",
         "Effect": "Deny"
       }
     ]
   }

Funções provisionadas da solução

A Formação da Nuvem AWS pilha para esta solução cria três funções de execução do Studio usadas no domínio SageMaker:

• SageMakerStudioExecutionRoleDefault
• SageMakerStudioExecutionRoleTeam1
• SageMakerStudioExecutionRoleTeam2

Nenhum dos papéis tem o AmazonSageMakerFullAccess política anexada e cada um tem apenas um conjunto limitado de permissões. Em seu ambiente SageMaker do mundo real, você precisa alterar as permissões da função com base em seus requisitos específicos.

SageMakerStudioExecutionRoleDefault tem apenas a política personalizada SageMakerReadOnlyPolicy anexado com uma lista restritiva de ações permitidas.

Ambos os papéis da equipe, SageMakerStudioExecutionRoleTeam1 e SageMakerStudioExecutionRoleTeam2, além de duas políticas personalizadas, SageMakerAccessSupportingServicesPolicy e SageMakerStudioDeveloperAccessPolicy, permitindo o uso de serviços específicos e uma política somente de negação, SageMakerDeniedServicesPolicy, com negação explícita em algumas chamadas de API do SageMaker.

A política de acesso do desenvolvedor do Studio impõe a configuração do Team tag igual ao mesmo valor da função de execução do próprio usuário para chamar qualquer SageMaker Create* API:

{
    "Condition": {
        "ForAnyValue:StringEquals": {
            "aws:TagKeys": [
                "Team"
            ]
        },
        "StringEqualsIfExists": {
            "aws:RequestTag/Team": "${aws:PrincipalTag/Team}"
        }
    },
    "Action": [
        "sagemaker:Create*"
    ],
    "Resource": [
        "arn:aws:sagemaker:*:<ACCOUNT_ID>:*"
    ],
    "Effect": "Allow",
    "Sid": "AmazonSageMakerCreate"
}

Além disso, ele permite o uso de operações de exclusão, parada, atualização e inicialização apenas em recursos marcados com a mesma tag Team que a função de execução do usuário:

{
    "Condition": {
        "StringEquals": {
            "aws:PrincipalTag/Team": "${sagemaker:ResourceTag/Team}"
        }
    },
    "Action": [
        "sagemaker:Delete*",
        "sagemaker:Stop*",
        "sagemaker:Update*",
        "sagemaker:Start*",
        "sagemaker:DisassociateTrialComponent",
        "sagemaker:AssociateTrialComponent",
        "sagemaker:BatchPutMetrics"
    ],
    "Resource": [
        "arn:aws:sagemaker:*:<ACCOUNT_ID>:*"
    ],
    "Effect": "Allow",
    "Sid": "AmazonSageMakerUpdateDeleteExecutePolicy"
}

Para obter mais informações sobre funções e políticas, consulte Configurar o Amazon SageMaker Studio para equipes e grupos com isolamento completo de recursos.

Infraestrutura de rede

A solução implementa um ambiente de domínio SageMaker totalmente isolado com todo o tráfego de rede passando AWS PrivateLink conexões. Opcionalmente, você pode habilitar o acesso à Internet nos notebooks do Studio. A solução também cria três Grupos de segurança da VPC para controlar o tráfego entre todos os componentes da solução, como a função Lambda de back-end SAML, Pontos de extremidade VPC, e cadernos de estúdio.

Para esta prova de conceito e simplicidade, a solução cria uma sub-rede SageMaker em um único Zona de Disponibilidade. Para sua configuração de produção, você deve usar várias sub-redes privadas em várias zonas de disponibilidade e garantir que cada sub-rede tenha o tamanho adequado, supondo um mínimo de cinco IPs por usuário.

Esta solução provisiona toda a infraestrutura de rede necessária. O modelo do CloudFormation ./cfn-templates/vpc.yaml contém o código fonte.

Etapas de implantação

Para implantar e testar a solução, você deve concluir as seguintes etapas:

1. Implante a pilha da solução por meio de um Modelo de aplicativo sem servidor da AWS Modelo (AWS SAM).
2. Crie usuários do AWS SSO ou use usuários existentes do AWS SSO.
3. Crie aplicativos SAML 2.0 personalizados e atribua usuários do AWS SSO aos aplicativos.

O código-fonte completo da solução é fornecido em nosso GitHub repositório.

Pré-requisitos

Para utilizar esta solução, o Interface de linha de comando da AWS (AWSCLI), CLI do AWS SAM e Python3.8 ou posterior Deve ser instalado.

O procedimento de implantação pressupõe que você habilitou o AWS SSO e configurou para o Organizações da AWS na conta em que a solução está implantada.

Para configurar o AWS SSO, consulte as instruções em GitHub.

Opções de implantação da solução

Você pode escolher entre várias opções de implantação de solução para se adequar melhor ao seu ambiente AWS existente. Você também pode selecionar as opções de provisionamento de rede e domínio do SageMaker. Para obter informações detalhadas sobre as diferentes opções de implantação, consulte o Arquivo README.

Implantar o modelo do AWS SAM

Para implantar o modelo do AWS SAM, conclua as etapas a seguir:

1. Clone o código-fonte repositório ao seu ambiente local:

   git clone https://github.com/aws-samples/users-and-team-management-with-amazon-sagemaker-and-aws-sso.git

2. Crie o aplicativo AWS SAM:
3. Implante o aplicativo:

   sam deploy --guided

4. Forneça parâmetros de pilha de acordo com seu ambiente existente e opções de implantação desejadas, como VPC existente, sub-redes públicas e privadas existentes e domínio SageMaker existente, conforme discutido na seção Opções de implantação da solução capítulo do arquivo README.

Você pode deixar todos os parâmetros em seus valores padrão para provisionar novos recursos de rede e um novo domínio do SageMaker. Consulte o uso detalhado dos parâmetros no README arquivo se precisar alterar alguma configuração padrão.

Aguarde até que a implantação da pilha seja concluída. A implantação de ponta a ponta, incluindo o provisionamento de todos os recursos de rede e um domínio do SageMaker, leva cerca de 20 minutos.

Para ver a saída da pilha, execute o seguinte comando no terminal:

export STACK_NAME=<SAM stack name>

aws cloudformation describe-stacks 
--stack-name $STACK_NAME
--output table 
--query "Stacks[0].Outputs[*].[OutputKey, OutputValue]"

Criar usuários de SSO

Siga as instruções para adicionar usuários do AWS SSO para criar dois usuários com nomes User1 e User2 ou use quaisquer dois de seus usuários existentes do AWS SSO para testar a solução. Certifique-se de usar o AWS SSO na mesma região da AWS em que você implantou a solução.

Crie aplicativos SAML 2.0 personalizados

Para criar os aplicativos SAML 2.0 personalizados necessários para a Equipe 1 e para a Equipe 2, conclua as etapas a seguir:

1. Abra o console do AWS SSO na conta de gerenciamento da AWS de sua organização da AWS, na mesma região em que você implantou a pilha de soluções.
2. Escolha Aplicações no painel de navegação.
3. Escolha Adicionar um novo aplicativo.
4. Escolha Adicionar um aplicativo SAML 2.0 personalizado.
5. Escolha Como seu nome será exibido, insira um nome de aplicativo, por exemplo SageMaker Studio Team 1.
6. Deixar URL de início do aplicativo e Estado do relé esvaziar.
7. Escolha Se você não tiver um arquivo de metadados, poderá inserir manualmente seus valores de metadados.
8. Escolha URL do aplicativo ACS, insira o URL fornecido no SAMLBackendEndpoint chave da saída da pilha do AWS SAM.
9. Escolha Público-alvo do aplicativo SAML, insira o URL fornecido no SAMLAudience chave da saída da pilha do AWS SAM.
10. Escolha Salvar as alterações .
    
11. Navegue até a Mapeamentos de atributos aba.
12. Colocou o Assunto para email e Formato para endereço de e-mail.
13. Adicione os seguintes novos atributos:
    1. ssouserid definido para ${user:AD_GUID}
    2. teamid definido para Team1 or Team2, respectivamente, para cada aplicação
       
14. Escolha Salvar as alterações .
15. No Usuários atribuídos guia, escolha Atribuir usuários.
16. Escolha Usuário 1 para o aplicativo Equipe 1 e Usuário 1 e Usuário 2 para o aplicativo Equipe 2.
17. Escolha Atribuir usuários.
    

Teste a solução

Para testar a solução, conclua as seguintes etapas:

1. Acesse o portal do usuário do AWS SSO https://<Identity Store ID>.awsapps.com/start e assine como usuário 1.
   Dois aplicativos SageMaker são mostrados no portal.
   
2. Escolha Equipe 1 do SageMaker Studio.
   Você é redirecionado para a instância do Studio para a Equipe 1 em uma nova janela do navegador.
   Na primeira vez que você inicia o Studio, o SageMaker cria um aplicativo JupyterServer. Este processo leva alguns minutos.
   
3. No estúdio, no Envie o menu, escolha Novo e terminal para iniciar um novo terminal.
4. Na linha de comando do terminal, digite o seguinte comando:

   aws sts get-caller-identity

   O comando retorna a função de execução do Studio.
   

   Em nossa configuração, esse papel deve ser diferente para cada equipe. Você também pode verificar se cada usuário em cada instância do Studio tem seu próprio diretório inicial em um volume do Amazon EFS montado.

5. Retorne ao portal do AWS SSO, ainda registrado como Usuário 1, e escolha Equipe 2 do SageMaker Studio.
   Você é redirecionado para uma instância do Team 2 Studio.
   O processo de inicialização pode demorar vários minutos, porque o SageMaker inicia um novo aplicativo JupyterServer para o usuário 2.
6. Assine como usuário 2 no portal do AWS SSO.
   O usuário 2 tem apenas um aplicativo atribuído: SageMaker Studio Team 2.
   

Se você iniciar uma instância do Studio por meio desse aplicativo de usuário, poderá verificar se ele usa a mesma função de execução do SageMaker que a instância da Equipe 1 do Usuário 2. No entanto, cada instância do Studio é completamente isolada. O usuário 2 tem seu próprio diretório inicial em um volume do Amazon EFS e sua própria instância do aplicativo JupyterServer. Você pode verificar isso criando uma pasta e alguns arquivos para cada um dos usuários e ver se o diretório inicial de cada usuário está isolado.

Agora você pode entrar no console do SageMaker e ver que existem três perfis de usuário criados.

Você acabou de implementar uma solução de prova de conceito para gerenciar vários usuários e equipes com o Studio.

limpar

Para evitar cobranças, você deve remover todos os recursos gerados e provisionados pelo projeto de sua conta da AWS. Use o seguinte comando SAM CLI para excluir a pilha do CloudFormation da solução:

sam delete delete-stack --stack-name <stack name of SAM stack>

Por motivos de segurança e para evitar perda de dados, a montagem do Amazon EFS e o conteúdo associado ao domínio do Studio implantado nesta solução não são excluídos. A VPC e as sub-redes associadas ao domínio do SageMaker permanecem em sua conta da AWS. Para obter instruções sobre como excluir o sistema de arquivos e a VPC, consulte Como excluir um sistema de arquivos do Amazon EFS e Trabalhar com VPCs, Respectivamente.

Para excluir o aplicativo SAML personalizado, conclua as etapas a seguir:

1. Abra o console do AWS SSO na conta de gerenciamento do AWS SSO.
2. Escolha Aplicações.
3. Selecionar Equipe 1 do SageMaker Studio.
4. No Opções menu, escolha Eliminar.
5. Repita estes passos para Equipe 2 do SageMaker Studio.

Conclusão

Esta solução demonstrou como você pode criar um ambiente flexível e personalizável usando os perfis de usuário do AWS SSO e do Studio para oferecer suporte à sua própria estrutura organizacional. As próximas etapas de melhoria possíveis para uma solução pronta para produção podem ser:

• Implemente o gerenciamento automatizado de perfil de usuário do Studio como um microsserviço dedicado para dar suporte a um fluxo de trabalho de provisionamento de perfil automatizado e para lidar com metadados e configuração de perfis de usuário, por exemplo, em Amazon DynamoDB.
• Use o mesmo mecanismo em um caso mais geral de vários domínios do SageMaker e várias contas da AWS. O mesmo back-end SAML pode fornecer um URL pré-assinado correspondente redirecionando para uma combinação de perfil de usuário-domínio-conta de acordo com sua lógica personalizada com base nos direitos do usuário e na configuração da equipe.
• Implemente um mecanismo de sincronização entre seu IdP e o AWS SSO e automatize a criação de aplicativos SAML 2.0 personalizados.
• Implemente dados escaláveis ​​e gerenciamento de acesso a recursos com controle de acesso baseado em atributos (ABAC).

Se você tiver algum comentário ou dúvida, por favor, deixe-os nos comentários.

Outras leituras

Documentação

UlTIMOS BLOGS

Sobre o autor

Eugene Ilyin é arquiteto de soluções na AWS. Ele tem mais de 20 anos de experiência trabalhando em todos os níveis de desenvolvimento de software e arquitetura de soluções e usou linguagens de programação de COBOL e Assembler a .NET, Java e Python. Ele desenvolve e codifica soluções nativas de nuvem com foco em big data, análise e engenharia de dados.