Configurazione Multi-Cluster e dei Namespace per Sviluppatori

In questo articolo affronteremo i seguenti temi:

A4 81

Una volta messa su tutta la topologia dell’ installazione multi-cluster di TAP ci ritroveremo con un ambiente costruito su più cluster e ciascuno con un profilo di TAP differente. La soluzione al momento prevede View-Buil- Run-Iterate.

L’installazione dei profili viene affrontata nell’articolo precedente: “Installare Tanzu Application Platform con profili Multicluster”.

Dopo aver esaminato l’installazione di una topologia multi-cluster nel nostro articolo precedente, è giunto il momento di affrontare la configurazione dell’ambiente TAP.

In questa fase critica, scopriremo come assicurare che tutti i componenti e le risorse lavorino sinergicamente per supportare le tue applicazioni in modo efficiente.

Configurazione multi-cluster

Per interagire con la Tanzu Application Platform (TAP) da un contesto specifico di cluster, dovrai prima modificare la tua configurazione. Utilizza il seguente comando per impostare il contesto sul cluster “View”:

				
					$ kubectl config use-context tap-view-cluster
Switched to context "tap-view-cluster".

Ciò assicura che i comandi successivi vengano eseguiti all’interno del contesto del cluster “View”.

Conservare il Certificato CA dal Cluster "View"

Per stabilire una comunicazione sicura con il cluster “View”, è necessario conservare il certificato CA. Esegui i seguenti comandi per recuperare il certificato CA e creare una risorsa di tipo Secret:

				
					CA_CERT=$(kubectl get secret -n metadata-store ingress-cert -o json | jq -r ".data.\"ca.crt\"")

cat <<EOF > store_ca.yaml
---
apiVersion: v1
kind: Secret
type: Opaque
metadata:
  name: store-ca-cert
  namespace: metadata-store-secrets
data:
  ca.crt: $CA_CERT
EOF

I comandi sopra recuperano il certificato CA dal cluster “View” e creano una risorsa Secret chiamata “store-ca-cert” nello namespace “metadata-store-secrets”. Questo Secret verrà utilizzato per garantire una comunicazione sicura tra i cluster.

Conservare il Token di Autenticazione dal Cluster "View"

