Da Docker a OpenShift
Published: 2023-10-03 14:26:38

---
title: Da Docker a OpenShift
published: true
date: 2022-12-15 00:00:00 UTC
tags: 
canonical_url: 
---

Sempre più aziende stanno migrando verso servizi di orchestrazione come Kubernetes e OpenShift; quest’ultimo ha aumentato le restrizioni alla sicurezza seguendo una strategia che non consente agli utenti di eseguire con privilegi di amministratore, quindi la maggior parte dei container che di solito vengono eseguiti correttamente su Docker e Kubernetes potrebbero non funzionare correttamente su OpenShift.

# Versione corta

Passi principali:

- Impostare la proprietà del gruppo sul gruppo principale (0).
- Non utilizzare _root_ come specifica per la direttiva [USER](https://docs.docker.com/engine/reference/builder/#user) in Dockerfile.
- I file eseguibili devono essere eseguiti dal gruppo radice (0) e dal proprietario.
- Non è possibile utilizzare porte inferiori a 1024.

L’uso dei ID assegnati in maniera arbitraria agli utenti fa parte della strategia di sicurezza multi-livello impiegata da OpenShift per ridurre i rischi di un’applicazione o del runtime del contenitore compromessi.

# Versione lunga

> Il presupposto di base è che i container vengano eseguiti utilizzando un ID utente assegnato in modo arbitrario: ciò significa che ogni container ha un ID utente assegnato che è univoco per il tuo progetto.

In effetti, al tuo progetto viene assegnato un ID utente che appartiene a un intervallo preciso con cui le applicazioni possono essere eseguite.

In questo modo, il range di ID utente utilizzato sarà _univoco_ e non si _sovrapporrà_ ad altri progetti. Per vedere quale intervallo è assegnato a un progetto eseguendo _oc describe_ sul progetto.

```
openshift.io/sa.scc.uid-range=1008050000/10000

```

Al contrario di OpenShift, Docker e [Kubernetes](https://kubernetes.io/it/docs/concepts/overview/what-is-kubernetes/) possono eseguire container che utilizzi un utente specifico definito tramite la direttiva USER nel Dockerfile, oppure andranno ad utilizzare l’utente root se non viene esplicitamente specificato.

# Come fare

> Il punto è: come fare a rendere un’immagine Docker che gira -magari- anche su Kubernetes pronta per essere eseguita su OpenShift?

Qui i passaggi da seguire:

## Imposta il gruppo

Sebbene OpenShift esegua i container utilizzando un ID utente assegnato arbitrariamente, l’ID gruppo deve essere sempre impostato sul gruppo _root_ (0).

Ciò significa che ogni directory e file devono essere accessibili dal gruppo _root_ per funzionare.

Di solito, ciò comporta una modifica nel Dockerfile come nell’esempio seguente:

```
RUN chgrp -R 0 /mia/directory && \
 chmod -R g=u /mia/directory

```

In questo caso, gli utenti del gruppo _root_ possono accedere alle risorse specificate con gli stessi privilegi del proprietario.

## User 1001

Le linee guida di RedHat suggeriscono di modificare il Dockerfile per utilizzare un utente casuale, per garantire piena compatibilità con OpenShift, ma anche retro-compatibilità con Kubernetes e Docker.

Questo si traduce in queste righe:

```
USER 1001
RUN chown -R 1001:0 /mia/directory

```

In questo caso, quando l’immagine finale verrà eseguita su OpenShift, l’utente specificato verrà ignorato poiché il cluster assegnerà a un utente un ID arbitrario. Questa modifica consente di eseguire la tua immagine sia su Kubernetes che su OpenShift, con un livello di sicurezza più elevato.

Tieni presente che il tentativo di risolvere i problemi relativi ai permessi nella proprietà _initContainers_impostando dei permessi superiori non funzionerà; il vantaggio offerto da Kubernetes per gestire i privilegi in questa fase si basa sul presupposto che sei _root_, ma in OpenShift anche gli _initContainer_ verranno assegnati a un utente arbitrario.

## Permessi

Per rendere i tuoi file eseguibili in grado di essere eseguiti da un ID utente arbitrario su OpenShift, le autorizzazioni dovrebbero essere modificate correttamente.

Ad esempio, uno script da eseguire dovrebbe avere i privilegi di esecuzione per il proprietario e il gruppo (ricordate? facciamo parte del gruppo _root_), ma nessuno -o pochi- per gli altri utenti.

```
RUN chmod 775 /my/directory/my-script

```

## Porte chiuse

Ogni numero di porta inferiore a 1024 non può essere utilizzato poiché può essere _bindata_ solo dall’utente _root_. Questo significa che qualsiasi tentativo di utilizzare una porta che va da 0 a 1023, sarà inutile.

# Risorse utili

- [Docker](https://amzn.to/3cSVvUG) - per cominciare bene