<h2>Namespaces em Kubernetes: Isolamento Lógico e Segurança</h2>

<p>Namespaces são um recurso fundamental do Kubernetes que permite particionar um cluster em múltiplos ambientes virtuais, isolando logicamente recursos como pods, serviços e deployments. Diferentemente de uma máquina virtual ou container individual, namespaces compartilham a mesma rede de cluster, mas oferecem isolamento a nível de API e política. Isso permite que equipes diferentes, projetos ou ambientes (desenvolvimento, staging, produção) coexistam no mesmo cluster físico sem interferência.</p>

<p>Cada recurso no Kubernetes pertence a um namespace, exceto por recursos de escopo de cluster como nodes e namespaces em si. Quando você não especifica um namespace, o Kubernetes assume <code>default</code>. Um ponto crítico: namespaces não oferecem isolamento de rede por si só — para isso você precisa de Network Policies. Porém, combinados com RBAC e quotas de recursos, eles formam a base de um cluster seguro e organizado.</p>

<h3>Criando e Gerenciando Namespaces</h3>

<p>A criação de um namespace é simples, mas devemos entender as melhores práticas. Você pode criar via YAML ou imperativamente:</p>

<pre><code class="language-yaml"># namespace-producao.yaml

apiVersion: v1

kind: Namespace

metadata:

name: producao

labels:

ambiente: producao

tier: critical</code></pre>

<p>Aplicar com <code>kubectl apply -f namespace-producao.yaml</code>. Você também pode criar imperativamente com <code>kubectl create namespace producao</code>, mas o arquivo YAML é preferível em ambientes de produção porque é versionável e reproduzível.</p>

<p>Para listar namespaces e ver quantos recursos existem em cada um:</p>

<pre><code class="language-bash">kubectl get namespaces

kubectl get all -n producao

kubectl describe namespace producao</code></pre>

<p>Um aspecto importante: quando você deleta um namespace, todos os recursos dentro dele são deletados também. Use com cuidado em produção. Para proteger namespaces críticos, implemente policies de admission e backups automáticos.</p>

<h2>RBAC (Role-Based Access Control): Autorização Granular</h2>

<p>RBAC é o mecanismo do Kubernetes que define quem pode fazer o quê em quais recursos. Diferentemente de autenticação (que responde &quot;você é quem diz ser?&quot;), autorização responde &quot;você tem permissão para fazer isso?&quot;. RBAC opera em quatro primitivas: Role, RoleBinding, ClusterRole e ClusterRoleBinding. Roles e RoleBindings são scoped a um namespace, enquanto ClusterRole e ClusterRoleBinding valem para todo o cluster.</p>

<p>O conceito central é simples: você define uma <strong>Role</strong> (um conjunto de permissões), depois vincula essa role a um <strong>Subject</strong> (usuário, grupo ou service account) através de um <strong>RoleBinding</strong>. Cada Role contém regras que especificam verbos (get, create, delete, etc.), recursos (pods, services, etc.) e opcionalmente nomes específicos de recursos.</p>

<h3>Estrutura e Componentes do RBAC</h3>

<p>Uma Role define permissões em um namespace específico:</p>

<pre><code class="language-yaml"># role-developer.yaml

apiVersion: rbac.authorization.k8s.io/v1

kind: Role

metadata:

name: developer

namespace: producao

rules:

Permite listar e obter pods

• apiGroups: [&quot;&quot;]

resources: [&quot;pods&quot;]

verbs: [&quot;get&quot;, &quot;list&quot;, &quot;watch&quot;]

Permite ver logs de pods

• apiGroups: [&quot;&quot;]

resources: [&quot;pods/log&quot;]

verbs: [&quot;get&quot;]

Permite criar e deletar deployments

• apiGroups: [&quot;apps&quot;]

resources: [&quot;deployments&quot;]

verbs: [&quot;get&quot;, &quot;list&quot;, &quot;create&quot;, &quot;update&quot;, &quot;patch&quot;, &quot;delete&quot;]

Permite acessar configmaps e secrets (leitura)

• apiGroups: [&quot;&quot;]

resources: [&quot;configmaps&quot;, &quot;secrets&quot;]

verbs: [&quot;get&quot;, &quot;list&quot;]</code></pre>

<p>Agora você vincula essa Role a um usuário ou service account através de um RoleBinding:</p>

