Nota

Questa esercitazione richiede l'accesso a Oracle Cloud. Per iscriverti a un account gratuito, consulta Inizia a utilizzare Oracle Cloud Infrastructure Free Tier.
Utilizza valori di esempio per le credenziali, la tenancy e i compartimenti di Oracle Cloud Infrastructure. Al termine del laboratorio, sostituisci questi valori con quelli specifici del tuo ambiente cloud.

Sfrutta il tunneling SSH con Oracle Cloud Infrastructure Kubernetes Engine per lo sviluppo sicuro delle applicazioni

Introduzione

immagine

Quando ho ottenuto il tunneling SSH con OKE lavorando con l'aiuto di Ali Mukadam, l'ho chiamato "magia".

Mi ha risposto con il seguente messaggio:

"L'hai chiamata magia, altri la chiamano scienza. Dove sono io sono uno e lo stesso".

La citazione originale è tratta da un film di Thor:

"I tuoi antenati la chiamavano magica, ma tu la chiami scienza. Vengo da una terra dove sono uno e lo stesso."

Cos'è questa magia?

Nello sviluppo di applicazioni moderne, proteggere le connessioni tra risorse locali e basate sul cloud è essenziale, soprattutto quando si lavora con Oracle Cloud Infrastructure Kubernetes Engine (OCI Kubernetes Engine o OKE). Il tunneling SSH offre un modo semplice ma potente per connettersi in modo sicuro ai cluster OKE, consentendo agli sviluppatori di gestire e interagire con le risorse senza esporle alla rete Internet pubblica. Questo tutorial esplora come impostare il tunneling SSH con OKE e come gli sviluppatori possono integrare questo approccio nel loro flusso di lavoro per una maggiore sicurezza ed efficienza. Dalla configurazione iniziale alle best practice, tratteremo tutto ciò di cui hai bisogno per sfruttare efficacemente il tunneling SSH nelle tue applicazioni basate su OKE.

L'immagine seguente illustra i flussi di traffico completi del tunneling SSH di due applicazioni diverse.

immagine

Obiettivi

Sfrutta il tunneling SSH con OKE per lo sviluppo sicuro delle applicazioni.

