Este conteúdo foi traduzido por máquina para sua conveniência e a Huawei Cloud não pode garantir que o conteúdo foi traduzido com precisão. Para exibir o conteúdo original, use o link no canto superior direito para mudar para a página em inglês.
Computação
Elastic Cloud Server
Bare Metal Server
Auto Scaling
Image Management Service
Dedicated Host
FunctionGraph
Cloud Phone Host
Huawei Cloud EulerOS
Redes
Virtual Private Cloud
Elastic IP
Elastic Load Balance
NAT Gateway
Direct Connect
Virtual Private Network
VPC Endpoint
Cloud Connect
Enterprise Router
Enterprise Switch
Global Accelerator
Gerenciamento e governança
Cloud Eye
Identity and Access Management
Cloud Trace Service
Resource Formation Service
Tag Management Service
Log Tank Service
Config
Resource Access Manager
Simple Message Notification
Application Performance Management
Application Operations Management
Organizations
Optimization Advisor
Cloud Operations Center
Resource Governance Center
Migração
Server Migration Service
Object Storage Migration Service
Cloud Data Migration
Migration Center
Cloud Ecosystem
KooGallery
Partner Center
User Support
My Account
Billing Center
Cost Center
Resource Center
Enterprise Management
Service Tickets
HUAWEI CLOUD (International) FAQs
ICP Filing
Support Plans
My Credentials
Customer Operation Capabilities
Partner Support Plans
Professional Services
Análises
MapReduce Service
Data Lake Insight
CloudTable Service
Cloud Search Service
Data Lake Visualization
Data Ingestion Service
GaussDB(DWS)
DataArts Studio
IoT
IoT Device Access
Outros
Product Pricing Details
System Permissions
Console Quick Start
Common FAQs
Instructions for Associating with a HUAWEI CLOUD Partner
Message Center
Segurança e conformidade
Security Technologies and Applications
Web Application Firewall
Host Security Service
Cloud Firewall
SecMaster
Anti-DDoS Service
Data Encryption Workshop
Database Security Service
Cloud Bastion Host
Data Security Center
Cloud Certificate Manager
Situation Awareness
Managed Threat Detection
Blockchain
Blockchain Service
Serviços de mídia
Media Processing Center
Video On Demand
Live
SparkRTC
Armazenamento
Object Storage Service
Elastic Volume Service
Cloud Backup and Recovery
Cloud Server Backup Service
Storage Disaster Recovery Service
Scalable File Service
Volume Backup Service
Data Express Service
Dedicated Distributed Storage Service
Containers
Cloud Container Engine
SoftWare Repository for Container
Application Service Mesh
Ubiquitous Cloud Native Service
Cloud Container Instance
Bancos de dados
Relational Database Service
Document Database Service
Data Admin Service
Data Replication Service
GeminiDB
GaussDB
Distributed Database Middleware
Database and Application Migration UGO
TaurusDB
Middleware
Distributed Cache Service
API Gateway
Distributed Message Service for Kafka
Distributed Message Service for RabbitMQ
Distributed Message Service for RocketMQ
Cloud Service Engine
EventGrid
Dedicated Cloud
Dedicated Computing Cluster
Aplicações de negócios
ROMA Connect
Message & SMS
Domain Name Service
Edge Data Center Management
Meeting
AI
Face Recognition Service
Graph Engine Service
Content Moderation
Image Recognition
Data Lake Factory
Optical Character Recognition
ModelArts
ImageSearch
Conversational Bot Service
Speech Interaction Service
Huawei HiLens
Developer Tools
SDK Developer Guide
API Request Signing Guide
Terraform
Koo Command Line Interface
Distribuição de conteúdo e computação de borda
Content Delivery Network
Intelligent EdgeFabric
CloudPond
Soluções
SAP Cloud
High Performance Computing
Serviços para desenvolvedore
ServiceStage
CodeArts
CodeArts PerfTest
CodeArts Req
CodeArts Pipeline
CodeArts Build
CodeArts Deploy
CodeArts Artifact
CodeArts TestPlan
CodeArts Check
Cloud Application Engine
MacroVerse aPaaS
KooPhone
KooDrive
Central de ajuda/ Cloud Container Engine/ Guia de usuário/ Permissões/ Segurança de pod/ Configuração de admissão de segurança do pod

Configuração de admissão de segurança do pod

Atualizado em 2024-11-28 GMT+08:00

Antes de usar a admissão de segurança do pod, entenda os Padrões de segurança do pod de Kubernetes. Esses padrões definem diferentes níveis de isolamento para vagens. Eles permitem que você defina como deseja restringir o comportamento dos pods de forma clara e consistente. O Kubernetes oferece um controlador de admissão de segurança de pod embutido para aplicar os padrões de segurança do pod. As restrições de segurança do pod são aplicadas no nível do namespace quando os pods são criados.

O padrão de segurança do pod define três níveis de política de segurança:

Tabela 1 Níveis de política de segurança do pod

Nível

Descrição

privileged

Política irrestrita, fornecendo o mais amplo nível possível de permissões, geralmente destinada a cargas de trabalho no nível do sistema e da infraestrutura gerenciadas por usuários privilegiados e confiáveis, como CNIs e drivers de armazenamento.

baseline

Política minimamente restritiva que impede escalações de privilégios conhecidas, geralmente direcionadas a cargas de trabalho não críticas. Esta política desativa recursos como hostNetwork e hostPID.

restricted

Política fortemente restrita, seguindo as práticas recomendadas atuais de endurecimento do Pod.

