Գաղտնիքների կառավարում և Vault

01Ինչն է համարվում գաղտնիք, և ինչու .env ֆայլերը բավարար չեն

Գաղտնիքն այն ամենն է, ինչ հասանելիություն է տալիս՝ բազայի գաղտնաբառեր, վճարային կամ email provider-ների API key-եր, OAuth client secret-ներ, JWT ստորագրման բանալիներ, TLS private key-եր, SSH key-եր, գաղտնագրման բանալիներ և webhook-ի ստորագրման գաղտնիքներ։ Twelve-Factor մոտեցումը՝ կոնֆիգուրացիան environment փոփոխականներում դնելը, մեծ քայլ էր hard-code անելու համեմատ, և server-ի վրա .env ֆայլերը դեռ խելամիտ սկիզբ են։ Բայց համակարգի աճին զուգընթաց խնդիրներ են հայտնվում՝ նույն .env-ի պատճեններ laptop-ներում, CI-ում և server-ներում, գրանցում չկա, թե ով ինչ է կարդացել, հեշտ rotation չկա, գաղտնիքները տեսանելի են process-ների ցուցակներում, crash dump-երում կամ սխալների էջերում, և ֆայլը commit անելու մշտական ռիսկը։ Գաղտնիքների կառավարումը սա լուծում է՝ գաղտնիքներին վերաբերվելով որպես տվյալների՝ սեփականատիրոջով, մուտքի քաղաքականությամբ, audit log-ով և կյանքի ցիկլով։

• Երբեք Git-ում, Docker image-ներում, client bundle-ներում կամ log-երում
• Յուրաքանչյուր գաղտնիք ունի սեփականատեր, scope և rotation-ի պլան
• Հասանելիությունը տրվում է ըստ ինքնության և գրանցվում է

02Ինչպես է աշխատում secret manager-ը

