ათობით სერვისის გამოყენებისას, თქვენ არ შეგიძლიათ აწყობის კონფიგურაცია და საიდუმლოებები ად-ჰოკ პრინციპით აწყობის თითოეული რეალიზაციისთვის. ცენტრალიზებული კონფიგურაცია ინარჩუნებს პარამეტრებს ერთ მართვადი წყაროში, ხოლო საიდუმლოების მენეჯერი ინახავს მგრძნობიარე მნიშვნელობებს უსაფრთხოდ.
კონფიგურაცია აგებულია ბიუროს გარეთ, ამიტომ იგივე იმიჯი ხორციელდება dev/staging/prod-ში სხვადსხვა პარამეტრებით.
| მიდგომა | მაგალითი |
|---|---|
| Config server | Spring Cloud Config, Consul |
| ორქესტრატორ-მშობლიური | Kubernetes ConfigMaps |
| საიდუმლოების მენეჯერი | HashiCorp Vault, AWS Secrets Manager |
ნასულელი არასოდეს ინახოთ ხელმოუტმენელი ConfigMaps-ში ან git-ში.
# fetch a secret at startup, short-lived, audited
export DB_PASSWORD=$(vault kv get -field=password secret/orders/db)
✓ Externalize config (12-factor): config in the environment
✓ Secrets in a dedicated manager with rotation + audit logs
✓ Dynamic refresh for non-secret toggles (no redeploy)
✗ Never commit secrets to source control
ცენტრალიზებული კონფიგურაცია საშუალებას გაძლევთ შეცვალოთ ქცევა (timeout-ები, ფიჩერ ფლაგები) და გადაბრუნდეთ სხვადსხვა სერვისებში დამოწმებების გარეშე თითოეულის ხელახლა აგება და განვითარება.
საიდუმლოების ინახვა ნამდვილი საიდუმლოების მენეჯერში — არა სურათებში ან git-ში — არის საბაზო უსაფრთხოების მოთხოვნა, რომელიც უფრო რთულდება სერვისების რაოდენობით.