> ## Documentation Index > Fetch the complete documentation index at: https://docs.basaltic.sh/llms.txt > Use this file to discover all available pages before exploring further. # Limites de permissão > Limitar o que um principal pode ser concedido, para que você possa delegar o gerenciamento de permissões com segurança. Um limite de permissão é uma política anexada a um principal que define o **máximo dentro de seu domínio de política** que pode ser concedido. Não concede nada por si só — é um teto, não um piso. ``` effective permissions = what the policies allow ∩ what the boundary allows ``` Uma ação tem que ser permitida por **ambos**. Uma política que concede algo fora da fronteira não concede nada. As contas e funções de serviço de conta utilizam limites de política de conta. Os usuários usam limites de política de organização de espaço de trabalho. Os limites de conta não limitam as permissões de organização delegadas separadamente; controlam aquelas com concessão de políticas de organização e políticas de sessão aplicáveis. ## Por que eles existem Sem limites, deixar alguém gerenciar permissões significa deixá-los conceder a si mesmos qualquer coisa. Um limite permite que você delege isso com segurança: um líder de equipe pode criar contas de serviço e anexar políticas, e nada que eles anexem pode ultrapassar o limite que você definir. Uma política que descreve o conjunto mais amplo de permissões que qualquer coisa nesta equipe pode ter. ```json theme={null} { "version": "2024-01-01", "statements": [{ "sid": "TeamCeiling", "effect": "allow", "actions": ["compute:*", "storage:*", "dns:*"], "resources": ["*"], "conditions": [ { "operator": "equals", "key": "basalt:ResourceTag/team", "values": ["platform"] } ] }] } ``` Abra o usuário, conta de serviço ou função e encontre o cartão **Permission Boundary**. Escolha **Set Boundary** e escolha a política. Uma vez que um é definido, o botão diz **Change**, e limpando-o confirma com **Remove Permission Boundary**. Um grupo não tem tal cartão, que é a tabela abaixo tornado visível. ```bash theme={null} PUT /v1/service-accounts/{service_account_id}/permission-boundary { "policy": "..." } ``` Os mesmos métodos existem para funções no IAM. Os limites de usuário usam `workspace.basaltic.sh/v1/users/{user_id}/permission-boundary` e uma política de organização. ```bash theme={null} basaltic iam service-account set-permission-boundary \ --policy ``` `get-permission-boundary` e `remove-permission-boundary` são os outros dois, e `workspace user` e `iam role` carregam os mesmos três. ```go theme={null} err := iam.New(cfg).SetServiceAccountPermissionBoundary(ctx, serviceAccountID, &iam.SetBoundaryRequest{Policy: policyID}) ``` Quem quer que gerencie esse principal pode agora anexar quaisquer políticas que desejar. Qualquer coisa fora do teto não tem efeito. ## A que se aplica um limite | Página principal | Delimitado em | | - | - | | Usuário registrado | Seu próprio limite de espaço de trabalho, para ações de organização | | Conta de serviço | Seu limite de conta, para ações de conta | | Papel assumido | O limite da conta da **função** — a sessão herda o limite da conta | | Grupo de trabalho | — Os grupos carregam políticas, não limites | Uma sessão de função assumida é delimitada pela função que assumiu, não por quem assumiu. A função é a entidade limitada; uma sessão não pode escapar do limite da função criando-se a partir de um chamador sem limites. Os proprietários de organizações seguem a mesma avaliação de políticas que outros diretores. Não é possível anexar um limite durável que remova o acesso de administrador necessário do proprietário. Transfira a propriedade antes de restringir essas concessões. Restrições temporárias de sessão ainda se aplicam. ## Como combina com tudo o mais Um limite é o **último** dos três passos de estreitamento, e cada um só pode subtrair: ```mermaid theme={null} flowchart LR A[Identity policies] --> B[∩ session policy] B --> C[∩ permission boundary] C --> D[Effective permissions] ``` Uma negação explícita no domínio da política avaliada o curto-circuita. Veja [como uma solicitação é autorizada](/pt/iam#how-a-request-is-authorized). ## Failing closed Se um limite for definido, mas o limite ou sua política **não puder ser lido**, a solicitação será negada. Um limite que existe, mas é ilegível pode estar limitando essa ação, então a resposta segura é não. A consequência prática: excluir uma política que está em uso como um limite não amplia o acesso, ele o remove. ## Exemplo de trabalho Delegar o gerenciamento de instâncias a uma equipe, com segurança. Tudo o que essa equipe pode tocar — computação e armazenamento, apenas em recursos marcados como seus, e nunca IAM. ```json theme={null} { "version": "2024-01-01", "statements": [ { "sid": "Ceiling", "effect": "allow", "actions": ["compute:*", "storage:*"], "resources": ["*"], "conditions": [ { "operator": "equals", "key": "basalt:ResourceTag/team", "values": ["platform"] } ] } ] } ``` Uma política de conta que permite a criação de contas de serviço e anexos de política de conta selecionados. As verificações de anexos exigem CRNs de identidade e de política: ```json theme={null} { "version": "2024-01-01", "statements": [{ "sid": "ManageTeamServiceAccounts", "effect": "allow", "actions": [ "iam:CreateServiceAccount", "iam:AttachPolicy", "iam:PutInlinePolicy" ], "resources": [ "crn:iam::my-account:service-account/*", "crn:iam::my-account:policy/team-*", "crn:iam::my-account:service-account/*/inline-policy/*" ] }] } ``` Suponha que o lead anexa `{"effect": "allow", "actions": ["*"], "resources": ["*"]}` a uma conta de serviço limitada. Essa conta de serviço ainda não pode tocar no IAM, não pode tocar em um recurso marcado para outra equipe e não pode alcançar nenhum serviço fora da computação e do armazenamento — o limite cruza todos esses serviços. A política alargada não é rejeitada; simplesmente não ultrapassa o limite máximo. Note o que este exemplo **não** faz: ele não permite que o lead adicione ou remova *limites*. Se pudessem, poderiam aumentar o seu próprio limite. Conceda a gestão de limites apenas a quem deve definir o limite máximo. ## Limite ou negação explícita? Ambos restringem, e não são intercambiáveis. Para limitar **um principal** enquanto deixa outra pessoa gerenciar suas políticas. É um limite máximo para a delegação. Recusar ações de correspondência mesmo quando outra política as permite. Uma negação supera qualquer permissão no mesmo domínio de política.