<pre><code class="language-yaml"># rolebinding-developer-producao.yaml

apiVersion: rbac.authorization.k8s.io/v1

kind: RoleBinding

metadata:

name: developer-binding

namespace: producao

subjects:

• kind: User

name: joao@empresa.com

apiGroup: rbac.authorization.k8s.io

• kind: ServiceAccount

name: app-deployer

namespace: producao

roleRef:

kind: Role

name: developer

apiGroup: rbac.authorization.k8s.io</code></pre>

<p>Neste exemplo, o usuário <code>joao@empresa.com</code> e a service account <code>app-deployer</code> agora têm as permissões definidas na Role <code>developer</code>, mas apenas no namespace <code>producao</code>.</p>

<h3>ClusterRole e ClusterRoleBinding</h3>

<p>Para recursos de escopo de cluster ou permissões que precisam valer em todos os namespaces, use ClusterRole:</p>

<pre><code class="language-yaml"># clusterrole-admin-logs.yaml

apiVersion: rbac.authorization.k8s.io/v1

kind: ClusterRole

metadata:

name: log-reader

rules:

• apiGroups: [&quot;&quot;]

resources: [&quot;pods&quot;, &quot;pods/log&quot;]

verbs: [&quot;get&quot;, &quot;list&quot;]

• apiGroups: [&quot;&quot;]

resources: [&quot;namespaces&quot;]

verbs: [&quot;get&quot;, &quot;list&quot;]</code></pre>

<p>E o ClusterRoleBinding que o vincula:</p>

<pre><code class="language-yaml"># clusterrolebinding-team-logs.yaml

apiVersion: rbac.authorization.k8s.io/v1

kind: ClusterRoleBinding

metadata:

name: log-reader-global

subjects:

• kind: Group

name: monitoring-team

apiGroup: rbac.authorization.k8s.io

roleRef:

kind: ClusterRole

name: log-reader

apiGroup: rbac.authorization.k8s.io</code></pre>

<h3>Boas Práticas no RBAC</h3>

<p>O princípio fundamental é o <strong>least privilege</strong>: conceda apenas as permissões mínimas necessárias. Nunca use <code>*</code> (wildcard) em verbos ou recursos em produção, pois isso equivale a acesso total. Use <code>kubectl auth can-i</code> para testar permissões antes de aplicar em produção:</p>

<pre><code class="language-bash"># Testar se um usuário pode listar pods em um namespace

kubectl auth can-i list pods --as=joao@empresa.com -n producao

Testar se uma service account pode criar deployments

kubectl auth can-i create deployments --as=system:serviceaccount:producao:app-deployer -n producao</code></pre>

<h2>Segurança em Clusters Kubernetes: Defesa em Profundidade</h2>

<p>Segurança em Kubernetes não é um único recurso, mas um conjunto de camadas. Além de RBAC e Namespaces, você precisa pensar em autenticação, autorização, policies de rede, segurança de imagens, e auditoria. A abordagem correta é &quot;defesa em profundidade&quot; — múltiplas camadas que, mesmo se uma falhar, a próxima ainda protege o cluster.</p>

<p>As ameaças em um cluster incluem: acesso não autorizado (resolvido com autenticação + RBAC), movimento lateral entre pods (resolvido com Network Policies), execução de containers privilegiados (resolvido com Pod Security Policies ou Pod Security Standards), e vazamento de secrets em logs ou imagens (resolvido com RBAC em secrets e image scanning).</p>

<h3>Network Policies: Isolamento de Rede</h3>

<p>Network Policies definem regras de tráfego entre pods, bloqueando por padrão e permitindo apenas o necessário:</p>

<pre><code class="language-yaml"># network-policy-app-db.yaml

apiVersion: networking.k8s.io/v1

kind: NetworkPolicy

metadata:

name: allow-app-to-db

namespace: producao

spec:

podSelector:

matchLabels:

tier: database

policyTypes:

• Ingress

ingress:

• from:
• podSelector:

matchLabels:

tier: app

ports:

• protocol: TCP

port: 5432</code></pre>

<p>Esta policy permite que pods com label <code>tier: app</code> acessem pods com label <code>tier: database</code> apenas na porta 5432. Todo outro tráfego é bloqueado. Aplique Network Policies em cada namespace e teste com <code>kubectl exec</code> de um pod para outro.</p>

