OpenShift - Segurança

A segurança OpenShift é principalmente uma combinação de dois componentes que lidam principalmente com as restrições de segurança.

Restrições de contexto de segurança (SCC)
Conta de serviço

Restrições de contexto de segurança (SCC)

É basicamente usado para restrição de pod, o que significa que define as limitações de um pod, como em quais ações ele pode executar e quais todas as coisas que ele pode acessar no cluster.

O OpenShift fornece um conjunto de SCC predefinido que pode ser usado, modificado e estendido pelo administrador.

$ oc get scc
NAME              PRIV   CAPS  HOSTDIR  SELINUX    RUNASUSER         FSGROUP   SUPGROUP  PRIORITY
anyuid            false   []   false    MustRunAs  RunAsAny          RunAsAny  RunAsAny  10
hostaccess        false   []   true     MustRunAs  MustRunAsRange    RunAsAny  RunAsAny  <none>
hostmount-anyuid  false   []   true     MustRunAs  RunAsAny          RunAsAny  RunAsAny  <none>
nonroot           false   []   false    MustRunAs  MustRunAsNonRoot  RunAsAny  RunAsAny  <none>
privileged        true    []   true     RunAsAny   RunAsAny          RunAsAny  RunAsAny  <none>
restricted        false   []   false    MustRunAs  MustRunAsRange    RunAsAny  RunAsAny  <none>

Se alguém deseja usar qualquer scc predefinido, isso pode ser feito simplesmente adicionando o usuário ou o grupo ao grupo scc.

$ oadm policy add-user-to-scc <scc_name> <user_name>
$ oadm policy add-group-to-scc <scc_name> <group_name>

Conta de serviço

As contas de serviço são basicamente usadas para controlar o acesso à API mestre do OpenShift, que é chamada quando um comando ou solicitação é disparado de qualquer máquina mestre ou de nó.

Sempre que um aplicativo ou processo exigir um recurso que não seja concedido pelo SCC restrito, você terá que criar uma conta de serviço específica e adicionar a conta ao respectivo SCC. No entanto, se um SCC não atender aos seus requisitos, é melhor criar um novo SCC específico para os seus requisitos, em vez de usar aquele que melhor se ajusta. No final, defina-o para a configuração de implantação.

$ oc create serviceaccount Cadmin
$ oc adm policy add-scc-to-user vipin -z Cadmin

Segurança de contêineres

No OpenShift, a segurança de contêineres é baseada no conceito de quão segura é a plataforma de contêiner e onde os contêineres estão sendo executados. Existem várias coisas que aparecem quando falamos sobre segurança de contêineres e o que precisa ser cuidado.

Image Provenance - Um sistema de rotulagem seguro está em vigor que identifica de forma exata e incontestável de onde vieram os recipientes em execução no ambiente de produção.

Security Scanning - Um scanner de imagem verifica automaticamente todas as imagens em busca de vulnerabilidades conhecidas.

Auditing - O ambiente de produção é auditado regularmente para garantir que todos os contêineres sejam baseados em contêineres atualizados e que os hosts e os contêineres estejam configurados com segurança.

Isolation and Least Privilege- Os contêineres são executados com os recursos e privilégios mínimos necessários para funcionar com eficácia. Eles não podem interferir indevidamente com o host ou outros contêineres.

Runtime Threat Detection - Um recurso que detecta ameaças ativas contra aplicativos em contêineres em tempo de execução e responde automaticamente a elas.

Access Controls - Módulos de segurança do Linux, como AppArmor ou SELinux, são usados para impor controles de acesso.

Existem alguns métodos principais pelos quais a segurança do contêiner é arquivada.

Controle de acesso via oAuth
Via console da web de autoatendimento
Por certificados de plataforma

Controle de acesso via OAuth

Neste método, a autenticação para acesso de controle de API é arquivada obtendo um token seguro para autenticação por meio de servidores OAuth, que vem embutido na máquina mestre OpenShift. Como administrador, você tem a capacidade de modificar a configuração do servidor OAuth.

Para obter mais detalhes sobre a configuração do servidor OAuth, consulte o Capítulo 5 deste tutorial.

Via console da web de autoatendimento

