**Ajudar a melhorar esta página** 

Para contribuir com este guia de usuário, escolha o link **Editar esta página no GitHub**, disponível no painel direito de cada página.

# Criação de uma funcionalidade do kro por meio da AWS CLI
<a name="kro-create-cli"></a>

Este tópico descreve como criar uma funcionalidade do kro (Kube Resource Orchestrator) usando a AWS CLI.

## Pré-requisitos
<a name="_prerequisites"></a>
+  **AWS CLI**: versão `2.12.3` ou em versões posteriores. Para verificar a versão, execute `aws --version`. Para obter mais informações, consulte [Instalação](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) no Guia do Usuário da Interface de Linha de Comando AWS.
+  ** `kubectl` ** – uma ferramenta de linha de comando para trabalhar com clusters do Kubernetes. Para obter mais informações, consulte [Configurar o `kubectl` e o `eksctl`](install-kubectl.md).

## Etapa 1: criação de um perfil da funcionalidade do IAM
<a name="_step_1_create_an_iam_capability_role"></a>

Crie um arquivo de política de confiança:

```
cat > kro-trust-policy.json << 'EOF'
{
  "Version": "2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "capabilities.eks.amazonaws.com"
      },
      "Action": [
        "sts:AssumeRole",
        "sts:TagSession"
      ]
    }
  ]
}
EOF
```

Crie o perfil do IAM:

```
aws iam create-role \
  --role-name KROCapabilityRole \
  --assume-role-policy-document file://kro-trust-policy.json
```

**nota**  
Ao contrário do ACK e do Argo CD, o kro não requer permissões do IAM adicionais. O kro opera inteiramente no cluster e não faz chamadas de API da AWS. O perfil é exigido exclusivamente para configurar a relação de confiança com o serviço de funcionalidades do EKS.

## Etapa 2: criação da funcionalidade do kro
<a name="_step_2_create_the_kro_capability"></a>

Crie o recurso da funcionalidade do kro no cluster. Substitua *region-cod*e pela região da AWS em que seu cluster está localizado (por exemplo, `us-west-2`) e *my-cluster* pelo nome do seu cluster.

```
aws eks create-capability \
  --region region-code \
  --cluster-name my-cluster \
  --capability-name my-kro \
  --type KRO \
  --role-arn arn:aws:iam::$(aws sts get-caller-identity --query Account --output text):role/KROCapabilityRole \
  --delete-propagation-policy RETAIN
```

O comando é concluído de imediato, mas a funcionalidade demora algum tempo para se tornar ativa, conforme o EKS cria a infraestrutura e os componentes necessários para a funcionalidade. O EKS instalará as definições de recursos personalizados do Kubernetes relacionadas a essa funcionalidade no cluster durante o processo de criação.

**nota**  
Caso ocorra um erro indicando a inexistência do cluster ou falta de permissões, verifique o seguinte:  
Se o nome do cluster está correto
Se a AWS CLI está configurada para a região correta
Se você tem as permissões do IAM obrigatórias

## Etapa 3: verificação da ativação da funcionalidade
<a name="_step_3_verify_the_capability_is_active"></a>

Aguarde até que a funcionalidade se torne ativa. Substitua *region-code* pela região AWS em que seu cluster se encontra e substitua *my-cluster* pelo nome do seu cluster.

```
aws eks describe-capability \
  --region region-code \
  --cluster-name my-cluster \
  --capability-name my-kro \
  --query 'capability.status' \
  --output text
```

A funcionalidade estará pronta assim que o status mostrar `ACTIVE`.

Também é possível visualizar os detalhes completos da funcionalidade:

```
aws eks describe-capability \
  --region region-code \
  --cluster-name my-cluster \
  --capability-name my-kro
```

## Etapa 4: concessão de permissões para o gerenciamento de recursos do Kubernetes
<a name="_step_4_grant_permissions_to_manage_kubernetes_resources"></a>

Quando você cria um recurso kro, uma entrada de acesso do EKS é criada automaticamente com a `AmazonEKSKROPolicy`, o que permite que o kro gerencie ResourceGraphDefinitions e suas instâncias. Contudo, nenhuma permissão é concedida por padrão para criar os recursos subjacentes do Kubernetes (como implantações, serviços, ConfigMaps etc.) definidos em suas ResourceGraphDefinitions.

Esse design intencional segue o princípio de privilégio mínimo, em que definições de gráficos de recursos diferentes exigem permissões diferentes. Por exemplo: \$1 Uma ResourceGraphDefinition que crie somente ConfigMaps e Segredos precisa de permissões diferentes daquela que cria Implantações e Serviços \$1 Uma ResourceGraphDefinition que cria recursos de ACK precisa de permissões para esses recursos personalizados específicos \$1 Algumas ResourceGraphDefinitions só podem ler recursos existentes sem criar novos

É necessário configurar explicitamente as permissões de que o kro precisa com base nos recursos que suas ResourceGraphDefinitions gerenciarão.

### Configuração rápida
<a name="_quick_setup"></a>

Para começar rapidamente, testar ou desenvolver ambientes, use a `AmazonEKSClusterAdminPolicy`:

Obtenha o ARN do perfil da funcionalidade:

```
CAPABILITY_ROLE_ARN=$(aws eks describe-capability \
  --region region-code \
  --cluster-name my-cluster \
  --capability-name my-kro \
  --query 'capability.roleArn' \
  --output text)
```

Associe a política de administrador do cluster:

```
aws eks associate-access-policy \
  --region region-code \
  --cluster-name my-cluster \
  --principal-arn $CAPABILITY_ROLE_ARN \
  --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy \
  --access-scope type=cluster
```

**Importante**  
A `AmazonEKSClusterAdminPolicy` concede permissões abrangentes para criar e gerenciar todos os recursos do Kubernetes, incluindo a capacidade de criar qualquer tipo de recurso em todos os namespaces. Isso é conveniente para desenvolvimento e POCs, mas não deve ser usado em ambientes de produção. Para ambientes de produção, crie políticas de RBAC personalizadas que concedam somente as permissões necessárias para os recursos específicos que as ResourceGraphDefinitions gerenciarão. Para obter orientações sobre como configurar permissões de privilégio mínimo, consulte [Configuração de permissões do kro](kro-permissions.md) e [Considerações sobre segurança para funcionalidades do EKS](capabilities-security.md).

## Etapa 5: verificação da disponibilidade de recursos personalizados
<a name="_step_5_verify_custom_resources_are_available"></a>

Após a funcionalidade estar ativa, verifique se os recursos personalizados do kro estão disponíveis no cluster:

```
kubectl api-resources | grep kro.run
```

O tipo de recurso `ResourceGraphDefinition` deve aparecer na lista apresentada.

## Próximas etapas
<a name="_next_steps"></a>
+  [Conceitos do kro](kro-concepts.md): compreenda os conceitos do kro e a composição de recursos
+  [Conceitos do kro](kro-concepts.md): saiba mais sobre o SimpleSchema, expressões CEL e padrões de composição
+  [Como trabalhar com recursos de funcionalidade](working-with-capabilities.md): gerencie os recursos da funcionalidade do kro