<h3>Pod Security Standards e Admission Controllers</h3>

<p>Pod Security Standards (PSS) definem níveis de segurança mínimos para pods. Ao invés do antigo Pod Security Policy (deprecado), você usa labels no namespace:</p>

<pre><code class="language-yaml"># namespace-producao-seguro.yaml

apiVersion: v1

kind: Namespace

metadata:

name: producao

labels:

pod-security.kubernetes.io/enforce: restricted

pod-security.kubernetes.io/audit: restricted

pod-security.kubernetes.io/warn: restricted</code></pre>

<p>Com <code>enforce: restricted</code>, o Kubernetes rejeita qualquer pod que não cumpra o padrão <code>restricted</code>, que proíbe containers privilegiados, acesso a root, e mais. O nível <code>audit</code> apenas registra em logs, e <code>warn</code> avisa o usuário.</p>

<h3>Gerenciamento Seguro de Secrets</h3>

<p>Secrets no Kubernetes armazenam dados sensíveis, mas por padrão são apenas base64-encoded (não criptografados). Use RBAC para limitar quem pode ver secrets:</p>

<pre><code class="language-yaml"># role-secret-restricted.yaml

apiVersion: rbac.authorization.k8s.io/v1

kind: Role

metadata:

name: database-admin

namespace: producao

rules:

• apiGroups: [&quot;&quot;]

resources: [&quot;secrets&quot;]

resourceNames: [&quot;db-credentials&quot;] # Apenas este secret

verbs: [&quot;get&quot;, &quot;list&quot;]</code></pre>

<p>Em produção, ative criptografia em repouso para etcd (o banco de dados do Kubernetes) e considere usar soluções externas como HashiCorp Vault ou AWS Secrets Manager, integradas via External Secrets Operator.</p>

<h3>Auditoria e Logging</h3>

<p>Configure audit logging no API server para registrar todas as ações. Isso é crítico para compliance e forensics:</p>

<pre><code class="language-yaml"># audit-policy.yaml (simplificado)

apiVersion: audit.k8s.io/v1

kind: Policy

rules:

Log de alta verbosidade para deletions

• level: RequestResponse

verbs: [&quot;delete&quot;, &quot;deletecollection&quot;]

omitStages:

• RequestReceived

Log de metadata para tudo else

• level: Metadata</code></pre>

<p>Configure no API server com <code>--audit-policy-file=/etc/kubernetes/audit-policy.yaml --audit-log-path=/var/log/kubernetes/audit.log</code>. Envie logs de auditoria para um SIEM ou ferramenta centralizada.</p>

<h3>Verificação de Vulnerabilidades em Imagens</h3>

<p>Sempre scaneie imagens em busca de vulnerabilidades conhecidas antes de colocar em produção:</p>

<pre><code class="language-bash"># Usando Trivy (ferramenta open-source)

trivy image --severity HIGH,CRITICAL seu-registry/sua-app:v1.0

Integrado no pipeline CI/CD

docker build -t seu-registry/sua-app:v1.0 .

trivy image --exit-code 1 --severity HIGH seu-registry/sua-app:v1.0

docker push seu-registry/sua-app:v1.0</code></pre>

<p>Mantenha imagens base atualizadas e implemente políticas que rejeitam imagens com vulnerabilidades críticas usando Admission Webhooks.</p>

<h2>Exemplo Integrado: Deployment Seguro em Produção</h2>

<p>Vamos juntar tudo: namespace isolado, RBAC restritivo, Network Policy, e Pod Security Standards:</p>

<pre><code class="language-yaml"># 1. Namespace com PSS

apiVersion: v1

kind: Namespace

metadata:

name: app-producao

labels:

pod-security.kubernetes.io/enforce: restricted

pod-security.kubernetes.io/audit: restricted

---

2. Service Account para a aplicação

apiVersion: v1

kind: ServiceAccount

metadata:

name: app-sa

namespace: app-producao

---

3. Role com permissões mínimas

apiVersion: rbac.authorization.k8s.io/v1

kind: Role

metadata:

name: app-reader

namespace: app-producao

rules:

• apiGroups: [&quot;&quot;]

resources: [&quot;configmaps&quot;]

verbs: [&quot;get&quot;, &quot;list&quot;]