Task 1: distribuire il cluster Kubernetes su OKE (con un'istanza bastion e di operatore)

Assicurarsi di disporre di un cluster Kubernetes distribuito su OKE.

Per distribuire il cluster Kubernetes in OKE, utilizzare uno dei seguenti metodi:
- Distribuisci un cluster Kubernetes con Terraform utilizzando Oracle Cloud Infrastructure Kubernetes Engine: distribuisci un singolo cluster Kubernetes in OKE utilizzando Terraform.
- Usa Terraform per distribuire più cluster Kubernetes in diverse aree OCI utilizzando OKE e crea una rete mesh completa utilizzando RPC: distribuisci più cluster Kubernetes in più aree in OKE utilizzando Terraform.
- Task 1: creare un nuovo cluster Kubernetes e verificare i componenti: distribuire un cluster Kubernetes in OKE utilizzando la modalità Creazione rapida.
- Task 1: distribuire un cluster Kubernetes utilizzando OKE: distribuire un cluster Kubernetes in OKE utilizzando la modalità Creazione personalizzata.
In questa esercitazione verrà utilizzato il comando Distribuisci un cluster Kubernetes con Terraform utilizzando Oracle Cloud Infrastructure Kubernetes Engine come cluster Kubernetes di base su OKE per spiegare come è possibile utilizzare un tunnel SSH per accedere a un'applicazione basata su container distribuita su OKE con localhost.

Esaminiamo rapidamente l'ambiente OKE OCI per impostare la fase.
Rete cloud virtuale (VCN)

Eseguire il login a OCI Console, passare a Networking e Reti cloud virtuali.
- Rivedere la VCN denominata oke.
- Fare clic sulla VCN oke.
Subnet

Andare alla pagina Dettagli VCN.
1. Fare clic su Subnet.
2. Rivedere le subnet distribuite.
Gateway

Andare alla pagina Dettagli VCN.
1. Fare clic su Gateway Internet.
2. Rivedere il gateway Internet creato.
1. Fare clic su Gateway NAT.
2. Rivedere il gateway NAT creato.
1. Fare clic su Gateway del servizio.
2. Rivedere il gateway di servizio creato.
1. Fare clic su Elenchi di sicurezza.
2. Rivedere le liste di sicurezza create.
Pool di nodi

Passare a Servizi per sviluppatori e Container e artifact.
1. Fare clic su Kubernetes Clusters (OKE).
2. Fare clic sul cluster oke.
1. Fare clic su Pool di nodi.
2. Rivedere i pool di nodi.
Istanze

Passare a Computazione e Istanze.
1. Fare clic su Istanze.
2. Rivedi le distribuzioni dei nodi di lavoro Kubernetes.
3. Rivedere la distribuzione dell'host Bastion.
4. Rivedi la distribuzione dell'operatore Kubernetes.
La seguente immagine illustra una panoramica completa di ciò che sarà il nostro punto di partenza per il contenuto rimanente di questo tutorial.
L'immagine seguente illustra una vista semplificata della figura precedente. Utilizzeremo questa figura nel resto di questo tutorial.

Task 2: distribuire un server Web NGINX nel cluster Kubernetes

Non è possibile accedere direttamente all'operatore da Internet e dobbiamo passare attraverso l'host Bastion.

In questo tutorial, stiamo utilizzando uno script SSH fornito da Ali Mukadam per connettersi all'operatore utilizzando un unico comando SSH. Lo script e il metodo per la connessione sono disponibili qui: Task 4: Utilizzare il bastion e l'operatore per verificare la connettività. Sarà necessario questo script più avanti in questa esercitazione, quindi assicurarsi di utilizzarlo.
- Impostare una sessione SSH per l'operatore Kubernetes.
- Rivedere i nodi di lavoro attivi con il comando kubectl get nodes.
- Rivedere tutti i nodi di lavoro attivi.

Per creare un'applicazione NGINX di esempio in esecuzione all'interno di un contenitore, creare un file YAML denominato modified2_nginx_ext_lb.yaml con il seguente codice sull'operatore.

Il file YAML contiene il codice per creare l'applicazione server Web NGINX con 3 repliche e creerà anche un servizio del tipo load balancer.

modified2_nginx_ext_lb.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
  app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
  - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
  annotations:
    oci.oraclecloud.com/load-balancer-type: "lb"
    service.beta.kubernetes.io/oci-load-balancer-internal: "true"
    service.beta.kubernetes.io/oci-load-balancer-subnet1: "ocid1.subnet.oc1.me-abudhabi-1.aaaaaaaaguwakvc6jxxxxxxxxxxxxxxxxxxxu7rixvdf5urvpxldhya"
    service.beta.kubernetes.io/oci-load-balancer-shape: "flexible"
    service.beta.kubernetes.io/oci-load-balancer-shape-flex-min: "50"
    service.beta.kubernetes.io/oci-load-balancer-shape-flex-max: "100"
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx

Vogliamo rendere questa applicazione accessibile internamente e decidere di creare il servizio di tipo load balancer collegato alla subnet privata del load balancer.

Per assegnare il servizio di tipo load balancer a una subnet privata del load balancer, è necessario disporre dell'OCID della subnet della subnet del load balancer privato e aggiungere il codice seguente nella sezione annotations.

annotations:
  oci.oraclecloud.com/load-balancer-type: "lb"
  service.beta.kubernetes.io/oci-load-balancer-internal: "true"
  service.beta.kubernetes.io/oci-load-balancer-subnet1: "ocid1.subnet.oc1.me-abudhabi-1.aaaaaaaaguwakvcxxxxxxxxxxxxxxxxxxxxxxxxxxxxixvdf5urvpxldhya"
  service.beta.kubernetes.io/oci-load-balancer-shape: "flexible"
  service.beta.kubernetes.io/oci-load-balancer-shape-flex-min: "50"
  service.beta.kubernetes.io/oci-load-balancer-shape-flex-max: "100"

Per ottenere l'OCID della subnet del load balancer privato, fare clic sulla subnet interna del load balancer.

Fare clic su Mostra e Copia per l'OCID della subnet del load balancer privato completo. Utilizzare questo OCID nella sezione annotations.
Per distribuire l'applicazione NGINX e il servizio di tipo load balancer, eseguire i comandi riportati di seguito.
1. Per creare il file YAML sull'operatore.
```
nano modified2_nginx_ext_lb.yaml
```
2. Per distribuire l'applicazione NGINX con il servizio di tipo load balancer.
```
kubectl apply -f modified2_nginx_ext_lb.yaml
```
  Per verificare se l'applicazione NGINX è stata distribuita correttamente (non visualizzata nell'immagine).
