Tutorial: gruppi di sicurezza per Pods
I gruppi di sicurezza per i Pods integrano i gruppi di sicurezza Amazon EC2 con i Pods Kubernetes. È possibile utilizzare i gruppi di sicurezza Amazon EC2 per definire regole che consentono il traffico di rete in entrata e in uscita da e verso i Pods implementati nei nodi in esecuzione su molti tipi di istanza Amazon EC2 e Fargate. Per una descrizione dettagliata di questa funzionalità, consulta il post Introduzione ai gruppi di sicurezza per i podPods
Considerazioni
Prima di implementare i gruppi di sicurezza per i Pods, considerare i limiti e le condizioni seguenti:
-
I gruppi di sicurezza per i Pods non possono essere utilizzati con i nodi Windows.
-
I gruppi di sicurezza per i Pods non possono essere utilizzati con cluster configurati per la famiglia
IPv6
che contengono nodi Amazon EC2. Tuttavia, è possibile utilizzare gruppi di sicurezza per i Pods con cluster configurati per la famigliaIPv6
che contengono solo nodi Fargate. Per ulteriori informazioni, consulta Tutorial: Assegnazione di indirizzi IPv6 a Pods e services. -
I gruppi di sicurezza per Pods sono supportati dalla maggior parte delle famiglie di istanze Amazon EC2 basate su Nitro, ma non da tutte le generazioni di una famiglia. Ad esempio, sono supportate la famiglia e le generazioni dell'istanza
m5
,c5
,r5
,p3
,m6g
,c6g
er6g
. Non è supportato alcun tipo di istanza nella famigliat
. Per un elenco completo dei tipi di istanza supportati, consulta il file limits.gosu GitHub. I nodi devono essere uno dei tipi di istanza elencati che contengono IsTrunkingCompatible: true
nel file. -
Se utilizzi anche le policy di sicurezza dei Pod per limitare l'accesso alla mutazione del Pod, allora l'utente
eks:vpc-resource-controller
Kubernetes deve essere specificato inClusterRoleBinding
Kubernetes per ilrole
a cui è assegnato ilpsp
. Se si utilizza Amazon EKS psp, role, e ClusterRoleBinding, questa è laeks:podsecuritypolicy:authenticated
ClusterRoleBinding
. Ad esempio, aggiungi l'utente alla sezionesubjects:
, come mostrato nell'esempio seguente:[...] subjects: - kind: Group apiGroup: rbac.authorization.k8s.io name: system:authenticated - apiGroup: rbac.authorization.k8s.io kind: User name: eks:vpc-resource-controller - kind: ServiceAccount name: eks-vpc-resource-controller
-
Se si utilizzano allo stesso tempo una rete personalizzata e i gruppi di sicurezza per i Pods, il gruppo di sicurezza specificato dai gruppi di sicurezza per i Pods viene utilizzato in alternativa al gruppo di protezione specificato in
ENIconfig
. -
Se utilizzi la versione
1.10.2
o precedente del plug-in CNI di Amazon VPC e includi l'impostazioneterminationGracePeriodSeconds
nelle specifiche del Pod, il valore per l'impostazione non può essere zero. -
Se utilizzi la versione
1.10
o precedente del plug-in CNI di Amazon VPC o la versione1.11
con l'impostazione predefinitaPOD_SECURITY_GROUP_ENFORCING_MODE
=strict
, i servizi Kubernetes di tipoNodePort
eLoadBalancer
che utilizzano le destinazioni di istanza conexternalTrafficPolicy
impostato suLocal
non sono supportati con i Pods a cui si assegnano i gruppi di sicurezza. Per ulteriori informazioni sull'utilizzo di un load balancer con target di istanza, consultare Bilanciamento del carico di rete su Amazon EKS. Le destinazioni dell'istanza conexternalTrafficPolicy
impostato suLocal
sono supportate se si utilizza la versione1.11
o successiva del plug-in conPOD_SECURITY_GROUP_ENFORCING_MODE
=standard
. -
La fonte NAT è disabilitata per il traffico in uscita dai Pods con gruppi di sicurezza assegnati, in modo che vengano applicate le regole dei gruppi di sicurezza in uscita, se si utilizza la versione
1.10
o precedente del plug-in CNI di Amazon VPC o la versione1.11
con l'impostazione predefinitaPOD_SECURITY_GROUP_ENFORCING_MODE
=strict
. Per accedere a Internet, è necessario avviare Pods con gruppi di sicurezza assegnati su nodi implementati in una sottorete privata configurata con un gateway NAT o un'istanza. I Podscon gruppi di sicurezza assegnati implementati nelle sottoreti pubbliche non sono in grado di accedere a Internet.Se si utilizza la versione
1.11
o successiva del plug-in conPOD_SECURITY_GROUP_ENFORCING_MODE
=standard
, il traffico Pod destinato all'esterno del VPC viene convertito nell'indirizzo IP dell'interfaccia di rete primaria dell'istanza. Per questo traffico vengono utilizzate le regole nei gruppi di sicurezza per l'interfaccia di rete primaria, anziché le regole nei gruppi di sicurezza dei Pod's. -
Per utilizzare le policy di rete Calico con Pods che hanno gruppi di sicurezza associati, dovrai utilizzare la versione
1.11.0
o successiva del plug-in CNI di Amazon VPC e impostarePOD_SECURITY_GROUP_ENFORCING_MODE
=standard
. In caso contrario, i flussi di traffico da e verso i Pods con gruppi di sicurezza associati non sono soggetti all'applicazione della policy di rete Calico ma saranno limiti esclusivamente all'applicazione del gruppo di sicurezza di Amazon EC2. Per aggiornare la versione di CNI di Amazon VPC, consulta la sezione Utilizzo del componente aggiuntivo Amazon VPC CNI plugin for Kubernetes di Amazon EKS. -
I Pods in esecuzione su nodi Amazon EC2 che utilizzano gruppi di sicurezza in cluster che impiegano Nodelocal DNSCache
sono supportati solo con la versione 1.11.0
o successiva del plug-in CNI di Amazon VPC e conPOD_SECURITY_GROUP_ENFORCING_MODE
=standard
. Per aggiornare la versione del plug-in CNI di Amazon VPC, consulta la sezione Utilizzo del componente aggiuntivo Amazon VPC CNI plugin for Kubernetes di Amazon EKS. -
I gruppi di sicurezza per Pods potrebbero portare a un aumento della latenza di startup dei Pod per i Pods con un alto tasso di abbandono. Ciò è dovuto alla limitazione della velocità nel controller delle risorse.
Configurazione del Amazon VPC CNI plugin for Kubernetes per i gruppi di sicurezza per Pods
Per implementare i gruppi di sicurezza per i Pods
Se si utilizzano gruppi di sicurezza solo per i Pods di Fargate e non si dispone di nodi Amazon EC2 nel cluster, andare alla fase Implementare un'applicazione di esempio.
-
Controlla la versione del Amazon VPC CNI plugin for Kubernetes corrente con il comando seguente:
kubectl describe daemonset aws-node --namespace kube-system | grep amazon-k8s-cni: | cut -d : -f 3
Di seguito viene riportato un output di esempio:
v1.7.6
Se la versione del Amazon VPC CNI plugin for Kubernetes è precedente alla
1.7.7
, aggiorna il plug-in alla versione1.7.7
o successiva. Per ulteriori informazioni, consulta Utilizzo del componente aggiuntivo Amazon VPC CNI plugin for Kubernetes di Amazon EKS. -
Aggiungi la policy IAM gestita
AmazonEKSVPCResourceController
al ruolo del cluster associato al cluster Amazon EKS. La policy consente al ruolo di gestire le interfacce di rete, i relativi indirizzi IP privati e i relativi allegati e distacchi da e verso le istanze di rete. -
Recupera il nome del ruolo IAM del cluster e archivialo in una variabile. Sostituisci
con il nome del cluster.my-cluster
cluster_role=$(aws eks describe-cluster --name
my-cluster
--query cluster.roleArn --output text | cut -d / -f 2) -
Collegare la policy al ruolo.
aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/AmazonEKSVPCResourceController --role-name $cluster_role
-
-
Abilitare il componente aggiuntivo CNI di Amazon VPC per gestire le interfacce di rete per i Pods impostando la variabile
ENABLE_POD_ENI
sutrue
nelaws-node
DaemonSet
. Una volta che questa impostazione è settata sutrue
, per ogni nodo nel cluster il componente aggiuntivo aggiunge un'etichetta con il valorevpc.amazonaws.com/has-trunk-attached=true
. Il controller di risorse VPC crea e allega un'interfaccia di rete speciale chiamata interfaccia di rete trunk con la descrizioneaws-k8s-trunk-eni
.kubectl set env daemonset aws-node -n kube-system ENABLE_POD_ENI=true
Nota
L'interfaccia di rete trunk è inclusa nel numero massimo di interfacce di rete supportate dal tipo di istanza. Per un elenco del numero massimo di interfacce di rete supportate da ciascun tipo di istanza, consultare la sezione Indirizzi IP per interfaccia di rete per tipo di istanza nella Guida per l'utente di Amazon EC2 per istanze Linux. Se il nodo ha già allegato il numero massimo di interfacce di rete standard, il controller di risorse VPC riserverà uno spazio. Sarà necessario ridurre i Pods in esecuzione in modo sufficiente da consentire al controller di scollegare ed eliminare un'interfaccia di rete standard, creare l'interfaccia di rete trunk e allegarla all'istanza.
É possibile vedere quale dei nodi ha
aws-k8s-trunk-eni
impostato sutrue
con il seguente comando. Se viene restituito l'outputNo resources found
, attendere alcuni secondi e riprovare. La fase precedente richiede il riavvio dei Pods Amazon VPC CNI plugin for Kubernetes, operazione che richiede alcuni secondi.kubectl get nodes -o wide -l vpc.amazonaws.com/has-trunk-attached=true
Una volta creata l'interfaccia di rete del trunk, ai Pods possono essere assegnati indirizzi IP secondari dalla rete trunk o dalle interfacce di rete standard. L'interfaccia trunk viene eliminata automaticamente se il nodo viene eliminato.
Quando si implementa un gruppo di sicurezza per un Pod in una fase successiva, il controller di risorse VPC crea un'interfaccia di rete speciale denominata interfaccia di rete di filiali con una descrizione di
aws-k8s-branch-eni
e associa i gruppi di sicurezza. Le interfacce di rete di filiali vengono create in aggiunta alle interfacce di rete standard e trunk allegate al nodo. Se si utilizzano probe liveness o readiness, è inoltre necessario disabilitare il demux precoce TCP, in modo che ilkubelet
possa connettersi a Pods su interfacce di rete di filiali tramite TCP. Per disabilitare TCP early demux, eseguire il comando seguente:kubectl patch daemonset aws-node -n kube-system \ -p '{"spec": {"template": {"spec": {"initContainers": [{"env":[{"name":"DISABLE_TCP_EARLY_DEMUX","value":"true"}],"name":"aws-vpc-cni-init"}]}}}}'
Nota
Non è necessario eseguire il comando precedente se si utilizza la versione
1.11.0
o successive del componente aggiuntivo Amazon VPC CNI plugin for Kubernetes e si impostaPOD_SECURITY_GROUP_ENFORCING_MODE
=standard
, come descritto nella fase successiva. -
Se il cluster utilizza
NodeLocal DNSCache
, se desideri utilizzare la policy di rete Calico con i tuoi Pods che dispongono dei propri gruppi di sicurezza, oppure se disponi di servizi Kubernetes di tipoNodePort
eLoadBalancer
che utilizzano le destinazioni di istanza con unaexternalTrafficPolicy
impostata suLocal
per Pods a cui desideri assegnare i gruppi di sicurezza, dovrai utilizzare la versione1.11.0
o successiva del componente aggiuntivo Amazon VPC CNI plugin for Kubernetes e dovrai abilitare la seguente impostazione:kubectl set env daemonset aws-node -n kube-system POD_SECURITY_GROUP_ENFORCING_MODE=standard
Importante
-
Le regole del gruppo di sicurezza per i Pod non si applicano al traffico tra Pods o tra Pods e services, ad esempio
kubelet
onodeLocalDNS
che si trovano sullo stesso nodo. I pod che utilizzano gruppi di sicurezza differenti sullo stesso nodo non possono comunicare perché sono configurati in sottoreti diverse e l'instradamento è disabilitato tra tali sottoreti. -
Traffico in uscita dai Pods verso gli indirizzi esterni al VPC è l'indirizzo di rete convertito nell'indirizzo IP dell'interfaccia di rete primaria dell'istanza (a meno che non sia stato impostato
AWS_VPC_K8S_CNI_EXTERNALSNAT=true
). Per questo traffico vengono utilizzate le regole nei gruppi di sicurezza per l'interfaccia di rete primaria, anziché le regole nei gruppi di sicurezza dei Pod's. -
Affinché questa impostazione venga applicata ai Pods esistenti, è necessario riavviare i Pods o i nodi su cui sono in esecuzione i Pods.
-
Implementare un'applicazione di esempio
Per utilizzare i gruppi di sicurezza per i Pods, è necessario disporre di un gruppo di sicurezza esistente ed è necessario implementare un SecurityGroupPolicy di Amazon EKS nel cluster, come descritto nella procedura seguente. I passaggi seguenti mostrano l'utilizzo delle policy di gruppo di sicurezza per un Pod. Se non diversamente indicato, completare tutti i passaggi nello stesso terminale, poiché nei passaggi successivi vengono utilizzate variabili che non persistono tra i terminali.
Per implementare un Pod di esempio con un gruppo di sicurezza
-
Crea uno spazio dei nomi Kubernetes in cui implementare le risorse. Puoi sostituire
my-namespace
con il nome di uno spazio dei nomi che desideri utilizzare.kubectl create namespace
my-namespace
-
Implementa una
SecurityGroupPolicy
Amazon EKS nel cluster.-
Copia i seguenti contenuti sul dispositivo. Puoi sostituire
podSelector
conserviceAccountSelector
se preferisci selezionare i Pods in base alle etichette degli account di servizio. É necessario specificare uno selettore. UnpodSelector
vuoto (ad esempio,podSelector: {}
) seleziona tutti i Pods nello spazio dei nomi. Puoi cambiare ilmy-role
con il nome del tuo ruolo. UnserviceAccountSelector
vuoto seleziona tutti gli account di servizio nello spazio dei nomi. Puoi sostituiremy-security-group-policy
con un nome per il tuoSecurityGroupPolicy
emy-namespace
con lo spazio dei nomi in cui desideri creareSecurityGroupPolicy
.È necessario sostituire
my_pod_security_group_id
con l'ID di un gruppo di sicurezza esistente. Se non disponi ancora di un gruppo di sicurezza dovrai crearne uno. Per ulteriori informazioni, consulta Gruppi di sicurezza Amazon EC2 per le istanze Linux nella Guida per l'utente di Amazon EC2 per le istanze Linux. Puoi specificare da 1 a 5 ID gruppo di sicurezza. Se si specificano più ID, la combinazione di tutte le regole in tutti i gruppi di sicurezza sarà valida per i Pods selezionati.cat >
my-security-group-policy.yaml
<<EOF apiVersion: vpcresources.k8s.aws/v1beta1 kind: SecurityGroupPolicy metadata: name:my-security-group-policy
namespace:my-namespace
spec:podSelector
: matchLabels: role:my-role
securityGroups: groupIds: -my_pod_security_group_id
EOFImportante
Il gruppo di sicurezza o i gruppi specificati per il Pod devono soddisfare i criteri seguenti:
-
Devono essere esistenti. Se non lo sono, quando si implementa un Pod che corrisponde al selettore, il Pod rimane bloccato nel processo di creazione. Se si descrive il Pod, si otterrà un messaggio di errore simile al seguente:
An error occurred (InvalidSecurityGroupID.NotFound) when calling the CreateNetworkInterface operation: The securityGroup ID '
.sg-05b1d815d1EXAMPLE
' does not exist -
Devono consentire la comunicazione in ingresso dal gruppo di sicurezza applicato ai nodi (per
kubelet
) su tutte le porte per cui sono state configurate le sonde. -
Devono consentire la comunicazione in uscita tramite le porte 53
TCP
eUDP
a un gruppo di sicurezza assegnato ai Pods (o ai nodi su cui sono eseguiti i Pods) che eseguono CoreDNS. Il gruppo di sicurezza per i Pods CoreDNS deve consentire il traffico in ingresso tramite le porte 53TCP
eUDP
dal gruppo di sicurezza specificato. -
Devono disporre delle regole in entrata e in uscita necessarie per comunicare con altri Pods.
-
Devono disporre di regole che consentano ai Pods di comunicare con il piano di controllo di Kubernetes se utilizzi il gruppo di sicurezza con Fargate. Il modo più semplice per eseguire questa operazione consiste nello specificare il gruppo di sicurezza del cluster come uno dei gruppi di sicurezza.
Le policy dei gruppi di sicurezza si applicano solo ai nuovi Pods pianificati. Non incidono sui Pods in esecuzione.
-
-
Implementare la policy.
kubectl apply -f
my-security-group-policy.yaml
-
-
Implementa un'applicazione di esempio con un'etichetta che corrisponda al valore
permy-role
specificato nel passaggio precedente.podSelector
-
Copia i seguenti contenuti sul dispositivo. Sostituisci i
valori di esempio
con i tuoi, quindi esegui il comando modificato. Se sostituisci ilmy-role
, assicurati che sia uguale al valore che hai specificato per il selettore in un passaggio precedente.cat >
sample-application.yaml
<<EOF apiVersion: apps/v1 kind: Deployment metadata: name:my-deployment
namespace:my-namespace
labels: app:my-app
spec: replicas:4
selector: matchLabels: app:my-app
template: metadata: labels: app:my-app
role:my-role
spec: terminationGracePeriodSeconds:120
containers: - name:nginx
image:public.ecr.aws/nginx/nginx:1.23
ports: - containerPort:80
--- apiVersion: v1 kind: Service metadata: name:my-app
namespace:my-namespace
labels: app:my-app
spec: selector: app:my-app
ports: - protocol:TCP
port:80
targetPort:80
EOF -
Implementare l'applicazione con il seguente comando. Quando si implementa l'applicazione, il Amazon VPC CNI plugin for Kubernetes corrisponde all'etichetta
role
e i gruppi di sicurezza specificati nel passaggio precedente vengono applicati al Pod.kubectl apply -f
sample-application.yaml
-
-
Visualizza i Pods implementati con l'applicazione di esempio. Nella parte restante di questo argomento, questo terminale è indicato come
TerminalA
.kubectl get pods -n my-namespace -o wide
Di seguito viene riportato un output di esempio:
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES my-deployment-
5df6f7687b
-4fbjm
1/1 Running 0 7m51s192.168.53.48
ip-192-168-33-28
.region-code
.compute.internal <none> <none> my-deployment-5df6f7687b
-j9fl4
1/1 Running 0 7m51s192.168.70.145
ip-192-168-92-33
.region-code
.compute.internal <none> <none> my-deployment-5df6f7687b
-rjxcz
1/1 Running 0 7m51s192.168.73.207
ip-192-168-92-33
.region-code
.compute.internal <none> <none> my-deployment-5df6f7687b
-zmb42
1/1 Running 0 7m51s192.168.63.27
ip-192-168-33-28
.region-code
.compute.internal <none> <none>Nota
-
Se dei Pods sono bloccati nello stato
Waiting
, eseguikubectl describe pod
. Se visualizzi
-nmy-deployment-xxxxxxxxxx-xxxxx
my-namespace
Insufficient permissions: Unable to create Elastic Network Interface.
, verifica di avere aggiunto la policy IAM al ruolo cluster IAM in un passaggio precedente. -
Se dei Pods sono bloccati nello stato
Pending
, verifica che il tipo di istanza del nodo sia elencato inlimits.go
e che non sia già stato raggiunto il prodotto del numero massimo di interfacce di rete di filiali supportate dal tipo di istanza moltiplicato per il numero di nodi nel gruppo di nodi. Ad esempio, una istanza m5.large
supporta nove interfacce di rete di filiali. Se il gruppo di nodi dispone di cinque nodi, è possibile creare un massimo di 45 interfacce di rete di filiali per il gruppo di nodi. Il 46° Pod che si tenta di implementare si troverà in uno stato diPending
finché non viene eliminato un altro Pod a cui sono associati gruppi di sicurezza.
Se si esegue
kubectl describe pod
e si visualizza un messaggio simile al seguente, può essere ignorato in modo sicuro. Questo messaggio potrebbe essere visualizzato quando il Amazon VPC CNI plugin for Kubernetes tenta di impostare la rete host e fallisce durante la creazione dell'interfaccia di rete. Il plug-in registra questo evento fino a quando non viene creata l'interfaccia di rete.my-deployment-xxxxxxxxxx-xxxxx
-nmy-namespace
Failed to create Pod sandbox: rpc error: code = Unknown desc = failed to set up sandbox container "
e24268322e55c8185721f52df6493684f6c2c3bf4fd59c9c121fd4cdc894579f
" network for Pod "my-deployment-5df6f7687b
-4fbjm
": networkPlugin cni failed to set up Pod "my-deployment-5df6f7687b-4fbjm-c89wx_my-namespace
" network: add cmd: failed to assign an IP address to containerNon è possibile superare il numero massimo di Pods eseguibili sul tipo di istanza. Per un elenco del numero massimo di Pods che è possibile eseguire su ogni tipo di istanza, consulta eni-max-pods.txt
su GitHub. Quando si elimina un Pod a cui sono associati gruppi di sicurezza o si elimina il nodo su cui è in esecuzione il Pod, il controller di risorse VPC elimina l'interfaccia di rete di filiali. Se elimini un cluster con Pods che utilizzano Pods per gruppi di sicurezza, il controller non elimina le interfacce di rete delle diramazioni, per cui dovrai eliminarle personalmente. Per ulteriori informazioni sull'eliminazione delle interfacce di rete, consulta Eliminazione di un'interfaccia di rete nella Guida per l'utente per istanze Linux di Amazon EC2. -
-
In un terminale separato, inserisci nella shell uno dei Pods. Nella parte restante di questo argomento, questo terminale è indicato come
TerminalB
. Sostituisci
con l'ID di uno dei Pods restituiti nell'output della fase precedente.5df6f7687b
-4fbjm
kubectl exec -it -n my-namespace my-deployment-
-- /bin/bash5df6f7687b
-4fbjm
-
Confermare il funzionamento dell'applicazione di esempio dalla shell in
TerminalB
.curl
my-app
Di seguito viene riportato un output di esempio:
<!DOCTYPE html> <html> <head> <title>Welcome to nginx!</title> [...]
L'output è stato ricevuto in quanto tutti i Pods che eseguono l'applicazione sono associati al gruppo di sicurezza creato. Tale gruppo contiene una regola che abilita il traffico tra tutti i Pods a cui è associato il gruppo di sicurezza. Il traffico DNS è consentito in uscita da tale gruppo di sicurezza al gruppo di sicurezza del cluster associato ai nodi. I nodi eseguono i Pods CoreDNS, su cui i Pods hanno eseguito la ricerca del nome.
-
Da
TerminalA
, rimuovere le regole del gruppo di sicurezza che consentono la comunicazione DNS dal gruppo di sicurezza al gruppo di sicurezza del cluster. Se in una fase precedente non hai aggiunto le regole DNS al gruppo di sicurezza del cluster, sostituisci
con l'ID del gruppo di sicurezza in cui sono state create le regole.$my_cluster_security_group_id
aws ec2 revoke-security-group-ingress --group-id
$my_cluster_security_group_id
--security-group-rule-ids $my_tcp_rule_id aws ec2 revoke-security-group-ingress --group-id$my_cluster_security_group_id
--security-group-rule-ids $my_udp_rule_id -
Tentare di accedere nuovamente all'applicazione da
TerminalB
.curl
my-app
Di seguito viene riportato un output di esempio:
curl: (6) Could not resolve host: my-app
Il tentativo ha esito negativo perché il Pod non è più in grado di accedere ai Pods CoreDNS a cui è associato il gruppo di sicurezza del cluster. Il gruppo di sicurezza del cluster non dispone più delle relative regole che consentono la comunicazione DNS dal gruppo di sicurezza associato al Pod.
Se si tenta di accedere all'applicazione utilizzando gli indirizzi IP restituiti in una fase precedente per uno dei Pods, si riceve comunque una risposta perché tutte le porte sono consentite tra i Pods a cui è associato il gruppo di sicurezza e non è necessaria una ricerca del nome.
-
Dopo avere eseguito diverse prove, è possibile rimuovere la policy del gruppo di sicurezza, l'applicazione e il gruppo di sicurezza di esempio creati. Esegui i comandi seguenti da
TerminalA
.kubectl delete namespace
my-namespace
aws ec2 revoke-security-group-ingress --group-id$my_pod_security_group_id
--security-group-rule-ids $my_inbound_self_rule_id wait sleep 45s aws ec2 delete-security-group --group-id$my_pod_security_group_id