• apiGroups: [&quot;&quot;]

resources: [&quot;secrets&quot;]

resourceNames: [&quot;app-db-secret&quot;]

verbs: [&quot;get&quot;]

---

4. RoleBinding

apiVersion: rbac.authorization.k8s.io/v1

kind: RoleBinding

metadata:

name: app-reader-binding

namespace: app-producao

subjects:

• kind: ServiceAccount

name: app-sa

namespace: app-producao

roleRef:

kind: Role

name: app-reader

apiGroup: rbac.authorization.k8s.io

---

5. Network Policy

apiVersion: networking.k8s.io/v1

kind: NetworkPolicy

metadata:

name: app-network-policy

namespace: app-producao

spec:

podSelector:

matchLabels:

app: myapp

policyTypes:

• Ingress
• Egress

ingress:

• from:
• namespaceSelector:

matchLabels:

name: ingress-nginx

ports:

• protocol: TCP

port: 8080

egress:

• to:
• podSelector:

matchLabels:

app: database

ports:

• protocol: TCP

port: 5432

• to:
• namespaceSelector: {}

podSelector:

matchLabels:

k8s-app: kube-dns

ports:

• protocol: UDP

port: 53

---

6. Deployment com segurança

apiVersion: apps/v1

kind: Deployment

metadata:

name: myapp

namespace: app-producao

spec:

replicas: 3

selector:

matchLabels:

app: myapp

template:

metadata:

labels:

app: myapp

spec:

serviceAccountName: app-sa

securityContext:

runAsNonRoot: true

runAsUser: 1000

fsReadOnlyRootFilesystem: true

containers:

• name: app

image: seu-registry/myapp:v1.0

imagePullPolicy: Always

ports:

• containerPort: 8080

securityContext:

allowPrivilegeEscalation: false

capabilities:

drop:

• ALL

resources:

requests:

memory: &quot;128Mi&quot;

cpu: &quot;100m&quot;

limits:

memory: &quot;256Mi&quot;

cpu: &quot;500m&quot;

volumeMounts:

• name: tmp

mountPath: /tmp

volumes:

• name: tmp

emptyDir: {}</code></pre>

<p>Para aplicar: <code>kubectl apply -f arquivo-completo.yaml</code>. Valide com <code>kubectl describe namespace app-producao</code>, <code>kubectl get roles -n app-producao</code>, e teste permissões com <code>kubectl auth can-i</code>.</p>

<h2>Conclusão</h2>

<p>Ao longo deste artigo, você aprendeu que <strong>Namespaces fornecem isolamento lógico e particionamento de recursos</strong>, servindo como base para multi-tenância em um cluster. Não confunda com isolamento de rede — use Network Policies para isso. Em segundo lugar, <strong>RBAC é o mecanismo de autorização que implementa least privilege</strong>, separando permissões por Role e RoleBinding em escopo de namespace, ou ClusterRole/ClusterRoleBinding globalmente. Sempre teste com <code>kubectl auth can-i</code> antes de confiar em uma política em produção. Por fim, <strong>segurança em Kubernetes é multi-camadas</strong>: autenticação, RBAC, Network Policies, Pod Security Standards, secrets criptografados, image scanning, e auditoria trabalham juntas. Nenhuma camada isolada é suficiente — implemente todas.</p>

<h2>Referências</h2>

<ul>

<li><a href="https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/" target="_blank" rel="noopener noreferrer">Kubernetes Documentation - Namespaces</a></li>

<li><a href="https://kubernetes.io/docs/reference/access-authn-authz/rbac/" target="_blank" rel="noopener noreferrer">Kubernetes Documentation - RBAC Authorization</a></li>

<li><a href="https://kubernetes.io/docs/concepts/security/pod-security-standards/" target="_blank" rel="noopener noreferrer">Kubernetes Documentation - Pod Security Standards</a></li>

<li><a href="https://kubernetes.io/docs/concepts/services-networking/network-policies/" target="_blank" rel="noopener noreferrer">Kubernetes Documentation - Network Policies</a></li>

<li><a href="https://kubernetes.io/docs/concepts/security/" target="_blank" rel="noopener noreferrer">Kubernetes Security Best Practices - Official</a></li>

</ul>

<p>&lt;!-- FIM --&gt;</p>