```
kubectl get pods
```
3. Per verificare se il servizio del load balancer del tipo è stato distribuito correttamente.
```
kubectl get svc
```
4. Si noti che la distribuzione del servizio del load balancer di tipo è riuscita.
Quando esaminiamo la subnet interna del load balancer, possiamo notare che il blocco CIDR per questa subnet è 10.0.2.0/27. Il nuovo servizio del load balancer ha l'indirizzo IP 10.0.2.3.
Per verificare l'oggetto load balancer nella console OCI, andare a Networking, Load balancer e fare clic su Load balancer.
L'immagine seguente illustra la distribuzione eseguita fino ad ora. Si noti che il load balancer viene aggiunto.

Test della nuova pod/applicazione

Approccio 1: Da un pod temporaneo

Per verificare se l'applicazione NGINX appena distribuita funziona con il servizio del load balancer di tipo, è possibile eseguire un test di connettività interno utilizzando un pod temporaneo.

Esistono diversi modi per testare la connettività all'applicazione, un modo sarebbe aprire un browser e verificare se è possibile accedere alla pagina Web. Ma quando non abbiamo un browser disponibile possiamo fare un altro test rapido distribuendo un pod temporaneo.

Per creare un pod temporaneo e utilizzarlo per i test di connettività, vedere Task 3: Distribuire un'applicazione Web e un servizio Web di esempio.
- Eseguire il comando riportato di seguito:
  1. Per ottenere l'indirizzo IP del servizio load balancer interno.
    kubectl get svc
  2. Per distribuire un pod di esempio per eseguire il test della connettività dell'applicazione Web.
    kubectl run --rm -i -t --image=alpine test-$RANDOM -- sh
  3. Testare la connettività al server Web utilizzando wget.
    wget -qO- http://<ip-of-internal-lb-service>
  4. Si noti il codice HTML restituito dal server Web, la conferma del server Web e la connettività mediante il servizio di bilanciamento del carico interno funzionano.
- Eseguire il comando seguente per uscire dal pod temporaneo.
```
exit
```
  Si noti che il pod viene eliminato immediatamente dopo la chiusura dell'interfaccia della riga di comando.
- L'immagine seguente illustra la distribuzione eseguita fino ad ora. Si noti che il pod distribuito temporaneamente si sta connettendo al servizio di tipo IP del load balancer per eseguire il test della connettività.
Approccio 2: dal computer locale
- Eseguire il comando seguente per eseguire il test della connettività all'applicazione NGINX di test con il servizio di bilanciamento del carico di tipo dal laptop locale.
```
iwhooge@iwhooge-mac ~ % wget -qO- <ip-of-internal-lb-service>
```
  Poiché noterai che attualmente non funziona poiché il servizio del load balancer di tipo ha un indirizzo IP interno e questo è raggiungibile solo all'interno dell'ambiente Kubernetes.
- Eseguire il comando seguente per provare ad accedere all'applicazione NGINX utilizzando l'indirizzo IP locale con una porta personalizzata 8080.
```
iwhooge@iwhooge-mac ~ % wget -qO- 127.0.0.1:8080
iwhooge@iwhooge-mac ~ %
```
  Per ora, questo non funziona, ma useremo lo stesso comando più avanti in questo tutorial dopo aver impostato il tunnel SSH.