A admissão de segurança do pod é aplicada no nível do namespace. O controlador restringe o contexto de segurança e outros parâmetros no pod ou contêiner no namespace. A política privilegiada não verifica o campo securityContext do pod e do contêiner. As políticas de linha de base e restritas têm requisitos diferentes em securityContext. Para obter detalhes, consulte Padrões de segurança do pod.

Configurar o contexto de segurança: configure um contexto de segurança para um pod ou contêiner

Rótulos de admissão de segurança de pod

O Kubernetes define três tipos de rótulos para admissão de segurança de pods (consulte Tabela 2). Você pode definir esses rótulos em um namespace para definir o nível de padrão de segurança do pod a ser usado. No entanto, não altere o nível do padrão de segurança do pod em namespaces do sistema, como o kube-system. Caso contrário, os pods no namespace do sistema podem estar com defeito.

Tabela 2 Rótulos de admissão de segurança de pod

Modo

Objeto de destino

Descrição

enforce

Pods

Violações de política farão com que o pod seja rejeitado.

audit

Cargas de trabalho (como Implementação e tarefa)

As violações de política acionarão a adição de uma anotação de auditoria ao evento registrado no log de auditoria, mas são permitidas de outra forma.

warn

Cargas de trabalho (como Implementação e tarefa)

Violações de política acionarão um aviso voltado para o usuário, mas de outra forma são permitidas.

Os pods geralmente são criados indiretamente, criando um objeto de carga de trabalho, como uma Implementação ou tarefa. Para ajudar a detectar violações precocemente, os modos de auditoria e aviso são aplicados aos recursos da carga de trabalho. No entanto, o modo de imposição é aplicado somente aos objetos de pod resultantes.

Impor a admissão de segurança de pod com rótulos de namespace

Você pode rotular namespaces para impor os padrões de segurança do pod. Suponha que um espaço de nomes está configurado da seguinte forma:

apiVersion: v1
kind: Namespace
metadata:
  name: my-baseline-namespace
  labels:
    pod-security.kubernetes.io/enforce: privileged
    pod-security.kubernetes.io/enforce-version: v1.25
    pod-security.kubernetes.io/audit: baseline
    pod-security.kubernetes.io/audit-version: v1.25
    pod-security.kubernetes.io/warn: restricted
    pod-security.kubernetes.io/warn-version: v1.25

    # The label can be in either of the following formats:
    # pod-security.kubernetes.io/<MODE>: <LEVEL> 
    # pod-security.kubernetes.io/<MODE>-version: <VERSION>  
    # The audit and warn modes inform you of which security behaviors are violated by the load.

Os rótulos de namespace indicam qual nível de política aplicar para o modo. Para cada modo, há dois rótulos que determinam a política usada:

  • pod-security.kubernetes.io/<MODE>: <LEVEL>
    • <MODE>: deve ser enforce, audit ou warn. Para obter detalhes sobre os modos, consulte Tabela 2.
    • <LEVEL>: deve ser privileged, baseline ou restricted. Para obter detalhes sobre os níveis, consulte Tabela 1.
  • pod-security.kubernetes.io/<MODE>-version: <VERSION>

    Opcional, que fixa a política em uma determinada versão do Kubernetes.

    • <MODE>: deve ser enforce, audit ou warn. Para obter detalhes sobre os modos, consulte Tabela 2.
    • <VERSION>: número da versão do Kubernetes. Por exemplo, v1.25. Você também pode usar latest.

Se os pods forem implementados no namespace anterior, as seguintes restrições de segurança se aplicam:

  1. A verificação no modo de impor é ignorada (modo impor + nível privilegiado).
  2. As restrições relacionadas com a política de linha de base são verificadas (modo de auditoria + nível de linha de base). Ou seja, se o pod ou o contêiner violar a política, o evento correspondente será registrado no log de auditoria.
  3. Restrições relacionadas à política restrita são verificadas (modo de aviso + nível restrito). Ou seja, se o pod ou contêiner violar a política, o usuário receberá um alarme ao criar o pod.

Migrar política de segurança do pod para a admissão de segurança do pod

Se você usar políticas de segurança de pods em um cluster anterior à v1.25 e precisar substituí-las pela admissão de segurança de pods em um cluster v1.25 ou posterior, siga o guia em Migração de PodSecurityPolicy para o controlador de admissão interno de PodSecurity.

  1. A admissão de segurança do pod suporta apenas três modos de isolamento, menos flexíveis do que as políticas de segurança do pod. Se você precisar de mais controle sobre restrições específicas, será necessário usar um Webhook de validação de admissão para impor essas políticas.
  2. Admissão de segurança de pod é um controlador de admissão não-mutante, o que significa que não irá modificar pods antes de validá-los. Se você estava confiando neste aspecto da PSP, você precisará modificar o contexto de segurança em suas cargas de trabalho ou usar um Webhook de admissão com mutação para fazer essas alterações.
  3. A PSP permite que você vincule políticas diferentes a contas de serviço diferentes. Essa abordagem tem muitas armadilhas e não é recomendada, mas se você precisar desse recurso de qualquer maneira, precisará usar um webhook de terceiros.
  4. Não aplique a admissão de segurança do pod aos namespaces onde os componentes do CCE, como kube-system, kube-public e kube-node-lease, são implementados. Caso contrário, os componentes do CCE e funções adicionais serão anormais.

Usamos cookies para aprimorar nosso site e sua experiência. Ao continuar a navegar em nosso site, você aceita nossa política de cookies. Saiba mais

Feedback

Feedback

Feedback

0/500

Conteúdo selecionado

Envie o conteúdo selecionado com o feedback