

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

# Kubernetes sichern mit AWS Private Certificate Authority
<a name="PcaKubernetes"></a>

Sie können AWS Private Certificate Authority damit Zertifikate für die sichere Authentifizierung und Verschlüsselung über TLS und mTLS bereitstellen. AWS Private CA stellt ein Open-Source-Plugin, [AWS Private CA Connector for Kubernetes, (`aws-privateca-issuer`) für](https://github.com/cert-manager/aws-privateca-issuer) das weit verbreitete [Cert-Manager-Add-on](https://cert-manager.io/docs/) für Kubernetes bereit, das Zertifikate anfordert, sie an Kubernetes-Secrets verteilt und die Zertifikatserneuerung automatisiert.

Das Plugin ermöglicht `aws-privateca-issuer` es Ihnen, Zertifikate auszustellen über. AWS Private CA `cert-manager` Sie können das Plugin mit Amazon Elastic Kubernetes Service (Amazon EKS), einem selbstverwalteten Kubernetes-Cluster auf AWS oder in einem lokalen Kubernetes-Cluster verwenden. Das Plugin funktioniert sowohl auf x86- als auch auf ARM-Architekturen.

AWS Private CA hat HSM-gestützte Schlüssel, die nicht exportiert werden können. Wenn Sie gesetzliche Anforderungen für die Zugriffskontrolle und die Prüfung Ihrer CA-Operationen haben, können Sie diese AWS Private CA zur Verbesserung der Überprüfbarkeit und zur Einhaltung der Vorschriften nutzen.

**Anmerkung**  
Wenn Sie Amazon EKS verwenden, empfehlen wir Ihnen, die `aws-privateca-connector-for-kubernetes` Add-Ons `cert-manager` und Addons für eine verwaltete Installation zu verwenden. Weitere Informationen finden Sie unter [AWS Add-Ons](https://docs.aws.amazon.com/eks/latest/userguide/workloads-add-ons-available-eks.html#add-ons-aws-privateca-connector).

# Konzepte
<a name="PcaKubernetes-concepts"></a>

Das folgende Diagramm zeigt einige der Optionen, die für die Verwendung von TLS in einem Amazon EKS-Cluster verfügbar sind. Der Beispielcluster befindet sich hinter einem Load Balancer. Die Zahlen identifizieren mögliche Endpunkte für TLS-gesicherte Kommunikation.

![\[Ein Diagramm, das die möglichen Endpunkte für die TLS-Verschlüsselung zeigt. Jeder Endpunkt hat eine Nummer, die der folgenden Liste entspricht.\]](http://docs.aws.amazon.com/de_de/privateca/latest/userguide/images/kubernetes-pca.png)


1. **Kündigung am Load Balancer**

   Elastic Load Balancing (Elastic Load Balancing) ist in den AWS Certificate Manager Service integriert. Sie müssen es nicht `cert-manager` auf dem Load Balancer installieren. Sie können ACM mit einer privaten CA bereitstellen, ein Zertifikat mit der privaten CA signieren und das Zertifikat mit der Elastic Load Balancing Console installieren. AWS Private CA Zertifikate werden automatisch erneuert.

   Als Alternative können Sie einem AWS Nicht-Load-Balancer ein privates Zertifikat zur Verfügung stellen, um TLS zu beenden.

   Dies ermöglicht eine verschlüsselte Kommunikation zwischen einem Remote-Client und dem Load Balancer. Daten nach dem Load Balancer werden unverschlüsselt an den Amazon EKS-Cluster übergeben.

1. **Kündigung am Kubernetes-Ingress-Controller**

   Der Ingress-Controller befindet sich im Amazon EKS-Cluster und fungiert als Load Balancer und Router. Um den Ingress-Controller als Endpunkt des Clusters für die externe Kommunikation zu verwenden, müssen Sie:
   + Installieren Sie beide `cert-manager` und `aws-privateca-issuer` 
   + Stellen Sie dem Controller ein privates TLS-Zertifikat von der bereit AWS Private CA.

   Die Kommunikation zwischen dem Load Balancer und dem Ingress Controller ist verschlüsselt, Daten werden unverschlüsselt an die Ressourcen des Clusters übertragen.

1. **Kündigung an einem Pod**

   Jeder Pod ist eine Gruppe von einem oder mehreren Containern, die sich Speicher- und Netzwerkressourcen teilen. Wenn Sie sowohl als auch installieren `cert-manager` `aws-privateca-issuer` und den Cluster mit einer privaten CA ausstatten, kann Kubernetes bei Bedarf ein signiertes privates TLS-Zertifikat auf Pods installieren. Eine TLS-Verbindung, die an einem Pod endet, ist für andere Pods im Cluster standardmäßig nicht verfügbar. 

1. **Sichere Kommunikation zwischen Pods.**

   Sie können mehrere Pods mit Zertifikaten ausstatten, damit sie miteinander kommunizieren können. Die folgenden Szenarien sind möglich:
   + Bereitstellung mit von Kubernetes generierten selbstsignierten Zertifikaten. Dadurch wird die Kommunikation zwischen Pods gesichert, selbstsignierte Zertifikate erfüllen jedoch nicht die HIPAA- oder FIPS-Anforderungen.
   + Bereitstellung mit Zertifikaten, signiert von. AWS Private CA Dazu müssen sowohl als auch `cert-manager` installiert werden. `aws-privateca-issuer` Kubernetes kann dann nach Bedarf signierte mTLS-Zertifikate auf den Pods installieren.

# Überlegungen
<a name="PcaKubernetes-considerations"></a>

Beachten Sie bei der Verwendung AWS Private Certificate Authority mit Kubernetes die folgenden Überlegungen.

## Kontoübergreifende Verwendung von Cert-Manager
<a name="kubernetes-cross-account"></a>

Administratoren mit kontenübergreifendem Zugriff auf eine Zertifizierungsstelle können das `cert-manager` Add-On für Kubernetes verwenden, um Zertifikate für einen Cluster bereitzustellen, der die gemeinsame CA verwendet. Weitere Informationen finden Sie unter [Bewährte Sicherheitsmethoden für den kontoübergreifenden Zugriff auf private CAs](pca-resource-sharing.md).

In kontoübergreifenden Szenarien können Sie nur bestimmte AWS Private CA Zertifikatsvorlagen verwenden.

In der folgenden Tabelle sind AWS Private CA Vorlagen aufgeführt, die Sie mit cert-manager verwenden können, um einen Kubernetes-Cluster bereitzustellen.


| Für Kubernetes unterstützte Vorlagen | Support für kontoübergreifende Nutzung | 
| --- | --- | 
| [BlankEndEntityCertificate\$1 /V1-Definition CSRPassthrough](template-definitions.md#BlankEndEntityCertificate_CSRPassthrough) | Nein | 
| [CodeSigningCertificate/V1-Definition](template-definitions.md#CodeSigningCertificate-V1) | Nein | 
| [EndEntityCertificate/V1-Definition](template-definitions.md#EndEntityCertificate-V1) | Ja | 
| [EndEntityClientAuthCertificate/V1-Definition](template-definitions.md#EndEntityClientAuthCertificate-V1) | Ja | 
| [EndEntityServerAuthCertificate/V1-Definition](template-definitions.md#EndEntityServerAuthCertificate-V1) | Ja | 
| [OCSPSigningZertifikat/V1-Definition](template-definitions.md#OCSPSigningCertificate-V1) | Nein | 

# Beginnen Sie mit AWS Private CA Connector for Kubernetes.
<a name="PcaKubernetes-get-started"></a>

Die folgenden Themen zeigen, wie Sie die Kommunikation in einem AWS Private CA Kubernetes-Cluster sichern können. Ein weiteres Beispiel finden Sie unter [Encryption in transit for Kubernetes](https://github.com/aws-samples/sample-encryption-in-transit-for-kubernetes) on. GitHub

Sie können eine private Zertifizierungsstelle verwenden, um die Kommunikation mit Ihren Amazon EKS-Clustern zu sichern. Beginnen Sie erst, wenn Folgendes vorliegt:
+ Ein AWS Konto mit entsprechenden Berechtigungen im Rahmen Ihrer Sicherheitsrichtlinien.

------
#### [ Amazon EKS clusters ]

------
#### [ JSON ]

****  

  ```
  {
    "Version":"2012-10-17",		 	 	 
    "Statement": [
      {
        "Sid": "IAM",
        "Effect": "Allow",
        "Action": [
          "iam:CreateRole",
          "iam:AttachRolePolicy",
          "iam:GetRole"
        ],
        "Resource": "*"
      },
      {
        "Sid": "EKS",
        "Effect": "Allow",
        "Action": [
          "eks:CreateAddon",
          "eks:DescribeAddon",
          "eks:CreatePodIdentityAssociation",
          "eks:DescribeCluster"
        ],
        "Resource": "*"
      },
      {
        "Sid": "IAMPassRole",
        "Effect": "Allow",
        "Action": [
          "iam:PassRole"
        ],
        "Resource": "arn:aws:iam::*:role/CertManagerPrivateCARole"
      }
    ]
  }
  ```

------

------
#### [ Other clusters ]

------
#### [ JSON ]

****  

  ```
  {
    "Version":"2012-10-17",		 	 	 
    "Statement": [
      {
        "Sid": "GetAndIssuePCACertificates",
        "Effect": "Allow",
        "Action": [
          "acm-pca:GetCertificate",
          "acm-pca:IssueCertificate"
        ],
        "Resource": "*"
      },
      {
        "Sid": "RolesAnywhere",
        "Effect": "Allow",
        "Action": [
          "rolesanywhere:CreateProfile"
        ],
        "Resource": "*"
      },
      {
        "Sid": "IAM",
        "Effect": "Allow",
        "Action": [
          "iam:CreateRole",
          "iam:AttachRolePolicy"
        ],
        "Resource": "*"
      },
      {
        "Sid": "IAMPassRole",
        "Effect": "Allow",
        "Action": [
          "iam:PassRole"
        ],
        "Resource": "arn:aws:iam::*:role/CertManagerPrivateCARole"
      }
    ]
  }
  ```

------

------
+ Ein Kubernetes-Cluster. Informationen zum Erstellen eines Amazon Elastic Kubernetes Service Service-Clusters finden Sie in der [Amazon EKS-Schnellstartanleitung](https://docs.aws.amazon.com/eks/latest/userguide/quickstart.html). Der Einfachheit halber erstellen Sie eine Umgebungsvariable, die den Clusternamen enthält:

  ```
  export CLUSTER=aws-privateca-demo
  ```

  
+ Der AWS-Region Ort, an dem sich Ihr CA- und Amazon EKS-Cluster befinden. Erstellen Sie der Einfachheit halber eine Umgebungsvariable für die Region:

  ```
  export REGION=aws-region
  ```
+ Der Amazon-Ressourcenname (ARN) einer AWS Private CA privaten Zertifizierungsstelle. Erstellen Sie der Einfachheit halber eine Umgebungsvariable, die den privaten CA-ARN ARN:

  ```
  export CA_ARN="arn:aws:acm-pca:region:account:certificate-authority/CA_ID/certificate/certificate_ID"
  ```

  Informationen zum Erstellen einer privaten Zertifizierungsstelle finden Sie unter [https://docs.aws.amazon.com/privateca/latest/userguide/create-CA.html](https://docs.aws.amazon.com/privateca/latest/userguide/create-CA.html) Erstellen einer privaten Zertifizierungsstelle in AWS Private CA
+ Ein Computer, auf dem die folgende Software installiert ist:
  + [AWS CLI v2](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) konfiguriert
  + [kubectl v1.13\$1](https://kubernetes.io/docs/tasks/tools/install-kubectl/)
  + [Helm](https://helm.sh/docs/intro/install/) v3 für Nicht-Amazon-EKS-Cluster

## Installieren Sie Cert-Manager
<a name="kubernetes-install-cert-manager"></a>

Um eine private Zertifizierungsstelle zu verwenden, müssen Sie das `cert-manager>` Add-on installieren, das Zertifikate anfordert, verteilt und die Zertifikatserneuerung automatisiert. Sie müssen auch das `aws-private-ca-issuer` Plugin installieren, mit dem Sie private Zertifikate ausstellen können. AWS Private CA Gehen Sie wie folgt vor, um das Add-on und das Plugin zu installieren.

------
#### [ Amazon EKS clusters ]

`cert-manager`Als Amazon EKS-Add-on installieren:

```
aws eks create-addon \
  --cluster-name $CLUSTER \
  --addon-name cert-manager \
  --region $REGION
```

------
#### [ Other clusters ]

Installation `cert-manager` mit Helm:

```
helm repo add jetstack https://charts.jetstack.io
helm repo update

helm install cert-manager jetstack/cert-manager \
  --namespace cert-manager \
  --create-namespace \
  --set crds.enabled=true
```

------

## Konfigurieren Sie die IAM-Berechtigungen.
<a name="kubernetes-iam-permissions"></a>

Das `aws-privateca-issuer` Plugin benötigt die Erlaubnis, mit dem Sie interagieren können AWS Private CA. Für Amazon EKS-Cluster verwenden Sie die Pod-Identität. Für andere Cluster verwenden Sie AWS Identity and Access Management Roles Anywhere.

Erstellen Sie zunächst eine IAM-Richtlinie. Die Richtlinie verwendet die `AWSPrivateCAConnectorForKubernetesPolicy` verwaltete Richtlinie. Weitere Informationen zu der Richtlinie finden Sie [AWSPrivateCAConnectorForKubernetesPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSPrivateCAConnectorForKubernetesPolicy.html)im *Referenzhandbuch für AWS verwaltete Richtlinien*.

------
#### [ Amazon EKS clusters ]

1. Erstellen Sie eine Datei `trust-policy.json` mit dem Namen, die die folgende Vertrauensrichtlinie enthält:

------
#### [ JSON ]

****  

   ```
   {
     "Version":"2012-10-17",		 	 	 
     "Statement": [
       {
         "Sid": "TrustPolicyForEKSClusters",
         "Effect": "Allow",
         "Principal": {
           "Service": "pods.eks.amazonaws.com"
         },
         "Action": [
           "sts:AssumeRole",
           "sts:TagSession"
         ]
       }
     ]
   }
   ```

------

1. Führen Sie die folgenden Befehle aus, um eine IAM-Rolle zu erstellen:

   ```
   ROLE_ARN=$(aws iam create-role \
     --role-name CertManagerPrivateCARole \
     --assume-role-policy-document file://trust-policy.json \
     --region $REGION \
     --output text \
     --query "Role.Arn")
    
    aws iam attach-role-policy \
     --role-name CertManagerPrivateCARole \
     --policy-arn arn:aws:iam::aws:policy/AWSPrivateCAConnectorForKubernetesPolicy
   ```

------
#### [ Other clusters ]

1. Erstellen Sie einen Vertrauensanker, der der privaten CA vertraut, die in gespeichert ist. `CA_ARN` Anweisungen finden Sie unter [Erste Schritte mit IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/getting-started.html). Erstellen Sie eine Umgebungsvariable, um den Vertrauensanker-ARN zu speichern:

   ```
   export TRUST_ANCHOR_ARN=trustAnchorArn
   ```

1. Erstellen Sie eine Datei mit dem Namen`trust-policy.json`, die die folgende Vertrauensrichtlinie enthält:

------
#### [ JSON ]

****  

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
           {
               "Sid": "TrustPolicyForSelfManagedOrOnPremiseClusters",
               "Effect": "Allow",
               "Principal": {
                   "Service": "rolesanywhere.amazonaws.com"
               },
               "Action": [
                   "sts:AssumeRole",
                   "sts:SetSourceIdentity",
                   "sts:TagSession"
               ],
               "Condition": {
                   "ArnEquals": {
                       "aws:SourceArn": [
                           "arn:aws:rolesanywhere:us-east-1:123456789012:trust-anchor/TRUST_ANCHOR_ARN"
                       ]
                   },
                   "StringEquals": {
                       "aws:PrincipalTag/x509Subject/CN": "aws-privateca-issuer"
                   }
               }
           }
       ]
   }
   ```

------

1. Führen Sie die folgenden Befehle aus, um eine IAM-Rolle zu erstellen:

   ```
   ROLE_ARN=$(aws iam create-role \
     --role-name CertManagerPrivateCARole \
     --assume-role-policy-document file://trust-policy.json \
     --query "Role.Arn" \
     --region $REGION \
     --output text)
     
    aws iam attach-role-policy \
     --role-name CertManagerPrivateCARole \
     --region $REGION \
     --policy-arn arn:aws:iam::aws:policy/AWSPrivateCAConnectorForKubernetesPolicy
   ```

------

## Installieren und konfigurieren Sie den AWS Private CA Cluster-Issuer
<a name="kubernetes-install-aws-private-ca-cluster-issuer"></a>

Verwenden Sie die folgenden Befehle, um das `aws-privateca-connector-for-kubernetes` Add-on zu installieren: 

------
#### [ Amazon EKS clusters ]

Erstellen Sie das Add-on:

```
aws eks create-addon --region $REGION \
  --cluster-name $CLUSTER \
  --addon-name aws-privateca-connector-for-kubernetes \
  --pod-identity-associations "[{
    \"serviceAccount\": \"aws-privateca-issuer\",
    \"roleArn\": \"$ROLE_ARN\"
  }]"
```

Warten Sie dann, bis das Add-on aktiv ist:

```
aws eks describe-addon \
  --cluster-name $CLUSTER \
  --addon-name aws-privateca-connector-for-kubernetes \
  --region $REGION \
  --query 'addon.status'
```

------
#### [ Other clusters ]

1. Erstellen Sie ein Profil in IAM Roles Anywhere:

   ```
   PROFILE_ARN=$(aws rolesanywhere create-profile \
     --name "privateca-profile" \
     --role-arns "$ROLE_ARN" \
     --region "$REGION" \
     --query 'profile.profileArn' \
     --enabled \
     --output text)
   ```

1. Generieren Sie ein Client-Zertifikat zur Verwendung mit dem Connector für Kubernetes und IAM Roles Anywhere zur Authentifizierung mit: AWS Private CA

   1. Generieren Sie einen privaten Schlüssel für das Client-Zertifikat:

      ```
      openssl genrsa -out client.key 2048
      ```

   1. Generieren Sie eine Zertifikatsignieranforderung (CSR) für das Client-Zertifikat:

      ```
      openssl req -new \
        -key client.key \
        -out client.csr \
        -subj "/CN=aws-privateca-issuer"
      ```

   1. Stellen Sie das Client-Zertifikat aus von AWS Private CA:

      ```
      CERT_ARN=$(aws acm-pca issue-certificate \
        --signing-algorithm SHA256WITHRSA \
        --csr fileb://client.csr \
        --validity Value=1,Type=DAYS \
        --certificate-authority-arn "$CA_ARN" \
        --region "$REGION" \
        --query 'CertificateArn' \
        --output text)
      ```

   1. Speichern Sie das Client-Zertifikat lokal:

      ```
      aws acm-pca get-certificate \
        --certificate-authority-arn $CA_ARN \
        --certificate-arn $CERT_ARN \
        --region $REGION \
        --query 'Certificate' 
        --output text > pca-issuer-client-cert.pem
      ```

1. Installieren Sie den AWS Private CA Aussteller im Cluster mit dem Client-Zertifikat:

   1. Fügen Sie das `awspca`-Helm-Repository hinzu:

      ```
      helm repo add awspca https://cert-manager.github.io/aws-privateca-issuer 
      helm repo update
      ```

   1. Erstellen Sie einen Namespace:

      ```
      kubectl create namespace aws-privateca-issuer
      ```

   1. Verwahren Sie das zuvor erstellte Zertifikat in ein Geheimnis:

      ```
      kubectl create secret tls aws-privateca-credentials \
        -n aws-privateca-issuer \
        --cert=pca-issuer-client-cert.pem \
        --key=client.key
      ```

1. Installieren Sie den AWS Private CA Aussteller mit IAM Roles Anywhere:

   1. Erstellen Sie eine Datei mit dem Namen`values.yaml`, um das AWS Private CA Issuer-Plugin für die Verwendung mit folgenden Komponenten zu konfigurieren: IAM Roles Anywhere

      ```
      cat > values.yaml <<EOF
      env:
        AWS_EC2_METADATA_SERVICE_ENDPOINT: "http://127.0.0.1:9911"
      
      extraContainers:
        - name: "rolesanywhere-credential-helper"
          image: "public.ecr.aws/rolesanywhere/credential-helper:latest"
          command: ["aws_signing_helper"]
          args:
            - "serve"
            - "--private-key"
            - "/etc/cert/tls.key"
            - "--certificate"
            - "/etc/cert/tls.crt"
            - "--role-arn"
            - "$ROLE_ARN"
            - "--profile-arn"
            - "$PROFILE_ARN"
            - "--trust-anchor-arn"
            - "$TRUST_ANCHOR_ARN"
          volumeMounts:
            - name: cert
              mountPath: /etc/cert/
              readOnly: true
      
      volumes:
        - name: cert
          secret:
            secretName: aws-privateca-credentials
      EOF
      ```

   1. Installieren Sie den AWS Private CA Emittenten mit: IAM Roles Anywhere

      ```
      helm install aws-privateca-issuer awspca/aws-privateca-issuer \
        -n aws-privateca-issuer \
        -f values.yaml
      ```

------

Warten Sie, bis der Emittent bereit ist. Verwenden Sie den folgenden Befehl: 

```
kubectl wait --for=condition=ready pods --all -n aws-privateca-issuer --timeout=120s
```

Überprüfen Sie anschließend die Installation, um sicherzustellen, dass alle Pods den folgenden `READY` Status erreicht haben:

```
kubectl -n aws-privateca-issuer get all
```

Um das zu konfigurieren`aws-private-ca-cluster-issuer`, erstellen Sie eine YAML-Datei `cluster-issuer.yaml` mit dem Namen, die die Konfiguration des Ausstellers enthält:

```
cat > cluster-issuer.yaml <<EOF
apiVersion: awspca.cert-manager.io/v1beta1
kind: AWSPCAClusterIssuer
metadata:
  name: aws-privateca-cluster-issuer
spec:
  arn: "$CA_ARN"
  region: "$REGION"
EOF
```

Wenden Sie als Nächstes die Cluster-Konfiguration an:

```
kubectl apply -f cluster-issuer.yaml
```

Überprüfen Sie den Status des Emittenten:

```
kubectl describe awspcaclusterissuer aws-privateca-cluster-issuer
```

Es wird eine Antwort ähnlich der folgenden angezeigt:

```
Status:
  Conditions:
    Last Transition Time:  2025-08-13T21:00:00Z
    Message:               AWS PCA Issuer is ready
    Reason:                Verified
    Status:                True
    Type:                  Ready
```

## Verwalten Sie das AWS Private CA Client-Zertifikat mit cert-manager
<a name="kubernetes-manage-pca-certificate"></a>

Wenn Sie keinen Amazon EKS-Cluster verwenden, können `aws-privateca-issuer` Sie nach dem manuellen Bootstrap eines vertrauenswürdigen Zertifikats zu einem Client-Authentifizierungszertifikat wechseln, das von verwaltet wird`cert-manager`. Dies ermöglicht `cert-manager` die automatische Verlängerung des Client-Authentifizierungszertifikats.

1. Erstellen Sie eine Datei mit dem Namen`pca-auth-cert.yaml`:

   ```
   cat > pca-auth-cert.yaml <<EOF
   apiVersion: cert-manager.io/v1
   kind: Certificate
   metadata:
     name: aws-privateca-client-cert
     namespace: aws-privateca-issuer
   spec:
     secretName: aws-privateca-credentials
     duration: 168h
     renewBefore: 48h
     commonName: aws-privateca-issuer
     privateKey:
       algorithm: ECDSA
       size: 256
       rotationPolicy: Always
     usages:
       - client auth
     issuerRef:
       name: aws-privateca-cluster-issuer
       kind: AWSPCAClusterIssuer
       group: awspca.cert-manager.io
   EOF
   ```

1. Erstellen Sie das neue verwaltete Client-Authentifizierungszertifikat:

   ```
   kubectl apply -f pca-auth-cert.yaml
   ```

1. Stellen Sie sicher, dass das Zertifikat erstellt wurde:

   ```
   kubectl get certificate aws-privateca-client-cert -n aws-privateca-issuer
   ```

   Es wird eine Antwort ähnlich der folgenden angezeigt:

   ```
   NAME                        READY   SECRET                      AGE
   aws-privateca-client-cert   True    aws-privateca-credentials   19m
   ```

## Stellen Sie Ihr erstes TLS-Zertifikat aus
<a name="kubernetes-issue-certificate"></a>

Nachdem die `cert-manager` und installiert `aws-privateca-issuer` sind, können Sie ein Zertifikat ausstellen.

Erstellen Sie eine YAML-Datei `certificate.yaml` mit dem Namen, die die Zertifikatsressource enthält:

```
cat > certificate.yaml <<EOF
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: example-certificate
  namespace: default
spec:
  secretName: example-certificate-tls
  issuerRef:
    name: aws-privateca-cluster-issuer
    kind: AWSPCAClusterIssuer
    group: awspca.cert-manager.io
  commonName: example.internal
  dnsNames:
    - example.internal
    - api.example.internal
  duration: 2160h # 90 days
  renewBefore: 360h # 15 days
  usages:
    - digital signature
    - key encipherment
    - server auth
EOF
```

Wenden Sie das Zertifikat mit dem folgenden Befehl an:

```
kubectl apply -f certificate.yaml
```

Anschließend können Sie den Status des Zertifikats mit den folgenden Befehlen überprüfen:

```
kubectl get certificate example-certificate
kubectl describe certificate example-certificate
```

Sie sollten eine Antwort ähnlich der folgenden sehen:

```
NAME                 READY   SECRET                    AGE
example-certificate  True    example-certificate-tls   30s
```

Sie können das ausgestellte Zertifikat mit dem folgenden Befehl überprüfen:

```
kubectl get secret example-certificate-tls -o yaml
```

Sie können das Zertifikat auch mit dem folgenden Befehl dekodieren und überprüfen:

```
kubectl get secret example-certificate-tls -o jsonpath='{.data.tls\.crt}' | base64 -d | openssl x509 -text -noout
```

# Beispiele
<a name="PcaKubernetes-examples"></a>

Die folgenden Beispiele zeigen, wie es mit AWS Private CA Kubernetes-Clustern verwendet werden kann.

**Topics**
+ [Beispiel: Verschlüsselung bei der Übertragung für Kubernetes](https://github.com/aws-samples/sample-encryption-in-transit-for-kubernetes?tab=readme-ov-file)
+ [TLS-fähige Kubernetes-Cluster mit und Amazon EKS AWS Private CA](https://go.aws/3ifFNEJ)
+ [Einrichtung der end-to-end TLS-Verschlüsselung auf Amazon EKS mit dem neuen Load AWS Balancer Controller](https://aws.amazon.com/blogs/containers/setting-up-end-to-end-tls-encryption-on-amazon-eks-with-the-new-aws-load-balancer-controller/)

# Überwachen Sie Kubernetes mit AWS Private CA
<a name="PcaKubernetes-monitor"></a>

Verwenden Sie die unter beschriebenen Techniken, um die private Zertifizierungsstelle des Kubernetes-Clusters zu überwachen. [AWS Private CA Ressourcen überwachen](logging-and-monitoring.md) Sie können Folgendes verwenden, um eine private CA zu überwachen:
+ [AWS Private CA CloudWatch MetrikenAWS Private CA CloudWatch Metriken](PcaCloudWatch.md)
+ [Überwachung AWS Private CA mit CloudWatch Ereignissen](CloudWatchEvents.md)
+ [Protokollieren von AWS Private Certificate Authority API-Aufrufen mit AWS CloudTrail](logging-using-cloudtrail-pca.md)

# Fehlerbehebung bei Kubernetes mit AWS Private CA
<a name="PcaKubernetes-troubleshoot"></a>

Sie können die Protokolle für `aws-private-ca-issuer` mit dem folgenden Verfahren abrufen:

1. Ermitteln Sie den Namen des Pods:

   ```
   kubectl get pods -A
   ```

1. Verwenden Sie den folgenden Befehl, um die Issuer-Logs einzusehen:

   ```
   kubectl logs -n aws-privateca-issuer <pod-name> aws-privateca-issuer
   ```

1. Verwenden Sie den folgenden Befehl, um die IAM Roles Anywhere Protokolle anzuzeigen:

   ```
   kubectl logs -n aws-privateca-issuer <pod-name> rolesanywhere-credentials-helper
   ```

Verwenden Sie eine der folgenden Methoden, um den Status Ihres AWS Private CA Emittenten zu überprüfen:

**Verwenden Sie den folgenden Befehl, um zu überprüfen, ob Ihr Emittent bereit ist:**

```
kubectl get AWSPCAClusterIssuers -o json | jq '.items[].status
```

Die Antwort sollte der folgenden ähneln:

```
{
  "conditions": [
    {
      "lastTransitionTime": "2024-07-03T13:56:37Z",
      "message": "Issuer verified",
      "reason": "Verified",
      "status": "True",
      "type": "Ready"
    }
  ]
}
```

Wenn sich der Emittent nicht in dem `Ready` Bundesstaat befindet, enthält das `message` Feld Informationen darüber, warum der Emittent den Bundesstaat nicht erreichen konnte. `Ready`

**Verwenden Sie den folgenden Befehl, um zu überprüfen, ob Ihr Zertifikat bereit ist:**

```
kubectl get certificates -o json | jq '.items[].status'
```

Die Antwort sollte der folgenden ähneln:

```
{
  "conditions": [
    {
      "lastTransitionTime": "2024-07-03T13:58:13Z",
      "message": "Certificate is up to date and has not expired",
      "observedGeneration": 1,
      "reason": "Ready",
      "status": "True",
      "type": "Ready"
    }
  ],
  "notAfter": "2024-10-01T13:58:12Z",
  "notBefore": "2024-07-03T12:58:12Z",
  "renewalTime": "2024-09-16T13:58:12Z",
  "revision": 1
}
```

Wenn sich das Zertifikat nicht im `Ready` Bundesstaat befindet, enthält das `message` Feld Informationen darüber, warum das Zertifikat den `Ready` Bundesstaat nicht erreichen konnte.