As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá. # Pré-requisitos para habilitar o Monitoramento de runtime Para ativar o Runtime Monitoring e gerenciar o agente de GuardDuty segurança, você deve atender aos pré-requisitos de cada tipo de recurso que deseja monitorar para detecção de ameaças. Cada tipo de recurso tem pré-requisitos diferentes. Por exemplo, GuardDuty oferece suporte a diferentes distribuições de sistema operacional com base no tipo de recurso. Caso queira monitorar apenas os recursos do Amazon EC2, é necessário seguir os pré-requisitos das instâncias do Amazon EC2.. Caso opte por monitorar os recursos do Amazon EKS posteriormente, é preciso seguir os pré-requisitos específicos dos clusters do Amazon EKS. As seções a seguir incluem pré-requisitos com base no tipo de recurso. **Topics** + [Pré-requisitos para suporte de instância do Amazon EC2](prereq-runtime-monitoring-ec2-support.md) + [Pré-requisitos para suporte (somente para AWS Fargate Amazon ECS)](prereq-runtime-monitoring-ecs-support.md) + [Pré-requisitos para o suporte ao cluster do Amazon EKS](prereq-runtime-monitoring-eks-support.md) # Pré-requisitos para suporte de instância do Amazon EC2 Esta seção inclui os pré-requisitos para monitorar o comportamento de runtime das instâncias do Amazon EC2. Depois que esses pré-requisitos forem atendidos, consulte [Habilitando o GuardDuty monitoramento de tempo](runtime-monitoring-configuration.md). **Topics** + [Tornar as instâncias do EC2 gerenciadas por SSM (somente para configuração automatizada de agentes)](#ssm-managed-prereq-ec2) + [Validação dos requisitos de arquitetura](#validating-architecture-req-ec2) + [Validando a política de controle de serviço da sua organização em um ambiente de várias contas](#validate-organization-scp-ec2) + [Ao usar a configuração de agente automatizado](#runtime-ec2-prereq-automated-agent) + [Limite de CPU e memória para o GuardDuty agente](#ec2-cpu-memory-limits-gdu-agent) + [Próxima etapa](#next-step-after-prereq-ec2) ## Tornar as instâncias do EC2 gerenciadas por SSM (somente para configuração automatizada de agentes) GuardDuty usa AWS Systems Manager (SSM) para implantar, instalar e gerenciar automaticamente o agente de segurança em suas instâncias. Se você planeja instalar e gerenciar manualmente o GuardDuty agente, o SSM não é necessário. Para gerenciar suas instâncias do Amazon EC2 com o Systems Manager, consulte [Configurando o Systems Manager para instâncias do Amazon EC2](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-setting-up-ec2.html) no *Guia do usuário do AWS Systems Manager *. ## Validação dos requisitos de arquitetura A arquitetura da distribuição do sistema operacional pode afetar o comportamento do agente de GuardDuty segurança. Você deve atender aos seguintes requisitos para usar o Monitoramento de runtime para instâncias do Amazon EC2: + O suporte do kernel inclui `eBPF`, `Tracepoints` e `Kprobe`. Para arquiteturas de CPU, o Runtime Monitoring suporta AMD64 (`x64`) e ARM64 (Graviton2 e superior). [1](#runtime-monitoring-ec2-graviton-2-support) A tabela a seguir mostra a distribuição do sistema operacional que foi verificada para oferecer suporte ao agente GuardDuty de segurança para instâncias do Amazon EC2. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/guardduty/latest/ug/prereq-runtime-monitoring-ec2-support.html) 1. O Monitoramento de Runtime para recursos do Amazon EC2 não é compatível com a instância Graviton de primeira geração, como os tipos de instância A1. 1. Suporte para vários sistemas operacionais - GuardDuty verificou o suporte do Runtime Monitoring para a distribuição operacional listada na tabela anterior. Embora o agente GuardDuty de segurança possa ser executado em sistemas operacionais não listados na tabela anterior, a GuardDuty equipe não pode garantir o valor de segurança esperado. 1. Para qualquer versão do kernel, você deve definir o sinalizador `CONFIG_DEBUG_INFO_BTF` como `y` (isto é, *verdadeiro*). Isso é necessário para que o agente GuardDuty de segurança possa ser executado conforme o esperado. 1. Para as versões 5.10 e anteriores do kernel, o agente GuardDuty de segurança usa memória bloqueada na RAM (`RLIMIT_MEMLOCK`) para funcionar conforme o esperado. Se o `RLIMIT_MEMLOCK` valor do seu sistema estiver definido como muito baixo, GuardDuty recomenda definir limites rígidos e flexíveis para pelo menos 32 MB. Para obter informações sobre como verificar e modificar o valor de `RLIMIT_MEMLOCK` padrão, consulte [Visualização e atualização de valores de `RLIMIT_MEMLOCK`](#runtime-monitoring-ec2-modify-rlimit-memlock). 1. Para o Ubuntu 24.04, as versões 6.13 e 6.14 do kernel oferecem suporte somente às versões do agente EC2 1.9.2 e superiores. + Requisitos adicionais - Somente se você tiver o Amazon ECS/Amazon EC2 Para o Amazon ECS/Amazon EC2, recomendamos que você use a versão mais recente otimizada para Amazon ECS AMIs (datada de 29 de setembro de 2023 ou posterior) ou use a versão v1.77.0 do agente Amazon ECS. ### Visualização e atualização de valores de `RLIMIT_MEMLOCK` Quando o `RLIMIT_MEMLOCK` limite do seu sistema é definido como muito baixo, o agente de GuardDuty segurança pode não funcionar conforme projetado. GuardDuty recomenda que os limites rígidos e flexíveis sejam de pelo menos 32 MB. Se você não atualizar os limites, não GuardDuty conseguirá monitorar os eventos de tempo de execução do seu recurso. Quando `RLIMIT_MEMLOCK` está acima dos limites mínimos estabelecidos, torna-se opcional que você atualize esses limites. Você pode modificar o `RLIMIT_MEMLOCK` valor padrão antes ou depois de instalar o agente GuardDuty de segurança. **Para visualizar valores `RLIMIT_MEMLOCK`** 1. Executar `ps aux | grep guardduty`. Isso exibirá o ID do processo (`pid`). 1. Copie o ID do processo (`pid`) da saída do comando anterior. 1. Execute `grep "Max locked memory" /proc/pid/limits` após substituir o `pid` pelo ID do processo copiado da etapa anterior. Isso exibirá a memória máxima bloqueada para executar o agente GuardDuty de segurança. **Para atualizar valores `RLIMIT_MEMLOCK`** 1. Se o arquivo `/etc/systemd/system.conf.d/NUMBER-limits.conf` existir, comente a linha de `DefaultLimitMEMLOCK` desse arquivo. Esse arquivo define um `RLIMIT_MEMLOCK` padrão com alta prioridade, que substitui suas configurações no arquivo `/etc/systemd/system.conf`. 1. Abra o arquivo `/etc/systemd/system.conf` e remova o comentário da linha com `#DefaultLimitMEMLOCK=`. 1. Atualize o valor padrão fornecendo limites de `RLIMIT_MEMLOCK` rígidos e flexíveis de pelo menos 32 MB. A atualização deve ter a seguinte aparência: `DefaultLimitMEMLOCK=32M:32M`. O formato é `soft-limit:hard-limit`. 1. Executar `sudo reboot`. ## Validando a política de controle de serviço da sua organização em um ambiente de várias contas Se você configurou uma política de controle de serviços (SCP) para gerenciar permissões na sua organização, confirme se o limite de permissões permite a ação `guardduty:SendSecurityTelemetry`. É necessário para oferecer suporte GuardDuty ao Runtime Monitoring em diferentes tipos de recursos. Se você for uma conta de membro, conecte-se com o administrador delegado associado. Para obter informações sobre o gerenciamento SCPs de sua organização, consulte [Políticas de controle de serviços (SCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html). ## Ao usar a configuração de agente automatizado Para [Usar a configuração de agente automatizado (recomendado)](how-runtime-monitoring-works-ec2.md#use-automated-agent-config-ec2) isso, você Conta da AWS deve atender aos seguintes pré-requisitos: + Ao usar tags de inclusão com configuração automática de agentes, GuardDuty para criar uma associação SSM para uma nova instância, certifique-se de que a nova instância seja gerenciada por SSM e apareça no **Fleet Manager** no [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)console. + Ao usar tags de exclusão com configuração de agente automatizado: + Adicione a `false` tag`GuardDutyManaged`: antes de configurar o agente GuardDuty automatizado para sua conta. Certifique-se de adicionar a tag de exclusão às instâncias do Amazon EC2 antes de iniciá-las. Depois de habilitar a configuração automatizada do agente para o Amazon EC2, qualquer instância do EC2 que seja executada sem uma tag de exclusão será coberta GuardDuty pela configuração automática do agente. + Habilite a configuração **Permitir tags nos metadados** para suas instâncias. Essa configuração é necessária porque GuardDuty precisa ler a tag de exclusão do serviço de metadados da instância (IMDS) para determinar se ela deve excluir a instância da instalação do agente. Para obter mais informações, consulte [Habilitar o acesso a tags em metadados da instância](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/work-with-tags-in-IMDS.html#allow-access-to-tags-in-IMDS) no *Guia do usuário do Amazon EC2*. ## Limite de CPU e memória para o GuardDuty agente **Limite da CPU** O limite máximo de CPU para o agente GuardDuty de segurança associado às instâncias do Amazon EC2 é de 10% do total de núcleos de vCPU. Por exemplo, se sua instância do EC2 tiver 4 núcleos de vCPU, o agente de segurança poderá usar, no máximo, 40% do total disponível de 400%. **Limite de memória** Da memória associada à sua instância do Amazon EC2, há uma memória limitada que o agente de GuardDuty segurança pode usar. A tabela a seguir mostra o limite de memória. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/guardduty/latest/ug/prereq-runtime-monitoring-ec2-support.html) ## Próxima etapa A próxima etapa é configurar o Monitoramento de runtime e também gerenciar o agente de segurança (automática ou manualmente). # Pré-requisitos para suporte (somente para AWS Fargate Amazon ECS) Esta seção inclui os pré-requisitos para monitorar o comportamento de runtime de seus recursos do Fargate-Amazon ECS. Depois que esses pré-requisitos forem atendidos, consulte [Habilitando o GuardDuty monitoramento de tempo](runtime-monitoring-configuration.md). **Topics** + [Validação dos requisitos de arquitetura](#validating-architecture-req-ecs) + [Pré-requisitos para acesso à imagem do contêiner](#before-enable-runtime-monitoring-ecs) + [Validando a política de controle de serviço da sua organização em um ambiente de várias contas](#validate-organization-scp-ecs) + [Validação de permissões de perfis e limite de permissões de política](#guardduty-runtime-monitoring-ecs-permission-boundary) + [Limites de CPU e memória](#ecs-runtime-agent-cpu-memory-limits) ## Validação dos requisitos de arquitetura A plataforma que você usa pode afetar o suporte do agente GuardDuty de segurança GuardDuty no recebimento de eventos de tempo de execução de seus clusters do Amazon ECS. Você precisa validar que está usando uma das plataformas verificadas. **Considerações iniciais:** A AWS Fargate plataforma para seus clusters do Amazon ECS deve ser Linux. A versão da plataforma correspondente deve ser pelo menos`1.4.0` ou`LATEST`. Para obter mais informações sobre as versões de plataforma, consulte [Versões da plataforma Linux](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/platform-linux-fargate.html) no *Guia do desenvolvedor do Amazon Elastic Container Service*. As versões da plataforma Windows ainda não são suportadas. ### Plataformas verificadas A distribuição do sistema operacional e a arquitetura da CPU afetam o suporte fornecido pelo agente GuardDuty de segurança. A tabela a seguir mostra a configuração verificada para implantar o agente de GuardDuty segurança e configurar o Runtime Monitoring. | Distribuição do sistema operacional **[1](#runtime-monitoring-ecs-os-support)** | Suporte do kernel | Arquitetura de CPU x64 () AMD64 | Arquitetura da CPU Graviton () ARM64 | | --- | --- | --- | --- | | Linux | eBPF, Tracepoints, Kprobe | Compatível | Compatível | 1 Suporte para vários sistemas operacionais - GuardDuty verificou o suporte do Runtime Monitoring para a distribuição operacional listada na tabela anterior. Embora o agente GuardDuty de segurança possa ser executado em sistemas operacionais não listados na tabela anterior, a GuardDuty equipe não pode garantir o valor de segurança esperado. ## Pré-requisitos para acesso à imagem do contêiner Os pré-requisitos a seguir ajudam você a acessar a imagem do contêiner auxiliar GuardDuty a partir do repositório Amazon ECR. ### Requisitos de permissão A função de execução da tarefa exige determinadas permissões do Amazon Elastic Container Registry (Amazon ECR) para baixar a imagem do contêiner GuardDuty do agente de segurança: ``` ... "ecr:GetAuthorizationToken", "ecr:BatchCheckLayerAvailability", "ecr:GetDownloadUrlForLayer", "ecr:BatchGetImage", ... ``` Para restringir ainda mais as permissões do Amazon ECR, você pode adicionar o URI do repositório do Amazon ECR que hospeda o agente de GuardDuty segurança para (somente AWS Fargate Amazon ECS). Para obter mais informações, consulte [Agente de hospedagem de repositórios Amazon ECR GuardDuty](runtime-monitoring-ecr-repository-gdu-agent.md). Você pode usar a política ECSTask ExecutionRolePolicy gerenciada da [Amazon](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_execution_IAM_role.html) ou adicionar as permissões acima à sua `TaskExecutionRole` política. ### Configuração de definição de tarefas Ao criar ou atualizar os serviços do Amazon ECS, você precisa fornecer informações de sub-rede na definição da sua tarefa: Executar [CreateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateService.html)e [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html) APIs na *Amazon Elastic Container Service API Reference* exige que você passe as informações da sub-rede. Para obter mais informações, consulte [Definições da tarefa do Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definitions.html) no *Guia do desenvolvedor do Amazon Elastic Container Service*. ### Requisitos de conectividade de rede Você deve garantir a conectividade de rede para baixar a imagem do GuardDuty contêiner do Amazon ECR. Esse requisito é específico GuardDuty porque ele usa o Amazon ECR para hospedar seu agente de segurança. Dependendo da configuração da sua rede, você deve implementar uma das seguintes opções: **Opção 1 – usar o acesso à rede pública (se disponível)** Se suas tarefas do Fargate forem executadas em sub-redes com acesso de saída à Internet, nenhuma configuração de rede adicional será necessária. **Opção 2 – usar endpoints da Amazon VPC (para sub-redes privadas)** Se suas tarefas do Fargate forem executadas em sub-redes privadas sem acesso à Internet, você deverá configurar VPC endpoints para ECR para garantir que o URI do repositório ECR que hospeda o agente de segurança esteja acessível pela rede. GuardDuty Sem esses endpoints, as tarefas em sub-redes privadas não podem baixar a imagem do GuardDuty contêiner. Para obter instruções de configuração do endpoint da VPC, consulte [Criação dos endpoints da VPC para o Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/vpc-endpoints.html#ecr-setting-up-vpc-create) no *Guia do usuário do Amazon Elastic Container Registry*. Para obter informações sobre como permitir que o Fargate baixe o GuardDuty contêiner, consulte Usando imagens do [Amazon ECR com o Amazon ECS no Guia do usuário do Amazon Elastic](https://docs.aws.amazon.com/AmazonECR/latest/userguide/ECR_on_ECS.html) *Container Registry*. ### Configuração do security group As imagens do GuardDuty contêiner estão no Amazon ECR e exigem acesso ao Amazon S3. Esse requisito é específico para baixar imagens de contêiner do Amazon ECR. Para tarefas com acesso restrito à rede, você deve configurar seus grupos de segurança para permitir acesso ao S3. Adicione uma regra de saída em seu grupo de segurança que permita o tráfego para a [lista de prefixos gerenciados do S3 (`pl-xxxxxxxx`) na porta 443](https://docs.aws.amazon.com/vpc/latest/privatelink/gateway-endpoints.html#gateway-endpoint-security). Para obter uma regra de saída, consulte [Configurar regras de grupo de segurança](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-security-group-rules.html) no *Guia do usuário da Amazon VPC*. Para visualizar suas listas AWS de prefixos gerenciados no console ou descrevê-las usando AWS Command Line Interface (AWS CLI), consulte listas de [prefixos AWS gerenciados no](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-aws-managed-prefix-lists.html) Guia do usuário da Amazon *VPC*. ## Validando a política de controle de serviço da sua organização em um ambiente de várias contas Esta seção explica como validar suas configurações de política de controle de serviços (SCP) para garantir que o Monitoramento de Runtime funcione conforme esperado na sua organização. Se você configurou uma ou mais políticas de controle de serviços para gerenciar permissões na sua organização, você deve confirmar se ela não nega a ação `guardduty:SendSecurityTelemetry`. Para obter informações sobre como SCPs funciona, consulte a [avaliação do SCP](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_evaluation.html) no *Guia do AWS Organizations Usuário*. Se você for uma conta de membro, conecte-se com o administrador delegado associado. Para obter informações sobre o gerenciamento SCPs da sua organização, consulte [Políticas de controle de serviço (SCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) no *Guia AWS Organizations do usuário*. Execute as etapas a seguir para tudo o SCPs que você configurou em seu ambiente de várias contas: **Para confirmar se `guardduty:SendSecurityTelemetry` não está negado no SCP** 1. Faça login no console Organizations em [https://console.aws.amazon.com/organizations/](https://console.aws.amazon.com/organizations/). Você deve fazer login como um perfil do IAM ou como o usuário-raiz [(não recomendado)](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#lock-away-credentials) na conta gerencial da organização. 1. No painel de navegação à esquerda, selecione **Policies (Políticas)**. Em seguida, em **Tipos de políticas compatíveis**, selecione **Políticas de controle de serviços**. 1. Na página **Políticas de controle de serviços**, escolha o nome da política que deseja validar. 1. Na página de detalhes da política, veja o **Conteúdo** dessa política. Confirme que ele não nega a ação `guardduty:SendSecurityTelemetry`. A política de SCP a seguir é um exemplo para *não negar* a ação `guardduty:SendSecurityTelemetry`: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "guardduty:SendSecurityTelemetry" ], "Resource": "*" } ] } ``` ------ Se sua política negar essa ação, você deverá atualizar a política. Para obter mais informações, consulte [Atualização de uma política de controle de serviços (SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_policies_update.html#update_policy) no *Guia do usuário do AWS Organizations *. ## Validação de permissões de perfis e limite de permissões de política Use as etapas a seguir para confirmar se os limites de permissões associados ao perfil e sua política **não** restringem a ação `guardduty:SendSecurityTelemetry`. **Para visualizar o limite de permissões para perfis e sua política** 1. Faça login no Console de gerenciamento da AWS e abra o console do IAM em [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/). 1. No painel de navegação esquerdo, em **Gerenciamento de acesso**, escolha **Perfis**. 1. Na página **Perfis**, selecione o perfil *`TaskExecutionRole`* que você pode ter criado. 1. Na página do perfil selecionado, na guia **Permissões**, expanda o nome da política associada a esse perfil. Em seguida, confirme se essa política não restringe `guardduty:SendSecurityTelemetry`. 1. Se o **limite de permissões** estiver definido, expanda essa seção. Em seguida, expanda cada política para verificar se ela não restringe a ação `guardduty:SendSecurityTelemetry`. A política deve ter a seguinte aparência: [Example SCP policy](#ecs-runtime-scp-not-deny-policy-example). Conforme necessário, execute uma das seguintes ações: + Para modificar a política, selecione **Editar**. Na página **Modificar permissões** dessa política, atualize a política no **Editor de políticas**. Confirme se o esquema JSON permanece válido. Em seguida, escolha **Próximo**. Em seguida, você poderá revisar e salvar as alterações. + Para alterar esse limite de permissões e escolher outro limite, escolha **Alterar limite**. + Para remover esse limite de permissões, escolha **Remover limite**. Para obter informações sobre como gerenciar políticas, consulte [Políticas e permissões no AWS Identity and Access Management](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) no *Guia do usuário do IAM*. ## Limites de CPU e memória Na definição de tarefa Fargate, você deve especificar o valor de CPU e de memória no nível de tarefa. A tabela a seguir mostra as combinações válidas de valores de CPU e memória em nível de tarefa e o limite máximo de memória do agente de GuardDuty segurança correspondente para o GuardDuty contêiner. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/guardduty/latest/ug/prereq-runtime-monitoring-ecs-support.html) Depois de habilitar o Monitoramento de runtime e avaliar se o status da cobertura do seu cluster é **Íntegro**, você pode configurar e visualizar as métricas do Container insight. Para obter mais informações, [Como configurar o monitoramento no cluster do Amazon ECS](runtime-monitoring-setting-cpu-mem-monitoring.md#ecs-runtime-cpu-memory-monitoring-agent). A próxima etapa é configurar o Monitoramento de runtime e também configurar o agente de segurança. # Pré-requisitos para o suporte ao cluster do Amazon EKS Esta seção inclui os pré-requisitos para monitorar o comportamento de runtime de seus recursos do Amazon EKS. Esses pré-requisitos são cruciais para que o GuardDuty agente funcione conforme o esperado. Depois que esses pré-requisitos forem atendidos, consulte [Habilitando o GuardDuty monitoramento de tempo](runtime-monitoring-configuration.md) para começar a monitorar seus recursos. ## Suporte para recursos do Amazon EKS O monitoramento de runtime **é compatível** com clusters do Amazon EKS em execução em instâncias do Amazon EC2 e do Amazon EKS Auto Mode. O Monitoramento de Runtime **não é compatível** com clusters do Amazon EKS com Amazon EKS Hybrid Nodes e aqueles em execução no AWS Fargate. Para ter mais informações sobre recursos do Amazon EKS, consulte [O que é o Amazon EKS?](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html) no **Guia do usuário do Amazon EKS**. ## Validação dos requisitos de arquitetura A plataforma que você usa pode afetar o suporte do GuardDuty Security Agent GuardDuty no recebimento de eventos de tempo de execução de seus clusters EKS. Você precisa validar que está usando uma das plataformas verificadas. Se você estiver gerenciando o GuardDuty agente manualmente, certifique-se de que a versão do Kubernetes seja compatível com a versão do GuardDuty agente que está em uso no momento. ### Plataformas verificadas A distribuição do sistema operacional, a versão do kernel e a arquitetura da CPU afetam o suporte fornecido pelo agente GuardDuty de segurança. O suporte do kernel inclui `eBPF`, `Tracepoints` e `Kprobe`. Para arquiteturas de CPU, o Runtime Monitoring suporta AMD64 (`x64`) e ARM64 (Graviton2 e superior). [1](#runtime-monitoring-eks-graviton-2-support) A tabela a seguir mostra a configuração verificada para implantar o agente de GuardDuty segurança e configurar o EKS Runtime Monitoring. | Distribuição do sistema operacional **[2](#runtime-monitoring-eks-os-support)** | Versão do kernel **[3](#runtime-monitoring-eks-kernel-version-required-flag)** | Versão compatível do Kubernetes | | --- | --- | --- | | Foguete de garrafas | 5.4, 5.10, 5.15, 6.1 [4](#v6.1-kernel-dns-findings-unsupported-eks) | v1.23 - v1.35 | | Ubuntu | 5.4, 5.10, 5.15, 6.1 [4](#v6.1-kernel-dns-findings-unsupported-eks) | v1.21 - v1.35 | | Amazon Linux 2 | 5.4, 5.10, 5.15, 6.1 [4](#v6.1-kernel-dns-findings-unsupported-eks) | v1.21 - v1.35 | | Amazon Linux 2023 *[5](#runtime-eks-al2023-support-v1.6.0)* | 5.4, 5.10, 5.15, 6.1 [4](#v6.1-kernel-dns-findings-unsupported-eks) | v1.21 - v1.35 | | RedHat 9.4 | 5.14 [4](#v6.1-kernel-dns-findings-unsupported-eks) | v1.21 - v1.35 | | Fedora 34 | 5.11, 5.17 | v1.21 - v1.35 | | Fedora 40 | 6.8 | v1.28 - v1.35 | | Fedora 41 | 6.12 | v1.28 - v1.35 | | CentOS Stream 9 | 5.14 | v1.21 - v1.35 | 1. O monitoramento de runtime para clusters do Amazon EKS não é compatível com a instância Graviton de primeira geração, como os tipos de instância A1. 1. Suporte para vários sistemas operacionais - GuardDuty verificou o suporte do Runtime Monitoring para a distribuição operacional listada na tabela anterior. Embora o agente GuardDuty de segurança possa ser executado em sistemas operacionais não listados na tabela anterior, a GuardDuty equipe não pode garantir o valor de segurança esperado. 1. Para qualquer versão do kernel, você deve definir o sinalizador `CONFIG_DEBUG_INFO_BTF` como `y` (isto é, *verdadeiro*). Isso é necessário para que o agente GuardDuty de segurança possa ser executado conforme o esperado. 1. Atualmente, com a versão Kernel`6.1`, não é GuardDuty possível gerar [GuardDuty Tipos de descoberta de monitoramento de tempo de execução](findings-runtime-monitoring.md) que estejam relacionados a. [Eventos do Sistema de Nomes de Domínio (DNS)](runtime-monitoring-collected-events.md#eks-runtime-dns-events) 1. O Runtime Monitoring é compatível AL2023 com o lançamento do agente GuardDuty de segurança v1.6.0 e superior. Para obter mais informações, consulte [GuardDuty versões do agente de segurança para recursos do Amazon EKS](runtime-monitoring-agent-release-history.md#eks-runtime-monitoring-agent-release-history). #### Versões do Kubernetes suportadas pelo agente de segurança GuardDuty A tabela a seguir mostra as versões do Kubernetes para seus clusters EKS que são compatíveis com o agente de GuardDuty segurança. | Versão complementar do agente de GuardDuty segurança Amazon EKS | Versão do Kubernetes | | --- | --- | | v1.12.1 (mais recente - v1.12.1-eksbuild.2) | 1,28 - 1,35 | | v1.11.0 (mais recente - v1.11.0-eksbuild.4) | 1,28 - 1,34 | | v1.10.0 (mais recente – v1.10.0-eksbuild.2) | 1,21 - 1,33 | | v1.9.0 (mais recente – v1.9.0-eksbuild.2) v1.8.1 (mais recente – v1.8.1-eksbuild.2) | 1,21 - 1,32 | | v1.7.1 v1.7.0 v1.6.1 | 1,21 - 1,31 | | v1.6.0 v1.5.0 v1.4.1 v1.4.0 v1.3.1 | 1,21 - 1,29 | | v1.3.0 v1.2.0 | 1,21 - 1,28 | | v1.1.0 | 1,21 - 1,26 | | v1.0.0 | 1.21 - 1.25 | Algumas das versões do agente de GuardDuty segurança chegarão ao fim do suporte padrão. Para obter informações sobre as versões de lançamento do agente, consulte [GuardDuty versões do agente de segurança para recursos do Amazon EKS](runtime-monitoring-agent-release-history.md#eks-runtime-monitoring-agent-release-history). ### Limites de CPU e memória A tabela a seguir mostra os limites de CPU e memória do complemento Amazon EKS para GuardDuty (`aws-guardduty-agent`). | Parâmetro | Limite mínimo | Limite máximo | | --- | --- | --- | | CPU | 200 m | 1000 m | | Memória | 256 Mi | 1024 Mi | Quando você usa a versão 1.5.0 ou superior do complemento Amazon EKS, GuardDuty fornece a capacidade de configurar o esquema complementar para seus valores de CPU e memória. Para obter informações sobre o intervalo de configuração, consulte [Parâmetros e valores configuráveis](guardduty-configure-security-agent-eks-addon.md#gdu-eks-addon-configure-parameters-values). Depois de ativar o Monitoramento de runtime do EKS e avaliar o status de cobertura dos seus clusters do EKS, você pode configurar e visualizar as métricas de insights do contêiner. Para obter mais informações, consulte [Configurar o monitoramento da CPU e da memória](runtime-monitoring-setting-cpu-mem-monitoring.md). ## Validando sua política de controle de serviço da organização Se você configurou uma política de controle de serviços (SCP) para gerenciar permissões em sua organização, verifique se o limite de permissões não é restritivo `guardduty:SendSecurityTelemetry`. É necessário para oferecer suporte GuardDuty ao Runtime Monitoring em diferentes tipos de recursos. Se você for uma conta de membro, conecte-se com o administrador delegado associado. Para obter informações sobre o gerenciamento SCPs de sua organização, consulte [Políticas de controle de serviços (SCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html).