L'immagine seguente illustra la distribuzione eseguita fino ad ora. La connessione tunnel all'indirizzo IP locale non funziona.

Task 3: Creare uno script di configurazione SSH con voci Localhost

Per consentire il funzionamento del tunnel SSH, è necessario aggiungere la seguente voce nel file di configurazione SSH situato nella cartella /Users/iwhooge/.ssh.

Eseguire il comando nano /Users/iwhooge/.ssh/config per modificare il file di configurazione.
Aggiungere la riga seguente nella sezione Host operator47.
```
LocalForward 8080 127.0.0.1:8080
```

L'output del file di configurazione SSH.

iwhooge@iwhooge-mac .ssh % pwd
/Users/iwhooge/.ssh

iwhooge@iwhooge-mac .ssh % more config
Host bastion47
    HostName 129.xxx.xxx.xxx
    user opc
    IdentityFile ~/.ssh/id_rsa
    UserKnownHostsFile /dev/null
    StrictHostKeyChecking=no
    TCPKeepAlive=yes
    ServerAliveInterval=50

Host operator47
    HostName 10.0.0.11
    user opc
    IdentityFile ~/.ssh/id_rsa
    ProxyJump bastion47
    UserKnownHostsFile /dev/null
    StrictHostKeyChecking=no
    TCPKeepAlive=yes
    ServerAliveInterval=50
    LocalForward 8080 127.0.0.1:8080
iwhooge@iwhooge-mac .ssh %

Si noti che il comando LocalForward viene aggiunto al file di configurazione SSH.

Task 4: Impostare il tunnel SSH e connettersi al server Web NGINX utilizzando Localhost

Se si è connessi con SSH all'operatore, disconnettere tale sessione.
1. Riconnettersi all'operatore utilizzando di nuovo lo script.
```
iwhooge@iwhooge-mac ~ % ssh operator47
```
2. Eseguire il comando riportato di seguito per ottenere l'indirizzo IP del servizio del load balancer interno.
```
[opc@o-sqrtga ~]$ kubectl get svc
```
3. Eseguire il comando riportato di seguito sull'operatore (finestra SSH) per impostare il tunnel SSH e inoltrare tutto il traffico che va all'host locale 8080 al servizio di tipo load balancer 80. Il servizio di tipo load balancer inoltrerà quindi il traffico all'applicazione NGINX.
```
[opc@o-sqrtga ~]$ k port-forward svc/my-nginx-svc 8080:80
```
  Notare i messaggi di inoltro nella finestra SSH che la porta localhost 8080 viene inoltrata alla porta 80.
```
Forwarding from 127.0.0.1:8080 -> 80
Forwarding from [::1]:8080 -> 80
```
Testare la connettività dal computer locale e verificare se la connettività funziona utilizzando un indirizzo IP locale (127.0.0.1) con la porta 8080 e verificare se ciò consente di connettersi all'applicazione NGINX all'interno dell'ambiente OKE.
Aprire un nuovo terminale ed eseguire il comando seguente per eseguire il test della connettività.
```
iwhooge@iwhooge-mac ~ % wget -qO- 127.0.0.1:8080
```

Si noti che si otterrà il seguente output nel terminale del computer locale, il che significa che funziona.

iwhooge@iwhooge-mac ~ % wget -qO- 127.0.0.1:8080
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>
iwhooge@iwhooge-mac ~ %

Nella finestra SSH dell'operatore, notare che l'output è cambiato e che una nuova riga ha aggiunto Gestione della connessione per 8080.
Un test rapido che utilizza un browser Web mostra l'output riportato di seguito.
L'immagine seguente illustra la distribuzione eseguita fino ad ora. Si noti che la connessione con tunneling all'indirizzo IP locale funziona.

Task 5: Distribuire un MySQL Database Service sul cluster Kubernetes