Պատկերացրեք բանկային պահոց՝ պահակով և մատյանով։ Secret manager-ը գաղտնիքները պահում է at rest գաղտնագրված՝ սովորաբար cloud KMS-ով կամ hardware security module-ով պաշտպանված բանալու ներքո։ Հավելվածները authenticate են անում ինքնությամբ՝ cloud IAM role, Kubernetes service account, CI job-ի OIDC token կամ AppRole, ընդհանուր գաղտնաբառի փոխարեն։ Քաղաքականությունները ինքնությունները կապում են այն ուղիների հետ, որոնք նրանք կարող են կարդալ․ orders ծառայությունը կարող է կարդալ secret/prod/orders/* և ուրիշ ոչինչ։ Յուրաքանչյուր կարդալ և գրել գրանցվում է audit log-ում։ Հիմնական տարբերակները՝ HashiCorp Vault (2023-ից source-available BSL լիցենզիայով, այժմ IBM-ի մաս), OpenBao (Vault-ի open-source fork Linux Foundation-ի ներքո), cloud ծառայություններ, ինչպիսիք են AWS Secrets Manager-ը, Google Secret Manager-ը և Azure Key Vault-ը, և ծրագրավորողների վրա կենտրոնացած պլատֆորմներ, ինչպիսիք են Doppler-ը, Infisical-ը կամ 1Password Secrets Automation-ը։

03Vault-ի հիմունքներ՝ KV գաղտնիքներ և քաղաքականություններ

Vault-ը ամեն ինչ կազմակերպում է ըստ ուղիների։ Key/value (KV) secrets engine-ը պահում է ստատիկ գաղտնիքներ՝ տարբերակավորմամբ, այնպես որ կարող եք rollback անել։ HCL-ով գրված քաղաքականությունները ուղիների վրա տալիս են capabilities, ինչպիսիք են read, create, update կամ list։ Հավելվածները մուտք են գործում auth method-ով, որը համապատասխանում է նրան, թե որտեղ են աշխատում՝ kubernetes, aws, jwt/oidc CI-ի համար կամ approle, և ստանում են կարճաժամկետ Vault token՝ սահմանափակված քաղաքականությամբ։ Development ռեժիմը (vault server -dev) միայն սովորելու համար է․ այն աշխատում է հիշողության մեջ, unsealed, root token-ով։ Production-ին պետք են storage (integrated Raft storage-ը տարածված ընտրություն է), TLS, auto-unseal cloud KMS-ով կամ HSM-ով, միացված audit device-ներ, և root token-ը revoke արված կարգավորումից հետո։ Նույն հրամանները աշխատում են OpenBao-ի bao CLI-ով։

1# Store and read a versioned secret (KV v2)
2vault kv put secret/prod/orders db_password='use-a-generated-value'
3vault kv get -field=db_password secret/prod/orders
4 
5# orders-policy.hcl — read-only access to one app's secrets
6path "secret/data/prod/orders/*" {
7  capabilities = ["read"]
8}
9 
10vault policy write orders orders-policy.hcl
11vault audit enable file file_path=/var/log/vault_audit.log

04Dynamic secrets՝ credentials, որոնք ինքնուրույն ժամկետանց են դառնում

Vault-ի ամենաուժեղ գաղափարը dynamic secrets-ն է։ Բոլոր instance-ների կողմից կիսվող մեկ երկարաժամկետ բազայի գաղտնաբառի փոխարեն Vault-ը հավելվածի յուրաքանչյուր instance-ի համար ըստ պահանջի ստեղծում է եզակի բազայի օգտատեր՝ lease-ով, ասենք՝ մեկ ժամ։ Երբ lease-ի ժամկետն ավարտվում է կամ այն revoke է արվում, Vault-ը ջնջում է այդ օգտատիրոջը։ Արտահոսած credential-ը շուտով դառնում է անօգուտ, յուրաքանչյուր կապ վերագրելի է մեկ instance-ի, իսկ կոտրված ծառայության հասանելիությունը revoke անելը մեկ հրաման է։ Նույն սխեման կա cloud credentials-ի (ժամանակավոր AWS key-եր), PKI-ի (կարճաժամկետ TLS սերտիֆիկատներ) և SSH-ի (ստորագրված սերտիֆիկատներ authorized key-երի փոխարեն) համար։ Cloud provider-ները նման գաղափարներ առաջարկում են native կերպով՝ workload-ների IAM role-երը և IAM database authentication-ը ընդհանրապես խուսափում են պահված գաղտնաբառերից։ Հավելվածները պետք է մշակեն renewal-ը, ինչը ձեր փոխարեն անում են client գրադարանները և agent-ները, ինչպիսին է Vault Agent-ը։

1# One-time setup by an admin
2vault secrets enable database
3vault write database/config/app-db plugin_name=postgresql-database-plugin \
4  connection_url="postgresql://{{username}}:{{password}}@db.internal:5432/app" \
5  allowed_roles="orders-ro" username="vault_admin" password="initial-admin-pass"
6vault write -force database/rotate-root/app-db   # Vault now owns the admin password
7 
8vault write database/roles/orders-ro db_name=app-db default_ttl=1h max_ttl=24h \
9  creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}'; GRANT SELECT ON ALL TABLES IN SCHEMA public TO \"{{name}}\";"
10 
11# Each app instance asks for its own short-lived user
12vault read database/creds/orders-ro

05Գաղտնիքները հավելվածներին հասցնելը

Կա առաքման երեք տարածված սխեմա։ Direct API՝ հավելվածն օգտագործում է SDK՝ գաղտնիքները startup-ի ժամանակ կարդալու և lease-երը թարմացնելու համար՝ ճկուն է, բայց կոդը կապում է vault-ին։ Sidecar կամ agent՝ Vault Agent-ը (կամ cloud համարժեքը) authenticate է անում, ստանում գաղտնիքները և render անում դրանք ֆայլի կամ environment-ի մեջ հավելվածի համար՝ ավտոմատ թարմացնելով, հավելվածը պարզապես կարդում է ֆայլը։ Platform sync՝ Kubernetes-ում External Secrets Operator-ը կամ Secrets Store CSI driver-ը համաժամեցնում են secret manager-ից pod-երի մեջ։ CI/CD-ում ընդհանրապես խուսափեք երկարաժամկետ cloud key-եր պահելուց․ GitHub Actions-ը, GitLab-ը և այլք կարող են յուրաքանչյուր job-ի համար թողարկել OIDC token, որը cloud-ը կամ Vault-ը փոխանակում է կարճաժամկետ credentials-ի հետ։ VPS-ի վրա Docker Compose-ի համար պարզ, հիմնավոր սխեմա է root-ին պատկանող env ֆայլերը mode 600-ով repository-ից դուրս, կամ Docker secrets՝ mount արված որպես ֆայլեր։

1# GitHub Actions: no stored cloud keys — exchange the job's OIDC token
2permissions:
3  id-token: write
4  contents: read
5jobs:
6  deploy:
7    runs-on: ubuntu-latest
8    steps:
9      - uses: aws-actions/configure-aws-credentials@v4
10        with:
11          role-to-assume: arn:aws:iam::123456789012:role/deploy-prod
12          aws-region: eu-central-1
13      - run: aws secretsmanager get-secret-value --secret-id prod/orders --query SecretString --output text > /dev/null

06Rotation, least privilege և արտահոսքի արձագանք

Rotation-ը նշանակում է գաղտնիքը փոխարինել նորով՝ ըստ ժամանակացույցի և ցանկացած կասկածելի բացահայտումից հետո։ Առանց downtime-ի rotate անելու համար միաժամանակ աջակցեք երկու վավեր տարբերակ՝ ստեղծեք նոր credential-ը, deploy արեք այն, համոզվեք, որ ոչինչ չի օգտագործում հինը, հետո revoke արեք հինը։ Cloud secret manager-ները կարող են ավտոմատացնել rotation-ը բազաների համար, երրորդ կողմի API key-երի համար rotation-ը սովորաբար script արված runbook է։ Least privilege-ը նշանակում է, որ յուրաքանչյուր ծառայություն, մարդ և pipeline ստանում է միայն իրեն անհրաժեշտ գաղտնիքները, իրեն անհրաժեշտ միջավայրում, իդեալում՝ միայն կարդալու համար։ Կանխարգելում՝ աշխատեցրեք secret scanner-ներ, ինչպիսիք են gitleaks-ը կամ TruffleHog-ը, pre-commit hook-երում և CI-ում և միացրեք ձեր Git host-ի push protection-ը։ Երբ գաղտնիքն արտահոսում է, կարգը կարևոր է՝ սկզբում revoke կամ rotate արեք այն, հետո հեռացրեք պատմությունից, որովհետև Git-ի պատմությունը վերագրելը «հետ չի բերում» արդեն clone կամ scrape արված բանալին։

• Rotate՝ ստեղծել նորը → deploy → ստուգել → revoke անել հինը
• Scan՝ pre-commit + CI + push protection
• Արտահոսք՝ սկզբում revoke, հետո մաքրել պատմությունը, հետո վերանայել access log-երը

07Vault-ի ճարտարապետություն՝ seal, storage և high availability

Vault-ի անվտանգության մոդելը հենվում է barrier-ի վրա․ այն ամենը, ինչ Vault-ից գնում է storage, գաղտնագրված է keyring-ով, որը պաշտպանված է root key-ով։ Sealing-ը նշանակում է, որ Vault-ը հիշողության մեջ բանալիներ չի պահում։ Shamir unseal-ի դեպքում root key-ը բաժանվում է share-երի (օրինակ՝ հինգ, որոնցից երեքն են պետք), որոնք պահում են տարբեր մարդիկ, auto-unseal-ի դեպքում cloud KMS-ը կամ HSM-ը ավտոմատ վերծանում է այն startup-ի ժամանակ, ինչը production-ում նորմ է, որովհետև restart-ները չպետք է գիշերը մարդկանց կարիք ունենան։ Integrated storage-ը (Raft) տվյալները replicate է անում սովորաբար երեք կամ հինգ node-երի միջև․ մեկը leader է, մյուսները standby-եր են, որոնք փոխանցում են հարցումները, և գրելու համար քվորում է պահանջվում։ Backup արեք Raft snapshot-ներով և փորձարկեք վերականգնումը։ Enterprise և HCP տարբերակները ավելացնում են performance և disaster-recovery replication տարածաշրջանների միջև։ Շահագործման տեսանկյունից Vault-ը tier-zero ենթակառուցվածք է․ եթե այն չի աշխատում, հավելվածները չեն կարող մեկնարկել, ուստի պլանավորեք քեշավորում, խելամիտ lease-ի երկարություններ և մոնիթորինգ seal-ի կարգավիճակի, leader-ի փոփոխությունների և lease-երի քանակի համար։

1# Production-style server config (excerpt)
2storage "raft" {
3  path    = "/opt/vault/data"
4  node_id = "vault-1"
5}
6listener "tcp" {
7  address       = "0.0.0.0:8200"
8  tls_cert_file = "/etc/vault/tls/vault.crt"
9  tls_key_file  = "/etc/vault/tls/vault.key"
10}
11seal "awskms" {
12  region     = "eu-central-1"
13  kms_key_id = "alias/vault-unseal"
14}
15api_addr     = "https://vault-1.internal:8200"
16cluster_addr = "https://vault-1.internal:8201"

08Secret zero՝ ինչպես է վստահվում առաջին credential-ը

Գաղտնիքների յուրաքանչյուր համակարգ բախվում է «secret zero» խնդրին․ գաղտնիքներ ստանալու համար հավելվածը նախ պետք է authenticate անի, ուստի ի՞նչ գաղտնիք է նա օգտագործում դրա համար։ Ժամանակակից պատասխանն է ապավինել այն ինքնությանը, որն արդեն ապացուցում է պլատֆորմը։ AWS-ում instance-ի կամ task-ի role-ը ստորագրում է հարցում, որը Vault-ը կամ Secrets Manager-ը կարող են ստուգել։ Kubernetes-ում pod-ի projected service-account token-ը ստուգվում է cluster-ի դեմ։ CI-ում job-ի OIDC token-ը ստորագրված է CI provider-ի կողմից։ Մերկ VPS server-ների վրա այդպիսի պլատֆորմային ինքնություն չկա, ուստի տարբերակներից են AppRole-ը՝ կոնֆիգուրացիայի մեջ ներդրված role id-ով և deploy գործիքի կողմից մեկ անգամ առաքված secret id-ով՝ կարճ TTL-ով և միանգամյա օգտագործմամբ, կամ provisioning-ի ժամանակ թողարկված TLS client certificate։ Ինչ էլ ընտրեք, ինքնությունը կապեք նեղ քաղաքականությունների և կարճ token-ների հետ, և bootstrap credential-ը դարձրեք անարժեք առաջին օգտագործումից հետո։

09Encryption as a service և envelope encryption

Գաղտնիքներ պահելուց բացի, Vault-ի transit engine-ը և cloud KMS ծառայությունները գաղտնագրում են տվյալներ հավելվածների համար՝ երբեք չբացահայտելով բանալին։ Հավելվածն ուղարկում է plaintext, ստանում ciphertext և պահում այն իր սեփական բազայում, վերծանումը պահանջում է քաղաքականությամբ ստուգվող կանչ։ Բանալիները կարող են rotate արվել, և հին ciphertext-ները մնում են վերծանելի և կարող են re-wrap արվել նոր տարբերակով։ Մեծ տվյալների համար օգտագործեք envelope encryption՝ գեներացրեք պատահական data key, դրանով լոկալ գաղտնագրեք տվյալները (օրինակ՝ AES-256-GCM), հետո data key-ը գաղտնագրեք KMS key-ով և պահեք տվյալների կողքին։ Ստանում եք արագ լոկալ գաղտնագրում, կենտրոնական audit trail և մեկ master key-ն անջատելով հասանելիությունը կտրելու հնարավորություն։ Այս սխեման ընկած է անձնական տվյալների field-level գաղտնագրման, գաղտնագրված backup-ների և GitOps գործիքներում, ինչպիսին է SOPS-ը, գաղտնիքների հիմքում։

1# Transit: the app never sees the key
2vault secrets enable transit
3vault write -f transit/keys/customer-pii
4 
5vault write transit/encrypt/customer-pii plaintext=$(printf '%s' 'AM12345678' | base64)
6# -> ciphertext: vault:v1:8SDd3WHDOjf7mq69CyCqYjBXAiQQAVZRkFM13ok481zoCmHnSeDX9vyf7w==
7 
8vault write transit/decrypt/customer-pii ciphertext='vault:v1:8SDd3WHDOjf7...'
9vault write -f transit/keys/customer-pii/rotate   # new version, old data still readable

10Kubernetes secrets՝ ինչ չէ base64-ը

Kubernetes Secret-ը base64-encoded է, ոչ թե գաղտնագրված․ ցանկացած մեկը, ով կարող է namespace-ում կարդալ Secret-ները կամ կարդալ etcd-ի backup-ները, տեսնում է արժեքները։ Ամրացրեք այն շերտերով։ Միացրեք encryption at rest etcd-ի համար, իդեալում՝ KMS provider-ով։ Սահմանափակեք RBAC-ը, որպեսզի միայն Secret-ների կարիք ունեցող workload-ները և մի քանի օպերատորներ կարողանան get կամ list անել դրանք․ Secret-ների վրա «list»-ը փաստացի բացահայտում է բոլորը։ Խուսափեք Secret manifest-ները Git-ում commit անելուց․ օգտագործեք External Secrets Operator՝ կենտրոնական manager-ից համաժամեցնելու համար, կամ Sealed Secrets կամ SOPS՝ GitOps-ի համար, որտեղ արժեքները գաղտնագրված են repository-ում։ Նախընտրեք գաղտնիքները mount անել որպես ֆայլեր՝ environment փոփոխականների փոխարեն, որպեսզի արժեքները կարողանան rotate արվել առանց restart-ի և ավելի քիչ հավանական լինի, որ հայտնվեն crash dump-երում։ Վերջապես, օգտագործեք workload identity, որպեսզի pod-երը կարողանան կանչել cloud API-ներ և secret manager-ներ՝ ընդհանրապես առանց Secret-ներում ստատիկ բանալիների։