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á. # Usando o Amazon EMR no EKS com AWS Lake Formation para controle de acesso refinado Com o Amazon EMR versão 7.7 e superior, você pode aproveitar o AWS Lake Formation para aplicar controles de acesso refinados nas tabelas do AWS Glue Data Catalog que são apoiadas por buckets do Amazon S3. Esse recurso permite configurar controles de acesso em nível de tabela, linha, coluna e célula para consultas de leitura em Trabalhos Spark do Amazon EMR no EKS. **Topics** + [Como o Amazon EMR no EKS funciona com AWS o Lake Formation](security_iam_fgac-lf-works.md) + [Habilitar o Lake Formation com o Amazon EMR no EKS](security_iam_fgac-lf-enable.md) + [Considerações e limitações](security_iam_fgac-considerations.md) + [Solução de problemas](security_iam_fgac-troubleshooting.md) # Como o Amazon EMR no EKS funciona com AWS o Lake Formation O uso do Amazon EMR no EKS com o Lake Formation permite aplicar uma camada de permissões em cada trabalho do Spark para aplicar o controle de permissões do Lake Formation quando o Amazon EMR no EKS executa trabalhos. O Amazon EMR on EKS usa [perfis de recursos do Spark](https://spark.apache.org/docs/latest/api/java/org/apache/spark/resource/ResourceProfile.html) para criar dois perfis para executar trabalhos de forma efetiva. O perfil do usuário executa o código fornecido pelo usuário, enquanto o perfil do sistema impõe as políticas do Lake Formation. Cada trabalho habilitado para o Lake Formation utiliza dois drivers do Spark, um para o perfil do usuário e outro para o perfil do sistema. Para obter mais informações, consulte O que é o [AWS Lake Formation](https://docs.aws.amazon.com/lake-formation/latest/dg/what-is-lake-formation.html). Veja a seguir uma visão geral de alto nível sobre como o Amazon EMR no EKS obtém acesso aos dados protegidos pelas políticas de segurança do Lake Formation. ![\[Segurança dos trabalhos por meio do Lake Formation\]](http://docs.aws.amazon.com/pt_br/emr/latest/EMR-on-EKS-DevelopmentGuide/images/fgac_diagram_eks_spark.png) As etapas a seguir descrevem este processo: 1. Um usuário envia um Spark Job para um Amazon EMR habilitado para AWS Lake Formation no cluster virtual EKS. 1. O serviço Amazon EMR on EKS configura o driver do usuário e executa o trabalho no perfil do usuário. O Driver do usuário executa uma versão simplificada do Spark que não tem capacidade para iniciar tarefas, solicitar executores, acessar o Amazon S3 ou o Catálogo de dados do Glue. Ele apenas cria um plano de trabalho. 1. O serviço Amazon EMR no EKS configura um segundo driver chamado driver do sistema e o executa no perfil do sistema (com uma identidade privilegiada). O Amazon EKS configura um canal TLS criptografado entre os dois drivers para comunicação. O driver do usuário usa o canal para enviar os planos de trabalho ao driver do sistema. O driver do sistema não executa o código enviado pelo usuário. Ela executa o Spark completo e se comunica com o Amazon S3 e com o Catálogo de dados para acesso aos dados. Ele solicita executores e compila o plano de trabalho em uma sequência de estágios de execução. 1. O serviço Amazon EMR no EKS executa as etapas nos executores. O código do usuário em qualquer estágio é executado exclusivamente nos executores do perfil do usuário. 1. Os estágios que lêem dados das tabelas do Catálogo de dados protegidas pelo Lake Formation ou que aplicam filtros de segurança são delegados aos executores do sistema. # Habilitar o Lake Formation com o Amazon EMR no EKS Com o Amazon EMR versão 7.7 e superior, você pode aproveitar o AWS Lake Formation para aplicar controles de acesso refinados nas tabelas do catálogo de dados que são apoiadas pelo Amazon S3. Esse recurso permite configurar controles de acesso em nível de tabela, linha, coluna e célula para consultas de leitura em Trabalhos Spark do Amazon EMR no EKS. Esta seção aborda como criar uma configuração de segurança e configurar o Lake Formation para funcionar com o Amazon EMR. Ele também descreve como criar um cluster virtual com a configuração de segurança que você criou para o Lake Formation. Essas seções devem ser concluídas em sequência. ## Etapa 1: Configurar permissões em nível de coluna, linha ou célula com base no Lake Formation Primeiro, para aplicar permissões em nível de linha e coluna com o Lake Formation, o administrador do data lake do Lake Formation deve definir a tag de **LakeFormationAuthorizedCaller**sessão. O Lake Formation usa essa etiqueta de sessão para autorizar os chamadores e fornecer acesso ao data lake. Navegue até o console do AWS Lake Formation e selecione a opção **Configurações de integração de aplicativos** na seção **Administração** na barra lateral. Em seguida, marque a caixa **Permitir que mecanismos externos filtrem dados em locais do Amazon S3 registrados no Lake Formation**. Adicione a **AWS conta em IDs ** que os Spark Jobs seriam executados e os **valores da tag Session**. ![\[Configurações de integração de aplicações\]](http://docs.aws.amazon.com/pt_br/emr/latest/EMR-on-EKS-DevelopmentGuide/images/application_integration_settings_fgac.png) Observe que a tag de **LakeFormationAuthorizedCaller**sessão passada aqui é passada **SecurityConfiguration**posteriormente quando você configura as funções do IAM, na seção 3. ## Etapa 2: Configurar permissões de RBAC do EKS Em segundo lugar, você configura permissões para controle de acesso baseado em perfil. ### Fornecer permissões do cluster do EKS ao serviço Amazon EMR no EKS O serviço Amazon EMR no EKS deve ter permissões de perfil de cluster do EKS para que possa criar permissões entre namespaces para que o driver do sistema execute executores de usuário no namespace do usuário. **Criar perfil de cluster** Este exemplo define permissões para um conjunto de recursos. ``` vim emr-containers-cluster-role.yaml --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: emr-containers rules: - apiGroups: [""] resources: ["namespaces"] verbs: ["get"] - apiGroups: [""] resources: ["serviceaccounts", "services", "configmaps", "events", "pods", "pods/log"] verbs: ["get", "list", "watch", "describe", "create", "edit", "delete", "deletecollection", "annotate", "patch", "label"] - apiGroups: [""] resources: ["secrets"] verbs: ["create", "patch", "delete", "watch"] - apiGroups: ["apps"] resources: ["statefulsets", "deployments"] verbs: ["get", "list", "watch", "describe", "create", "edit", "delete", "annotate", "patch", "label"] - apiGroups: ["batch"] resources: ["jobs"] verbs: ["get", "list", "watch", "describe", "create", "edit", "delete", "annotate", "patch", "label"] - apiGroups: ["extensions", "networking.k8s.io"] resources: ["ingresses"] verbs: ["get", "list", "watch", "describe", "create", "edit", "delete", "annotate", "patch", "label"] - apiGroups: ["rbac.authorization.k8s.io"] resources: ["clusterroles","clusterrolebindings","roles", "rolebindings"] verbs: ["get", "list", "watch", "describe", "create", "edit", "delete", "deletecollection", "annotate", "patch", "label"] - apiGroups: [""] resources: ["persistentvolumeclaims"] verbs: ["get", "list", "watch", "describe", "create", "edit", "delete", "deletecollection", "annotate", "patch", "label"] - apiGroups: ["kyverno.io"] resources: ["clusterpolicies"] verbs: ["create", "delete"] --- ``` ``` kubectl apply -f emr-containers-cluster-role.yaml ``` **Criar vinculações de perfis de cluster** ``` vim emr-containers-cluster-role-binding.yaml --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: emr-containers subjects: - kind: User name: emr-containers apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: emr-containers apiGroup: rbac.authorization.k8s.io --- ``` ``` kubectl apply -f emr-containers-cluster-role-binding.yaml ``` ### Fornecer acesso ao namespace ao serviço Amazon EMR no EKS Crie dois namespaces do Kubernetes, um para o driver e executores do usuário e outro para o driver e executores do sistema, e habilite o acesso ao serviço Amazon EMR no EKS para enviar trabalhos nos namespaces do usuário e do sistema. Siga o guia existente para fornecer acesso a cada namespace, disponível em [Habilitar acesso ao cluster usando `aws-auth`](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-cluster-access.html#setting-up-cluster-access-aws-auth). ## Etapa 3: Configurar perfis do IAM para componentes de perfil de usuário e sistema Em terceiro lugar, você define perfis para componentes específicos. Um trabalho Spark habilitado para o Lake Formation tem dois componentes: usuário e sistema. O driver e os executores do usuário são executados no namespace do usuário e estão vinculados ao JobExecutionRole que é passado na API. StartJobRun O driver e os executores do sistema são executados no namespace System e estão vinculados à função. **QueryEngine** ### Configurar o perfil do mecanismo de consulta A QueryEngine função está vinculada aos componentes do System Space e teria permissões para assumir a tag **JobExecutionRole**with **LakeFormationAuthorizedCaller**Session. A Política de permissões do IAM do perfil do Mecanismo de consulta é a seguinte: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AssumeJobRoleWithSessionTagAccessForSystemDriver", "Effect": "Allow", "Action": [ "sts:AssumeRole", "sts:TagSession" ], "Resource": [ "arn:aws:iam::*:role/JobExecutionRole" ], "Condition": { "StringLike": { "aws:RequestTag/LakeFormationAuthorizedCaller": "EMR on EKS Engine" } } }, { "Sid": "AssumeJobRoleWithSessionTagAccessForSystemExecutor", "Effect": "Allow", "Action": [ "sts:AssumeRole" ], "Resource": [ "arn:aws:iam::*:role/JobExecutionRole" ] }, { "Sid": "CreateCertificateAccessForTLS", "Effect": "Allow", "Action": [ "emr-containers:CreateCertificate" ], "Resource": [ "*" ] } ] } ``` ------ Configure a política de confiança do perfil do Mecanismo de consulta para confiar no namespace do sistema Kubernetes. ``` aws emr-containers update-role-trust-policy \ --cluster-name eks cluster \ --namespace eks system namespace \ --role-name query_engine_iam_role_name ``` Para obter mais informações, consulte [Atualizar a política de confiança de perfis](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-trust-policy.html). ### Configurar o perfil de execução do trabalho As permissões do Lake Formation controlam o acesso aos recursos do AWS Glue Data Catalog, aos locais do Amazon S3 e aos dados subjacentes nesses locais. As permissões do IAM controlam o acesso ao Lake Formation, ao AWS Glue APIs e aos recursos. Embora você possa ter a permissão do Lake Formation para acessar uma tabela no Catálogo de dados (SELECT), a operação falhará se você não tiver a permissão do IAM em operações de API `glue:Get*`. Política de permissões do IAM de **JobExecutionRole**: A **JobExecution**função deve ter as declarações de política em sua política de permissões. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "GlueCatalogAccess", "Effect": "Allow", "Action": [ "glue:Get*", "glue:Create*", "glue:Update*" ], "Resource": [ "*" ] }, { "Sid": "LakeFormationAccess", "Effect": "Allow", "Action": [ "lakeformation:GetDataAccess" ], "Resource": [ "*" ] }, { "Sid": "CreateCertificateAccessForTLS", "Effect": "Allow", "Action": [ "emr-containers:CreateCertificate" ], "Resource": [ "*" ] } ] } ``` ------ Política de confiança do IAM para **JobExecutionRole**: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "TrustQueryEngineRoleForSystemDriver", "Effect": "Allow", "Action": [ "sts:AssumeRole", "sts:TagSession" ], "Resource": [ "arn:aws:iam::*:role/QueryExecutionRole" ], "Condition": { "StringLike": { "aws:RequestTag/LakeFormationAuthorizedCaller": "EMR on EKS Engine" } } }, { "Sid": "TrustQueryEngineRoleForSystemExecutor", "Effect": "Allow", "Action": [ "sts:AssumeRole" ], "Resource": [ "arn:aws:iam::*:role/QueryEngineRole" ] } ] } ``` ------ Configure a política de confiança do Perfil de execução de trabalho para confiar no namespace de usuário do Kubernetes: ``` aws emr-containers update-role-trust-policy \ --cluster-name eks cluster \ --namespace eks User namespace \ --role-name job_execution_role_name ``` Para obter mais informações, consulte [Atualizar a política de confiança do perfil de execução do trabalho](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-trust-policy.html). ## Etapa 4: Definir a configuração de segurança Para executar um trabalho habilitado para o Lake Formation, você deve criar uma configuração de segurança. ``` aws emr-containers create-security-configuration \ --name 'security-configuration-name' \ --security-configuration '{ "authorizationConfiguration": { "lakeFormationConfiguration": { "authorizedSessionTagValue": "SessionTag configured in LakeFormation", "secureNamespaceInfo": { "clusterId": "eks-cluster-name", "namespace": "system-namespace-name" }, "queryEngineRoleArn": "query-engine-IAM-role-ARN" } } }' ``` Certifique-se de que a etiqueta de sessão passada no campo **authorizedSessionTagValue** possa autorizar o Lake Formation. Defina o valor como aquele configurado no Lake Formation, em [Etapa 1: Configurar permissões em nível de coluna, linha ou célula com base no Lake Formation](#security_iam_fgac-lf-enable-permissions). ## Etapa 5: Criar um cluster virtual Crie um cluster virtual do Amazon EMR no EKS com uma configuração de segurança. ``` aws emr-containers create-virtual-cluster \ --name my-lf-enabled-vc \ --container-provider '{ "id": "eks-cluster", "type": "EKS", "info": { "eksInfo": { "namespace": "user-namespace" } } }' \ --security-configuration-id SecurityConfiguraionId ``` Certifique-se de que o **SecurityConfiguration**ID da etapa anterior seja passado, para que a configuração de autorização do Lake Formation seja aplicada a todos os trabalhos em execução no cluster virtual. Para obter mais informações, consulte [Registrar o cluster do Amazon EKS no Amazon EMR](). ## Etapa 6: Enviar um Job no FGAC Enabled VirtualCluster O processo de envio de trabalhos é o mesmo para trabalhos pertencentes ou não ao Lake Formation. Para obter mais informações, consulte [Enviar uma execução de trabalho com o `StartJobRun`](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/emr-eks-jobs-submit.html). O driver Spark, o executor e os registros de eventos do driver do sistema são armazenados no bucket S3 da conta de AWS serviço para depuração. Recomendamos configurar uma chave KMS gerenciada pelo cliente no Job Run para criptografar todos os registros armazenados no service bucket. AWS Para obter mais informações sobre como habilitar a criptografia de logs, consulte [Criptografar logs do Amazon EMR no EKS](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/security_iam_fgac-logging-kms.html). # Considerações e limitações Observe as seguintes considerações e limitações ao usar o Lake Formation com o Amazon EMR no EKS: + O Amazon EMR no EKS oferece suporte ao controle de acesso refinado por meio do Lake Formation apenas para os formatos de tabela Apache Hive, tabela do Iceberg, Apache Hudi e Delta. Os formatos do Apache Hive incluem Parquet, ORC e xSV. + `DynamicResourceAllocation` está habilitado por padrão e `DynamicResourceAllocation` não pode ser desabilitado para trabalhos do Lake Formation. Como o valor padrão da configuração `spark.dynamicAllocation.maxExecutors` do DRA é infinito, configure um valor adequado com base na sua workload. + Trabalhos habilitados para Lake Formation não são compatíveis com o uso de imagens personalizadas do EMR no EKS no driver do sistema e nos executores do sistema. + Você só pode usar o Lake Formation com trabalhos do Spark. + O EMR no EKS with Lake Formation oferece suporte apenas a uma única sessão do Spark durante todo o trabalho. + O EMR no EKS com Lake Formation só oferece suporte a consultas de tabelas entre contas compartilhadas por meio de links de recursos. + As seguintes opções não são compatíveis: + Conjuntos de dados distribuídos resilientes (RDD) + Streaming do Spark + Gravação com as permissões concedidas pelo Lake Formation + Controle de acesso para colunas aninhadas + O EMR no EKS bloqueia funcionalidades que podem prejudicar o isolamento completo do driver do sistema, incluindo as seguintes: + UDTs, Hive UDFs e qualquer função definida pelo usuário que envolva classes personalizadas + Fontes de dados personalizadas + Fornecimento de JARs adicionais para o comando `ANALYZE TABLE` da extensão, conector ou metastore do Spark + Para impor controles de acesso, `EXPLAIN PLAN` e operações de DDL, como `DESCRIBE TABLE`, não expõem informações restritas. + O Amazon EMR no EKS restringe o acesso aos logs do driver do sistema Spark em trabalhos habilitados para o Lake Formation. Como o driver do sistema é executado com mais acesso, os eventos e logs que o driver do sistema gera podem incluir informações confidenciais. Para evitar que usuários ou códigos não autorizados acessem esses dados confidenciais, o EMR no EKS desabilitou o acesso aos logs do driver do sistema. Para solucionar problemas, entre em contato com AWS o suporte. + Se você tiver registrado um local de tabela com o Lake Formation, o caminho de acesso aos dados passa pelas credenciais armazenadas no Lake Formation, independentemente da permissão do IAM para o perfil de execução de tarefas do EMR no EKS. Se você configurar incorretamente o perfil registrado com a localização da tabela, os trabalhos enviados que usam o perfil com a permissão do IAM para o S3 na localização da tabela falharão. + Gravar em uma tabela do Lake Formation usa a permissão do IAM em vez das permissões concedidas pelo Lake Formation. Se o perfil de execução do trabalho tiver as permissões necessárias do S3, será possível usá-lo para executar operações de gravação. Observe estas considerações e limitações ao usar o Apache Iceberg: + Você só pode usar o Apache Iceberg com o catálogo de sessões e não com catálogos nomeados arbitrariamente. + As tabelas do Iceberg registradas no Lake Formation oferecem suporte apenas às tabelas de metadados `history`, `metadata_log_entries`, `snapshots`, `files`, `manifests` e `refs`. O Amazon EMR oculta as colunas que podem conter dados confidenciais, como `partitions`, `path` e `summaries`. Essa limitação não se aplica às tabelas do Iceberg que não estão registradas no Lake Formation. + As tabelas que você não registra no Lake Formation oferecem suporte a todos os procedimentos armazenados do Iceberg. Os procedimentos `register_table` e `migrate` não são compatíveis com nenhuma tabela. + Recomendamos que você use o Iceberg DataFrameWriter V2 em vez do V1. Para obter mais informações, consulte [Noções básicas sobre os conceitos e a terminologia do Amazon EMR no EKS](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/emr-eks-concepts.html) e [Habilitar acesso ao cluster para o Amazon EMR no EKS](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-cluster-access.html). ## Aviso legal para administradores de dados **nota** Ao conceder acesso aos recursos do Lake Formation a um perfil do IAM para o EMR no EKS, você deve garantir que o administrador ou operador do cluster do EMR seja um administrador confiável. Isso é particularmente relevante para os recursos do Lake Formation que são compartilhados entre várias organizações e AWS contas. ## Responsabilidades dos administradores do EKS + O namespace `System` deve ser protegido. Nenhum usuário, recurso, entidade ou ferramenta teria permissão para ter quaisquer permissões de RBAC do Kubernetes sobre os recursos do Kubernetes no namespace `System`. + Nenhum usuário, recurso ou entidade, exceto o serviço EMR no EKS, deve ter acesso a `CREATE` para POD, CONFIG\$1MAP e SECRET no namespace `User`. + Drivers `System` e executores `System` contêm dados sensíveis. Portanto, eventos Spark, logs de driver Spark e logs de executor Spark no namespace `System` não devem ser encaminhados para sistemas externos de armazenamento de logs. # Solução de problemas ## Registro em log O EMR no EKS usa perfis de recursos do Spark para dividir a execução do trabalho. O Amazon EMR no EKS usa o perfil do usuário para executar o código fornecido, enquanto o perfil do sistema impõe as políticas do Lake Formation. Você pode acessar os registros dos contêineres executados como perfil de usuário configurando a StartJobRun solicitação com [MonitoringConfiguration](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/emr-eks-jobs-s3.html). ## Servidor de histórico do Spark O Spark History Server têm todos os eventos do Spark gerados no perfil do usuário e os eventos editados gerados pelo driver do sistema. Você pode ver todos os contêineres dos drivers do usuário e do sistema na guia **Executores**. No entanto, os links de logs estão disponíveis somente para o perfil do usuário. ## O trabalho falhou com permissões insuficientes do Lake Formation Certifique-se de que o perfil de execução de trabalho tenha permissões para executar `SELECT` e `DESCRIBE` na tabela que você está acessando. ## Falha na execução do trabalho com RDD No momento, o EMR no EKS não oferece suporte a operações de conjunto de dados resilientes distribuídos (RDD) em trabalhos habilitados para o Lake Formation. ## Não é possível acessar arquivos de dados no Amazon S3 Certifique-se de ter registrado a localização do data lake no Lake Formation. ## Exceção de validação de segurança O EMR no EKS detectou um erro de validação de segurança. Entre em contato com o AWS suporte para obter assistência. ## Compartilhando o catálogo de dados e tabelas do AWS Glue entre contas Você pode compartilhar bancos de dados e tabelas entre contas e ainda usar o Lake Formation. Para obter mais informações, consulte [Compartilhamento de dados entre contas no Lake Formation](https://docs.aws.amazon.com/lake-formation/latest/dg/cross-account-permissions.html) e [Como faço para compartilhar o catálogo de dados e tabelas do AWS Glue entre contas usando o AWS Lake](https://repost.aws/knowledge-center/glue-lake-formation-cross-account) Formation? . ## Erro de inicialização do Iceberg Job que não configura a região AWS A mensagem é a seguinte: ``` 25/02/25 13:33:19 ERROR SparkFGACExceptionSanitizer: Client received error with id = b921f9e6-f655-491f-b8bd-b2842cdc20c7, reason = IllegalArgumentException, message = Cannot initialize LakeFormationAwsClientFactory, please set client.region to a valid aws region ``` Certifique-se de que a configuração do Spark `spark.sql.catalog.catalog_name.client.region` esteja definida como uma região válida. ## Lançamento de empregos no Iceberg SparkUnsupportedOperationException A mensagem é a seguinte: ``` 25/02/25 13:53:15 ERROR SparkFGACExceptionSanitizer: Client received error with id = 921fef42-0800-448b-bef5-d283d1278ce0, reason = SparkUnsupportedOperationException, message = Either glue.id or glue.account-id is set with non-default account. Cross account access with fine-grained access control is only supported with AWS Resource Access Manager. ``` Certifique-se de que a configuração do Spark `spark.sql.catalog.catalog_name.glue.account-id` esteja definida como um ID de conta válido. ## Falha no trabalho Iceberg com “403 Acesso negado” durante a operação MERGE A mensagem é a seguinte: ``` software.amazon.awssdk.services.s3.model.S3Exception: Access Denied (Service: S3, Status Code: 403, ... at software.amazon.awssdk.services.s3.DefaultS3Client.deleteObject(DefaultS3Client.java:3365) at org.apache.iceberg.aws.s3.S3FileIO.deleteFile(S3FileIO.java:162) at org.apache.iceberg.io.FileIO.deleteFile(FileIO.java:86) at org.apache.iceberg.io.RollingFileWriter.closeCurrentWriter(RollingFileWriter.java:129) ``` Desabilite as operações de exclusão do S3 no Spark adicionando a seguinte propriedade. `--conf spark.sql.catalog.s3-table-name.s3.delete-enabled=false`.