Possiamo raggiungere l'applicazione NGINX attraverso il tunnel SSH, ora aggiungere un servizio di database MySQL in esecuzione all'interno dell'ambiente OKE.

Per impostare un servizio di database MySQL all'interno di un ambiente Kubernetes, è necessario creare:
- Un segreto per la protezione delle password.
- Volume persistente e richiesta di volume persistente per lo storage del database.
- Servizio di database MYSQL con un servizio di tipo load balancer.

Eseguire i comandi seguenti per:

Creare la password per il servizio di database MySQL.

nano mysql-secret.yaml

Copiare il seguente codice YAML in mysql-secret.yaml.

apiVersion: v1
kind: Secret
metadata:
  name: mysql-secret
type: kubernetes.io/basic-auth
stringData:
  password: Or@cle1

Applicare il codice YAML.
```
kubectl apply -f mysql-secret.yaml
```

Creare lo storage per il servizio di database MySQL.

nano mysql-storage.yaml

Copiare il seguente codice YAML in mysql-storage.yaml.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: mysql-pv-volume
  labels:
    type: local
spec:
  storageClassName: manual
  capacity:
    storage: 20Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: "/mnt/data"
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-pv-claim
spec:
  storageClassName: manual
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi

Applicare il codice YAML.
```
kubectl apply -f mysql-storage.yaml
```

Creare il servizio di database MySQL e il servizio di tipo load balancer.

nano mysql-deployment.yaml

Copiare il seguente codice YAML in mysql-deployment.yaml.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mysql
spec:
  selector:
    matchLabels:
      app: mysql
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
      - image: mysql:latest
        name: mysql
        env:
        - name: MYSQL_ROOT_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysql-secret
              key: password
        ports:
        - containerPort: 3306
          name: mysql
        volumeMounts:
        - name: mysql-persistent-storage
          mountPath: /var/lib/mysql
      volumes:
      - name: mysql-persistent-storage
        persistentVolumeClaim:
          claimName: mysql-pv-claim
---
apiVersion: v1
kind: Service
metadata:
  name: my-mysql-svc
  labels:
    app: mysql
  annotations:
    oci.oraclecloud.com/load-balancer-type: "lb"
    service.beta.kubernetes.io/oci-load-balancer-internal: "true"
    service.beta.kubernetes.io/oci-load-balancer-subnet1: "ocid1.subnet.oc1.me-abudhabi-1.aaaaaaaaguwakvc6xxxxxxxxxxxxxxxxxxxxxx2rseu7rixvdf5urvpxldhya"
    service.beta.kubernetes.io/oci-load-balancer-shape: "flexible"
    service.beta.kubernetes.io/oci-load-balancer-shape-flex-min: "50"
    service.beta.kubernetes.io/oci-load-balancer-shape-flex-max: "100"
spec:
  type: LoadBalancer
  ports:
  - port: 3306
  selector:
    app: mysql

Applicare il codice YAML.
```
kubectl apply -f mysql-deployment.yaml
```
Verificare se la distribuzione del servizio di database MySQL è riuscita.
```
kubectl get pod
```
Tenere presente che la distribuzione del servizio di database MySQL è riuscita.
Verificare se la distribuzione del servizio di tipo load balancer è riuscita.
```
kubectl get svc
```
Tenere presente che la distribuzione del servizio di tipo load balancer è riuscita.

immagine

Per verificare l'oggetto load balancer nella console OCI, andare a Networking, Load balancer e fare clic sul load balancer.
Per accedere alla console terminale del servizio di database MySQL, è possibile utilizzare il comando kubectl exec e il comando tunnel SSH localhost.
1. Eseguire il comando seguente per accedere alla console di terminale dall'operatore.
```
kubectl exec --stdin --tty mysql-74f8bf98c5-bl8vv -- /bin/bash
```
2. Eseguire il comando riportato di seguito per accedere alla console del servizio di database MySQL.
```
mysql -p
```
3. Immettere la password specificata nel file mysql-secret.yaml e notare il messaggio di benvenuto del servizio di database MySQL.
4. Eseguire la query SQL seguente per visualizzare la lista di tutti i database MySQL all'interno del servizio di database.
```
SHOW DATABASES;
```
Ora puoi accedere alla console di gestione dei servizi di database MySQL dall'ambiente Kubernetes.
L'immagine seguente illustra la distribuzione eseguita fino ad ora. Si noti che il servizio MySQL con il servizio di tipo load balancer viene distribuito.