Per l’accesso autenticato al cluster “View”, avrai bisogno di un token di autenticazione. Utilizza i seguenti comandi per recuperare il token, decodificarlo e conservarlo in modo sicuro:

				
					AUTH_TOKEN=$(kubectl get secrets metadata-store-read-write-client -n metadata-store -o jsonpath="{.data.token}" | base64 -

Il comando sopra recupera il token di autenticazione e lo decodifica dall’encoding in base64. Questo token potrà essere utilizzato per interazioni autorizzate con il cluster “View”.

Con questi passaggi completati, hai configurato con successo il tuo ambiente per interagire con il cluster “View” all’interno della Tanzu Application Platform. Questo stabilisce le basi per gestire e interagire con le risorse in questo contesto specifico di cluster.

Passare al Contesto del Cluster "Build"

Per continuare con la gestione delle configurazioni all’interno della Tanzu Application Platform (TAP), è necessario spostarsi al contesto del cluster “Build”. Esegui il seguente comando per impostare il contesto sul cluster “Build”:

				
					$ kubectl config use-context tap-build-cluster
Switched to context "tap-build-cluster".

Ciò garantirà che le operazioni successive vengano eseguite all’interno del contesto del cluster “Build”.

Applicare il Certificato CA e il Token di Autenticazione al Cluster "Build"

Affinché il cluster “Build” possa comunicare in modo sicuro con altri cluster, è necessario applicare il certificato CA e il token di autenticazione. Esegui i seguenti comandi:

				
					$ kubectl create ns metadata-store-secrets

$ kubectl apply -f store_ca.yaml

$ kubectl create secret generic store-auth-token --from-literal=auth_token=$AUTH_TOKEN -n metadata-store-secrets

I comandi sopra creano un namespace “metadata-store-secrets” per conservare in modo sicuro il certificato CA e il token di autenticazione. Il certificato CA è stato precedentemente salvato nel file store_ca.yaml. Il token di autenticazione è ora archiviato nel Secret denominato “store-auth-token”.

Aggiornare il Pacchetto Installato "tap"

Per garantire che le modifiche e le configurazioni siano effettive nel cluster “Build”, esegui il seguente comando per aggiornare il pacchetto installato “tap”:

				
					$ tanzu package installed update tap -f tap-values-build.yaml -n tap-install

Questo comando applica le nuove configurazioni definite nel file tap-values-build.yaml al pacchetto “tap” installato nel cluster “Build”.

Con questi passaggi, hai completato la configurazione dell’ambiente TAP nel contesto del cluster “Build”.

Configurazione dei Namespace degli Sviluppatori

Per consentire agli sviluppatori di interagire in modo sicuro con le risorse all’interno dei loro namespace, è necessario configurare la condivisione dei certificati CA e dei token di autenticazione. Utilizza i seguenti comandi per creare le configurazioni necessarie:

				
					cat <<EOF | kubectl apply -f -
---
apiVersion: secretgen.carvel.dev/v1alpha1
kind: SecretExport
metadata:
  name: store-ca-cert
  namespace: metadata-store-secrets
spec:
  toNamespaces: [dev]
---
apiVersion: secretgen.carvel.dev/v1alpha1
kind: SecretExport
metadata:
  name: store-auth-token
  namespace: metadata-store-secrets
spec:
  toNamespaces: [dev]
EOF

I comandi sopra creano le configurazioni per esportare il certificato CA e il token di autenticazione dal namespace “metadata-store-secrets” al namespace “dev “. Ciò consentirà agli sviluppatori all’interno di “dev ” di accedere in modo sicuro a risorse e servizi condivisi.

Visualizzazione delle risorse su più cluster nella GUI della piattaforma applicativa Tanzu

È possibile configurare la GUI di Tanzu Application Platform per recuperare i dettagli degli oggetti Kubernetes da più cluster e quindi far emergere tali dettagli nei vari plug-in della GUI di Tanzu Application Platform.

Copia questo contenuto YAML in un file chiamato “tap-gui-viewer-service-account-rbac.yaml”

				
					apiVersion: v1
kind: Namespace
metadata:
  name: tap-gui
---
apiVersion: v1
kind: ServiceAccount
metadata:
  namespace: tap-gui
  name: tap-gui-viewer
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: tap-gui-read-k8s
subjects:
- kind: ServiceAccount
  namespace: tap-gui
  name: tap-gui-viewer
roleRef:
  kind: ClusterRole
  name: k8s-reader
  apiGroup: rbac.authorization.k8s.io
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: k8s-reader
rules:
- apiGroups: ['']
  resources: ['pods', 'pods/log', 'services', 'configmaps']
  verbs: ['get', 'watch', 'list']
- apiGroups: ['apps']
  resources: ['deployments', 'replicasets']
  verbs: ['get', 'watch', 'list']
- apiGroups: ['autoscaling']
  resources: ['horizontalpodautoscalers']
  verbs: ['get', 'watch', 'list']
- apiGroups: ['networking.k8s.io']
  resources: ['ingresses']
  verbs: ['get', 'watch', 'list']
- apiGroups: ['networking.internal.knative.dev']
  resources: ['serverlessservices']
  verbs: ['get', 'watch', 'list']
- apiGroups: [ 'autoscaling.internal.knative.dev' ]
  resources: [ 'podautoscalers' ]
  verbs: [ 'get', 'watch', 'list' ]
- apiGroups: ['serving.knative.dev']
  resources:
  - configurations
  - revisions
  - routes
  - services
  verbs: ['get', 'watch', 'list']
- apiGroups: ['carto.run']
  resources:
  - clusterconfigtemplates
  - clusterdeliveries
  - clusterdeploymenttemplates
  - clusterimagetemplates
  - clusterruntemplates
  - clustersourcetemplates
  - clustersupplychains
  - clustertemplates
  - deliverables
  - runnables
  - workloads
  verbs: ['get', 'watch', 'list']
- apiGroups: ['source.toolkit.fluxcd.io']
  resources:
  - gitrepositories
  verbs: ['get', 'watch', 'list']
- apiGroups: ['source.apps.tanzu.vmware.com']
  resources:
  - imagerepositories
  - mavenartifacts
  verbs: ['get', 'watch', 'list']
- apiGroups: ['conventions.carto.run']
  resources:
  - podintents
  verbs: ['get', 'watch', 'list']
- apiGroups: ['kpack.io']
  resources:
  - images
  - builds
  verbs: ['get', 'watch', 'list']
- apiGroups: ['scanning.apps.tanzu.vmware.com']
  resources:
  - sourcescans
  - imagescans
  - scanpolicies
  verbs: ['get', 'watch', 'list']
- apiGroups: ['tekton.dev']
  resources:
  - taskruns
  - pipelineruns
  verbs: ['get', 'watch', 'list']
- apiGroups: ['kappctrl.k14s.io']
  resources:
  - apps
  verbs: ['get', 'watch', 'list']

Questo set di manifesti definisce la configurazione necessaria per garantire che l’account di servizio “tap-gui-viewer” nel namespace “tap-gui” abbia le autorizzazioni appropriate per visualizzare e monitorare risorse chiave nei namespace indicati.

Questa configurazione aiuta a garantire che gli sviluppatori nel namespace “Dev ” abbiano accesso solo alle risorse necessarie per svolgere le loro attività.

Configurare i Cluster per la Comunicazione Interna

Passare al Contesto del Cluster “RUN”

Per continuare con la configurazione dell’ambiente e la gestione delle autorizzazioni nel cluster “run”, eseguire il seguente comando per impostare il contesto sul cluster “RUN”:

				
					$ kubectl config use-context tap-run-cluster
Switched to context "tap-run-cluster".

Ciò assicurerà che le operazioni successive vengano eseguite all’interno del contesto del cluster “run”.

Creare Namespace, ServiceAccount, ClusterRole e ClusterRoleBinding

Esegui il seguente comando per creare il namespace, il service account, il cluster role e il cluster role binding utilizzando il file tap-gui-viewer-service-account-rbac.yaml:

				
					$ kubectl create -f tap-gui-viewer-service-account-rbac.yaml
namespace/tap-gui created
serviceaccount/tap-gui-viewer created
clusterrolebinding.rbac.authorization.k8s.io/tap-gui-read-k8s created
clusterrole.rbac.authorization.k8s.io/k8s-reader created

Questi comandi creeranno il namespace “tap-gui”, il service account “tap-gui-viewer”, il cluster role binding “tap-gui-read-k8s” e il cluster role “k8s-reader” nel cluster “run”. Questo consentirà all’account di servizio “tap-gui-viewer” di visualizzare le risorse all’interno del namespace “tap-gui”.

Scoprire i Valori CLUSTER_URL e CLUSTER_TOKEN

Per interagire con il cluster “run” utilizzando l’account di servizio “tap-gui-viewer”, esegui i seguenti comandi per scoprire i valori di CLUSTER_URL e CLUSTER_TOKEN:

				
					CLUSTER_URL=$(kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}')

kubectl apply -f - <<EOF
apiVersion: v1
kind: Secret
metadata:
  name: tap-gui-viewer
  namespace: tap-gui
  annotations:
    kubernetes.io/service-account.name: tap-gui-viewer
type: kubernetes.io/service-account-token
EOF


CLUSTER_TOKEN=$(kubectl -n tap-gui get secret tap-gui-viewer -o=json \
| jq -r '.data["token"]' \
| base64 --decode)

echo CLUSTER_URL: $CLUSTER_URL
echo CLUSTER_TOKEN: $CLUSTER_TOKEN

Questi comandi otterranno l’URL del cluster “run” e il token dell’account di servizio “tap-gui-viewer” all’interno del namespace “tap-gui”. Queste informazioni sono essenziali per interagire con il cluster “run” in modo sicuro e autorizzato.

Con questi passaggi, hai configurato con successo l’ambiente nel contesto del cluster “run” e hai ottenuto le informazioni necessarie per l’accesso sicuro tramite l’account di servizio “tap-gui-viewer”.

Ripetere gli Step per il Cluster di "BUILD" e “ITERATE”

Ora che hai completato la configurazione per il cluster “RUN”, dovrai ripetere gli stessi passaggi per il cluster di “BUILD” e “ITERATE”.

Questo assicurerà che anche il cluster di “ITERATE” e “BUILD” siano configurati correttamente per l’accesso sicuro tramite l’account di servizio “tap-gui-viewer”.

Cambia il contesto, applica RBAC e Scopri nuovamente i valori di CLUSTER_URL e CLUSTER_TOKEN per il cluster di Build e Iterate.

				
					## Switch the context to BUILD Cluster

$ kubectl config use-context tap-build-cluster
Switched to context "tap-build-cluster".

## create Namespace, ServiceAccount, ClusterRole, and ClusterRoleBinding by running:

$ kubectl create -f tap-gui-viewer-service-account-rbac.yaml
namespace/tap-gui created
serviceaccount/tap-gui-viewer created
clusterrolebinding.rbac.authorization.k8s.io/tap-gui-read-k8s created
clusterrole.rbac.authorization.k8s.io/k8s-reader created

## Discover the CLUSTER_URL and CLUSTER_TOKEN values:

CLUSTER_URL=$(kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}')

kubectl apply -f - <<EOF
apiVersion: v1
kind: Secret
metadata:
  name: tap-gui-viewer
  namespace: tap-gui
  annotations:
    kubernetes.io/service-account.name: tap-gui-viewer
type: kubernetes.io/service-account-token
EOF

CLUSTER_TOKEN=$(kubectl -n tap-gui get secret tap-gui-viewer -o=json \
| jq -r '.data["token"]' \
| base64 --decode)

echo CLUSTER_URL: $CLUSTER_URL
echo CLUSTER_TOKEN: $CLUSTER_TOKEN



## Switch the context to ITERATE Cluster

$ kubectl config use-context tap-iterate-cluster
Switched to context "tap-iterate-cluster".

## create Namespace, ServiceAccount, ClusterRole, and ClusterRoleBinding by running:

$ kubectl create -f tap-gui-viewer-service-account-rbac.yaml
namespace/tap-gui created
serviceaccount/tap-gui-viewer created
clusterrolebinding.rbac.authorization.k8s.io/tap-gui-read-k8s created
clusterrole.rbac.authorization.k8s.io/k8s-reader created

## Discover the CLUSTER_URL and CLUSTER_TOKEN values:

CLUSTER_URL=$(kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}')

kubectl apply -f - <<EOF
apiVersion: v1
kind: Secret
metadata:
  name: tap-gui-viewer
  namespace: tap-gui
  annotations:
    kubernetes.io/service-account.name: tap-gui-viewer
type: kubernetes.io/service-account-token
EOF

CLUSTER_TOKEN=$(kubectl -n tap-gui get secret tap-gui-viewer -o=json \
| jq -r '.data["token"]' \
| base64 --decode)

echo CLUSTER_URL: $CLUSTER_URL
echo CLUSTER_TOKEN: $CLUSTER_TOKEN

Aggiorna la   sezione Kubernetes nel  tap-values-view.yaml file utilizzata da Tanzu Application Platform durante l’installazione. Questa sezione deve avere una voce per ogni cluster che dispone di risorse da visualizzare, come mostrato di seguito:

				
					ceip_policy_disclosed: true # Installation fails if this is not set to true. Not a string.

. . . 
    kubernetes:
      serviceLocatorMethod:
        type: 'multiTenant'
      clusterLocatorMethods:
        - type: 'config'
          clusters:
            - url: https://172.16.XX.XX:6443  # BUILD Cluster URL    
              name: Build-cluster 
              authProvider: serviceAccount
              serviceAccountToken: eyJhbGciOiJSUzI1NiIsIm [………] tpZCI6  # BUILD CLUSTER TOKEN
              skipTLSVerify: true
              skipMetricsLookup: true
            - url: https://172.16.XX.XX:6443   # RUN Cluster URL    
              name: run-cluster 
              authProvider: serviceAccount
              serviceAccountToken: eyJhbGciOiJSUzI1NiIsI [………] mtpZCI6I  # RUN CLUSTER TOKEN
              skipTLSVerify: true
              skipMetricsLookup: true
            - url: https://172.16.XX.XXX:6443   # Iterate Cluster URL    
              name: iterate-cluster
              authProvider: serviceAccount
              serviceAccountToken: eyJhbGciOiJSUzI1NiIp [………] ZCI6I  # ITERATE CLUSTER TOKEN
              skipTLSVerify: true
              skipMetricsLookup: true
. . .

Per aggiornare il pacchetto TAP utilizzando il file di valori tap-values-view.yaml, esegui il seguente comando:

				
					## Update the TAP package using below command: 

$ tanzu package installed update tap --values-file tap-values-view.yaml -n tap-install

Questo comando effettuerà l’aggiornamento del pacchetto TAP utilizzando le configurazioni specificate nel file tap-values-view.yaml. Assicurati di essere nel contesto appropriato, devi trovarti nel contesto di “VIEW”

L’implementazione e la gestione sicura delle applicazioni sono fondamentali nel panorama attuale.

Nel contesto del Tanzu Application Platform, è possibile raggiungere questi obiettivi attraverso l’uso di politiche di scansione e pipeline Tekton.

In questo articolo, esploreremo come definire e applicare una ScanPolicy, configurare le pipeline Tekton e automatizzare il processo di distribuzione di applicazioni in ambienti diversi.

Definire una ScanPolicy per la Sicurezza delle Scansioni

La ScanPolicy è un componente cruciale per garantire la sicurezza delle scansioni. Questa definisce regole per valutare l’aderenza degli artefatti (come immagini o codice sorgente) alle norme di sicurezza.

Di seguito un esempio di una ScanPolicy che include regole personalizzate:

				
					apiVersion: scanning.apps.tanzu.vmware.com/v1beta1
kind: ScanPolicy
metadata:
  name: scan-policy
  labels:
    'app.kubernetes.io/part-of': 'enable-in-gui'
spec:
  regoFile: |
    package main

    notAllowedSeverities := ["UnknownSeverity"]
    ignoreCves := ["CVE-2016-1000027","CVE-2021-26291","GHSA-3mc7-4q67-w48m"]

    contains(array, elem) = true {
      array[_] = elem
    } else = false { true }

    isSafe(match) {
      severities := { e | e := match.ratings.rating.severity } | { e | e := match.ratings.rating[_].severity }
      some i
      fails := contains(notAllowedSeverities, severities[i])
      not fails
    }

    isSafe(match) {
      ignore := contains(ignoreCves, match.id)
      ignore
    }

    deny[msg] {
      comps := { e | e := input.bom.components.component } | { e | e := input.bom.components.component[_] }
      some i
      comp := comps[i]
      vulns := { e | e := comp.vulnerabilities.vulnerability } | { e | e := comp.vulnerabilities.vulnerability[_] }
      some j
      vuln := vulns[j]
      ratings := { e | e := vuln.ratings.rating.severity } | { e | e := vuln.ratings.rating[_].severity }
      not isSafe(vuln)
      msg = sprintf("CVE %s %s %s", [comp.name, vuln.id, ratings])
    }

Pipeline Tekton per l'Automazione della Distribuzione

Le pipeline Tekton consentono di automatizzare la distribuzione del codice sorgente attraverso una serie di attività. Di seguito è riportato un esempio di una pipeline Tekton per distribuire un’applicazione Java:

				
					apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
  name: developer-defined-tekton-pipeline
  labels:
    apps.tanzu.vmware.com/pipeline: test
spec:
  params:
    - name: source-url
    - name: source-revision
  tasks:
    - name: test
      params:
        - name: source-url
          value: $(params.source-url)
        - name: source-revision
          value: $(params.source-revision)
      taskSpec:
        params:
          - name: source-url
          - name: source-revision
        steps:
          - name: test
            image: gradle
            script: |-
              cd `mktemp -d`
              wget -qO- $(params.source-url) | tar xvz -m
              ./mvnw test

Cambiare il Contesto al Cluster "Build" per Applicare le Politiche di Scansione e il Tekton Pipeline

Per procedere con l’applicazione delle politiche di scansione e del Tekton Pipeline nel cluster “Build”, esegui il seguente comando per cambiare il contesto al cluster “Build”:

				
					$ kubectl config use-context tap-build-cluster
Switched to context "tap-build-cluster".

Questo assicurerà che le operazioni successive siano eseguite all’interno del contesto del cluster “Build”.

Applicare la Politica di Scansione

Esegui il seguente comando per applicare la politica di scansione utilizzando il file che avete creato in precedenza:

				
					kubectl apply -f scanpolicy.yaml -n tap-install
scanpolicy.scanning.apps.tanzu.vmware.com/scan-policy created

Questo comando creerà la politica di scansione nel namespace “tap-install”. La politica di scansione specificata nel file verrà applicata alle risorse all’interno del cluster “Build”.

Applicare il Tekton Pipeline nel Cluster di Build

Esegui il seguente comando per applicare il Tekton Pipeline nel cluster “Build” utilizzando il file della pipeline creato in precedenza:

				
					kubectl apply -f tekton-pipeline.yaml -n tap-install
pipeline.tekton.dev/developer-defined-tekton-pipeline created

Questo comando creerà il Tekton Pipeline nel namespace “tap-install”.

Il Tekton Pipeline definito nel file verrà ora eseguito nel cluster “Build”.

Con questi passaggi, hai applicato con successo la politica di scansione e il Tekton Pipeline nel cluster “Build”.

Configurare i namespace degli Sviluppatori

Configurare i namespace degli sviluppatori è fondamentale per l’utilizzo dei pacchetti installati.

La modifica riportata sotto va ripetuta su 3 tipologie di cluster:

  • Build
  • Run
  • Iterate

Di seguito è illustrato cosa applicare sui 3 cluster:

				
					# Creazione di Secret e ServiceAccount
cat <<EOF | kubectl -n dev apply -f -
apiVersion: v1
kind: Secret
metadata:
  name: tap-registry
  annotations:
    secretgen.carvel.dev/image-pull-secret: ""
type: kubernetes.io/dockerconfigjson
data:
  .dockerconfigjson: e30K
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: default
secrets:
  - name: registry-credentials
imagePullSecrets:
  - name: registry-credentials
  - name: tap-registry
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: default-permit-deliverable
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: deliverable
subjects:
  - kind: ServiceAccount
    name: default
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: default-permit-workload
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: workload
subjects:
  - kind: ServiceAccount
    name: default
EOF

Cambiare il Contesto al Cluster "View"

Per procedere con le seguenti operazioni nel cluster “View”, esegui il seguente comando per cambiare il contesto al cluster “View”:

				
					$ kubectl config use-context tap-view-cluster
Passato al contesto "tap-view-cluster".

Questo assicurerà che le operazioni successive siano eseguite all’interno del contesto del cluster “View”.

Recuperare e Memorizzare l'Access Token dal Service Account

Esegui il seguente comando per recuperare l’access token dal service account “metadata-store-read-write-client” e memorizzarlo in una variabile chiamata METADATA_STORE_ACCESS_TOKEN:

				
					# Recupera l'access token
export METADATA_STORE_ACCESS_TOKEN=$(kubectl get secrets metadata-store-read-write-client -n metadata-store -o jsonpath="{.data.token}" | base64 -d)

Questo comando otterrà l’access token dal secret associato all’account di servizio e lo memorizzerà in una variabile.

Raccogliere l'IP di ENVOY

Esegui il seguente comando per ottenere l’indirizzo IP dell’Envoy:

				
					# Recupera l'indirizzo IP di Envoy
kubectl get svc -n tanzu-system-ingress

Prendi nota dell’indirizzo IP esterno dell’Envoy e associalo all’hostname “metadata-store.tap.desotech.local “. Questo indirizzo IP sarà utilizzato per l’accesso.

Ottenere il Certificato

Esegui il seguente comando per ottenere il certificato:

				
					# Imposta il target per Tanzu Insight
tanzu insight config set-target https://metadata-store.tap.desotech.local --ca-cert insight-ca.crt

Questo comando otterrà il certificato dal secret “ingress-cert” e lo memorizzerà in un file chiamato “insight-ca.crt”.

Questo certificato sarà utilizzato per stabilire una comunicazione sicura.

creare un set di record nel DNS che punta all’ip (IP ENVOY raccolto nel passaggio precedente) per il nome host metadata-store.tap.desotech.local

Impostare la Destinazione

Per impostare la destinazione per il servizio Insight, esegui il seguente comando:

				
					$ tanzu insight config set-target https://metadata-store.captainvirtualization.co.in --ca-cert insight-ca.crt
ℹ  Config File "/home/azureuser/.config/tanzu/insight/config.yaml" Already Exists
ℹ  Using config file: /home/azureuser/.config/tanzu/insight/config.yaml
ℹ  Setting trustedcacert in config
ℹ  Setting endpoint in config to: https://metadata-store.captainvirtualization.co.in
✔  Success: Set Metadata Store endpoint

Questo comando imposterà la destinazione per il servizio Insight utilizzando l’URL “https://metadata-store.tap.desotech.local” e il certificato CA “insight-ca.crt” precedentemente ottenuti. Questo consentirà a Insight di comunicare in modo sicuro con il metadata store.

Con questo passo, hai completato l’impostazione della destinazione per il servizio Insight.

In questo articolo, abbiamo esplorato il processo dettagliato per configurare un ambiente aggiornato e sicuro utilizzando Tanzu Application Platform (TAP). Abbiamo coperto ogni aspetto, dalle configurazioni iniziali al deploy delle politiche di sicurezza e alle implementazioni dei pipeline.

Successivamente, abbiamo affrontato la configurazione dei namespace degli sviluppatori, consentendo loro di collaborare in modo sicuro all’interno dell’ambiente. Abbiamo esaminato come creare account di servizio, assegnare autorizzazioni granulari e condividere risorse chiave come certificati CA e token di autenticazione.

Passando al cluster “build”, abbiamo dettagliato il processo per applicare politiche di scansione e implementare un pipeline Tekton. Queste azioni sono fondamentali per garantire la sicurezza del ciclo di vita delle applicazioni e per automatizzare il processo di sviluppo e deployment.

Nel cluster “view”, ci siamo concentrati sull’integrazione con il servizio Insight, fornendo una guida passo-passo per configurare l’accesso e visualizzare i dati dell’ambiente. Abbiamo dimostrato come impostare la destinazione per Insight, consentendo un’analisi dettagliata e una migliore comprensione delle risorse e delle prestazioni.

Condividi l’articolo!!


Scopri i nostri corsi!

Formazione Cloud-Native in presenza o da remoto
Scegli il tuo percorso formativo!
Picture of Evangelista Tragni

Evangelista Tragni

VMware Instructor – AWS Instructor – Linux Foundation Instructor
Mi prefiggo di ottenere una buona reputazione professionale come formatore IT conosciuto in tutto il mondo per AWS, VMware, Kubernetes e forse anche per altri settori come Google e cosi via. Mi piace essere parte del percorso di apprendimento di ognuno dei miei studenti, pertanto cerco di lasciare un segno in ognuno di loro integrando l’esperienza del corso con le loro attivita quotidiane. Spero di vedervi presto tra i miei allievi!

Find me on Linkedin!