Este recurso de segurança do console da web está embutido no console da web OpenShift. Este console garante que todas as equipes que trabalham juntas não tenham acesso a outros ambientes sem autenticação. O mestre multi-telnet no OpenShift possui os seguintes recursos de segurança -

A camada TCL está habilitada
Usa certificado x.509 para autenticação
Protege a configuração do etcd na máquina mestre

Por certificados de plataforma

Nesse método, os certificados para cada host são configurados durante a instalação por meio do Ansible. Como ele usa o protocolo de comunicação HTTPS via API Rest, precisamos de uma conexão segura TCL para diferentes componentes e objetos. Esses são certificados predefinidos, no entanto, pode-se até ter um certificado personalizado instalado no cluster de mestre para acesso. Durante a configuração inicial do mestre, os certificados personalizados podem ser configurados substituindo os certificados existentes usandoopenshift_master_overwrite_named_certificates parâmetro.

Example

openshift_master_named_certificates = [{"certfile": "/path/on/host/to/master.crt", 
"keyfile": "/path/on/host/to/master.key", 
"cafile": "/path/on/host/to/mastercert.crt"}]

Para obter mais detalhes sobre como gerar certificados personalizados, visite o seguinte link -

https://www.linux.com/learn/creating-self-signed-ssl-certificates-apache-linux

Segurança de rede

No OpenShift, o Software Defined Networking (SDN) é usado para comunicação. O namespace de rede é usado para cada pod no cluster, em que cada pod obtém seu próprio IP e um intervalo de portas para obter o tráfego de rede nele. Por esse método, pode-se isolar pods por causa dos quais não pode se comunicar com pods no outro projeto.

Isolando um Projeto

Isso pode ser feito pelo administrador do cluster usando o seguinte oadm command da CLI.

$ oadm pod-network isolate-projects <project name 1> <project name 2>

Isso significa que os projetos definidos acima não podem se comunicar com outros projetos no cluster.

Segurança de Volume

A segurança de volume significa claramente proteger o PV e o PVC de projetos no cluster OpenShift. Existem principalmente quatro seções para controlar o acesso a volumes no OpenShift.

Grupos Suplementares
fsGroup
runAsUser
seLinuxOptions

Grupos suplementares - grupos suplementares são grupos regulares do Linux. Quando um processo é executado no sistema, ele é executado com um ID de usuário e um ID de grupo. Esses grupos são usados para controlar o acesso ao armazenamento compartilhado.

Verifique a montagem NFS usando o seguinte comando.

# showmount -e <nfs-server-ip-or-hostname>
Export list for f21-nfs.vm:
/opt/nfs *

Verifique os detalhes do NFS no servidor de montagem usando o seguinte comando.

# cat /etc/exports
/opt/nfs *(rw,sync,no_root_squash)
...
# ls -lZ /opt/nfs -d
drwxrws---. nfsnobody 2325 unconfined_u:object_r:usr_t:s0 /opt/nfs
# id nfsnobody
uid = 65534(nfsnobody) gid = 454265(nfsnobody) groups = 454265(nfsnobody)

O / opt / nfs / export pode ser acessado por UID454265 e o grupo 2325.

apiVersion: v1
kind: Pod
...
spec:
   containers:
   - name: ...
      volumeMounts:
      - name: nfs
         mountPath: /usr/share/...
   securityContext:
      supplementalGroups: [2325]
   volumes:
   - name: nfs
      nfs:
      server: <nfs_server_ip_or_host>
      path: /opt/nfs

fsGroup

fsGroup significa o grupo do sistema de arquivos que é usado para adicionar grupos suplementares de contêineres. O ID do grupo de suplemento é usado para armazenamento compartilhado e fsGroup é usado para armazenamento de bloco.

kind: Pod
spec:
   containers:
   - name: ...
   securityContext:
      fsGroup: 2325

runAsUser

runAsUser usa o ID do usuário para comunicação. Isso é usado para definir a imagem do contêiner na definição do pod. Um único usuário de ID pode ser usado em todos os contêineres, se necessário.

Durante a execução do contêiner, o ID definido é correspondido com o ID do proprietário na exportação. Se o ID especificado for definido externamente, ele se tornará global para todos os contêineres do pod. Se for definido com um pod específico, ele se tornará específico para um único contêiner.

spec:
   containers:
   - name: ...
      securityContext:
         runAsUser: 454265