Task 6: aggiunta di voci Localhost aggiuntive nello script di configurazione SSH

Aggiungere ulteriori voci localhost all'interno dello script di configurazione SSH per accedere al nuovo servizio di database MySQL.

Per consentire il funzionamento del tunnel SSH per il servizio di database MySQL, è necessario aggiungere la voce seguente nel file di configurazione SSH situato nella cartella /Users/iwhooge/.ssh.
Eseguire il comando nano /Users/iwhooge/.ssh/config per modificare il file di configurazione.
Aggiungere la riga seguente nella sezione Host operator47.
```
LocalForward 8306 127.0.0.1:8306
```

Output del file di configurazione SSH.

Host bastion47
    HostName 129.xxx.xxx.xxx
    user opc
    IdentityFile ~/.ssh/id_rsa
    UserKnownHostsFile /dev/null
    StrictHostKeyChecking=no
    TCPKeepAlive=yes
    ServerAliveInterval=50
Host operator47
    HostName 10.0.0.11
    user opc
    IdentityFile ~/.ssh/id_rsa
    ProxyJump bastion47
    UserKnownHostsFile /dev/null
    StrictHostKeyChecking=no
    TCPKeepAlive=yes
    ServerAliveInterval=50
    LocalForward 8080 127.0.0.1:8080
    LocalForward 8306 127.0.0.1:8306

Si noti che il comando LocalForward viene aggiunto al file di configurazione SSH.

Task 7: impostare il tunnel SSH e connettersi a MySQL Database utilizzando Localhost

Per eseguire il test della connessione al servizio di database MySQL dal computer locale, è necessario scaricare e installare MySQL Workbench sul computer locale.
1. Aprire nuovamente un nuovo terminale all'operatore utilizzando lo script. Lasciare aperto l'altro terminale.
```
iwhooge@iwhooge-mac ~ % ssh operator47
```
2. Eseguire il comando riportato di seguito nella finestra SSH dell'operatore per impostare il tunnel SSH e inoltrare tutto il traffico che va all'host locale 8306 al servizio di tipo load balancer 3306. Il servizio di tipo load balancer inoltrerà quindi il traffico al servizio di database MySQL.
```
[opc@o-sqrtga ~]$ k port-forward svc/my-mysql-svc 8306:3306
```
3. Notare i messaggi di inoltro nella finestra SSH che la porta localhost 8306 viene inoltrata alla porta 3306.
```
Forwarding from 127.0.0.1:8306 -> 3306
Forwarding from [::1]:8306 -> 3306
```
L'applicazione MySQL Workbench è installata e la sessione SSH e il tunnel sono stabiliti, aprire l'applicazione MySQL Workbench sul computer locale.
Fare clic sul segno + per aggiungere una nuova connessione MySQL.
In Imposta nuova connessione, immettere le informazioni riportate di seguito.
1. Nome connessione: immettere un nome.
2. Nome host: immettere l'indirizzo IP 127.0.0.1 (localhost in quanto viene eseguito il tunneling del traffico).
3. Porta: immettere la porta 8306, ovvero la porta utilizzata per l'inoltro del tunnel locale per il servizio di database MySQL.
4. Fare clic su Esegui test connessione.
1. Password: immettere la password specificata nel file mysql-secret.yaml.
2. Fare clic su OK.
Fare clic su Continua comunque per ignorare l'avvertenza di connessione. Questa avvertenza viene fornita poiché la versione dell'applicazione MySQL Workbench e la versione del servizio di database MySQL distribuita potrebbero non essere compatibili.
1. Si noti il messaggio di connessione riuscito.
2. Fare clic su OK.
3. Fare clic su OK per salvare la connessione MySQL.
Fare clic sulla connessione MySQL salvata per aprire la sessione.
Prendere nota del messaggio Si prega di stare accanto....
Fare clic su Continua comunque per ignorare l'avvertenza di connessione.
1. Eseguire la query SQL seguente per impostare una lista di tutti i database MySQL all'interno del servizio di database.
```
SHOW DATABASES;
```
2. Fare clic sull'icona del fulmine.
3. Notare l'output di tutti i database MySQL all'interno del servizio di database MySQL.
Nella finestra SSH operatore l'output è cambiato e una nuova riga ha aggiunto Gestione della connessione per 8306.
Ci sono più voci perché abbiamo fatto più connessioni, una per ogni:
- Esegui il test.
- Connessione effettiva.
- Query SQL.
- Test che abbiamo fatto prima (aggiuntivo).
Ora possiamo aprire più sessioni SSH verso l'operatore ed eseguire più comandi tunnel per diverse applicazioni contemporaneamente. Notate le seguenti finestre.
1. Il terminale SSH con il comando tunnel per il servizio di database MySQL.
2. Connessione che utilizza l'applicazione MYSQL Workbench dal computer locale al servizio di database MySQL utilizzando l'indirizzo IP localhost 127.0.0.1.
3. Il terminale SSH con il comando tunnel per l'applicazione NGINX.
4. La connessione tramite Safari Internet Browser dal computer locale all'applicazione NGINX utilizzando l'indirizzo IP localhost 127.0.0.1.
L'immagine seguente illustra la distribuzione eseguita fino ad ora. Si noti che la connessione con tunneling all'indirizzo IP locale funziona contemporaneamente per l'applicazione NGINX e il servizio di database MySQL con l'uso di più sessioni SSH e tunnel SSH.

Task 8: Cancellare tutte le applicazioni e i servizi

Eseguire i comandi riportati di seguito per eseguire il cleanup dell'applicazione NGINX distribuita e del servizio associato.

kubectl get pods
kubectl delete service my-nginx-svc -n default
kubectl get pods
kubectl get svc
kubectl delete deployment my-nginx --namespace default
kubectl get svc

Eseguire i comandi riportati di seguito per eseguire il cleanup del servizio di database MySQL distribuito e del servizio, dello storage e della password associati.
```
kubectl delete deployment,svc mysql
kubectl delete pvc mysql-pv-claim
kubectl delete pv mysql-pv-volume
kubectl delete secret mysql-secret
```
L'immagine riportata di seguito illustra la distribuzione eseguita fino ad ora in cui si dispone di un ambiente pulito e si può ricominciare.

Passi successivi

La protezione dell'accesso ai cluster OKE è un passo fondamentale nello sviluppo di applicazioni moderne e il tunneling SSH offre una soluzione solida e semplice. Implementando i passaggi di questa esercitazione, gli sviluppatori possono salvaguardare le proprie risorse, semplificare i flussi di lavoro e mantenere il controllo sulle connessioni sensibili per più applicazioni. L'integrazione del tunnel SSH nella configurazione OKE non solo migliora la sicurezza, ma riduce anche i rischi associati all'esposizione delle risorse alla rete Internet pubblica. Grazie a queste pratiche, puoi utilizzare con sicurezza i cluster OKE e concentrarti sulla creazione di applicazioni scalabili, sicure ed efficienti.

Conferme

Autore - Iwan Hoogendoorn (esperto di rete OCI)

Altre risorse di apprendimento

Esplora altri laboratori su docs.oracle.com/learn o accedi a più contenuti gratuiti sulla formazione su Oracle Learning YouTube channel. Inoltre, visita education.oracle.com/learning-explorer per diventare un Oracle Learning Explorer.

Per la documentazione del prodotto, visita l'Oracle Help Center.

Titolo e informazioni sul copyright

Leverage SSH Tunneling with Oracle Cloud Infrastructure Kubernetes Engine for Secure Application Development

G21951-02

December 2024

Oracle e/o relative consociate.