SSD Nodes Learn Hosting plans →
নির্দেশিকা Matt Connorদ্বারা Matt Connor · আপডেট করা হয়েছে 2026-08-22

একটি VPS-এর জন্য সেরা self-hosted secrets manager

একটি VPS-এ OpenBao, Infisical, SOPS with age, systemd credentials ও locked down env file তুলনা করুন। কোনটির কী খরচ, সীমাবদ্ধতা ও ব্যবহারযোগ্যতা জানুন।

Self-hosted secrets manager যা password manager করে না

একটি self-hosted secrets manager process-কে credential সরবরাহ করে। একটি password manager মানুষকে credential সরবরাহ করে। বাকি সব পার্থক্য এই মৌলিক ব্যবধান থেকেই আসে। password manager এমন একজন মানুষ unlock করেন, যিনি উপস্থিত এবং সতর্ক। secrets manager-কে রাত 03:00-এ আপনার application-কে database password দিতে হতে পারে, যখন কেউ জেগে নেই।

ব্যর্থতার ধরনও গুরুত্বপূর্ণভাবে আলাদা। locked password manager একটি অসুবিধা: আপনি আবার master password টাইপ করেন। sealed secrets manager একটি outage: sealed থাকা অবস্থায় restart হওয়া প্রতিটি service credential ছাড়া চালু হয় এবং বন্ধই থাকে। নিজের password manager হিসেবে Vaultwarden চালানো মানুষের সমস্যাটি ভালোভাবে সমাধান করে। এটি machine-এর সমস্যা সমাধান করে না, এবং এটি সে উদ্দেশ্যে তৈরি হয়ওনি। এটি পাশাপাশি চালালে এর vault contents-এর বদলে admin token এবং backup file harden করা বেশি গুরুত্বপূর্ণ, কারণ client ইতিমধ্যে vault contents encrypt করে; Vaultwarden harden করার একটি ধাপ দুটিই কভার করে।

একটি server-এর জন্য বাস্তবসম্মত option দুটি দলে পড়ে। OpenBao এবং Infisical হলো service: একটি API, একটি database, TLS (transport layer security), একটি login step এবং এমন একটি process, যেটি এখন আপনাকে সচল রাখতে হবে। SOPS with age, systemd credentials এবং Docker secrets হলো file: এগুলো at rest অবস্থায় encrypted থাকে, ইতিমধ্যে চলমান কোনো component এগুলো decrypt করে, এবং monitor করার জন্য অতিরিক্ত কিছু থাকে না।

সরাসরি উত্তর হলো: একটি মাত্র box-এ এক বা দুইজন ব্যবহারকারী থাকলে file-based option সাধারণত সঠিক পছন্দ। এমন একটি OpenBao, যেটি কেউ সঠিকভাবে unseal করে না এবং যার credential কেউ rotate করে না, mode 600 env file-এর চেয়েও খারাপ। কারণ এটি একটি অতিরিক্ত moving part এবং এমন একটি backup যোগ করে, যা আপনি ভুলভাবে পরিচালনা করবেন; অথচ আপনি আগে হাতে যা করতেন না, তেমন কোনো rotation সুবিধাও এটি দেয় না।

mode 600 env ফাইল কি যথেষ্ট?

অনেক ক্ষেত্রে, হ্যাঁ। এটি যে হুমকি প্রতিরোধ করে তা হলো একই মেশিনের অন্য কোনো user আপনার database password পড়ে ফেলতে পারে। Unix file permission এটি প্রতিরোধ করে, এবং network চালু হওয়ার আগেই তা করে।

sudo install -d -m 750 -o root -g myapp /etc/myapp
sudo install -m 640 -o root -g myapp /dev/null /etc/myapp/env
sudoedit /etc/myapp/env

দুই দিক থেকেই পরীক্ষা করুন:

sudo -u myapp cat /etc/myapp/env
sudo -u nobody cat /etc/myapp/env

প্রথম command-টি ফাইলটি দেখায়। দ্বিতীয়টি cat: /etc/myapp/env: Permission denied দেখায়, কারণ nobody myapp group-এ নেই এবং ফাইলটিতে কোনো world permission নেই। এটিই সম্পূর্ণ security model, এবং এটি কার্যকর।

এর পরের ধাপেই secret leak হয়। EnvironmentFile=-সহ একটি systemd unit ওই value-গুলো process environment-এ কপি করে, আর process environment পড়া যায়।

[Service]
User=myapp
EnvironmentFile=/etc/myapp/env
ExecStart=/usr/local/bin/myapp
sudo cat /proc/$(pgrep -n myapp)/environ | tr '\0' '\n'

এটি আপনার secret-গুলো cleartext-এ দেখায়, কারণ /proc/<pid>/environ root এবং process যে user হিসেবে চলে, উভয়ের কাছেই পাঠযোগ্য। কোনো crash reporter report-এর সঙ্গে environment যুক্ত করলেও একই তথ্য দেখতে পায়। একই account-এর অধীনে চলা যেকোনো tool-ও তা দেখতে পারে। তাই AI agent-এর কাছ থেকে secret দূরে রাখা শুরু হয় environment থেকে secret সরানোর মাধ্যমে। ফাইলটির সঙ্গে কম privilege-যুক্ত dedicated service user ব্যবহার করুন, যাতে “process যে user হিসেবে চলে” সেটি root না হয়।

age দিয়ে SOPS: Git-এ commit করা যায় এমন encrypted secret

SOPS (secrets operations) YAML বা JSON ফাইলের value encrypt করে, কিন্তু key-গুলো cleartext অবস্থায় রাখে। age একটি ছোট encryption tool। এটি একটি key pair দেয় এবং কোনো key server ব্যবহার করে না। একসঙ্গে এগুলো ব্যবহার করলে আপনি secrets.enc.yaml code-এর পাশে commit করতে পারবেন। git diff-এর মাধ্যমে কোনো পাঠক value কী ছিল তা না জেনেও কোন setting পরিবর্তিত হয়েছে তা দেখতে পারবেন।

Ubuntu 24.04-এ age packaged অবস্থায় আছে। SOPS নেই। তাই release page থেকে .deb নিন। August 2026 অনুযায়ী বর্তমান version ছিল 3.13.3।

sudo apt update && sudo apt install -y age
curl -LO https://github.com/getsops/sops/releases/download/v3.13.3/sops_3.13.3_amd64.deb
sudo apt install -y ./sops_3.13.3_amd64.deb
sops --version

একটি key pair তৈরি করুন। age-keygen private key-টি ফাইলে লেখে এবং public key print করে। তাই Public key: age1... দিয়ে শুরু হওয়া একটি line দেখতে পাবেন।

mkdir -p ~/.config/sops/age
age-keygen -o ~/.config/sops/age/keys.txt
chmod 600 ~/.config/sops/age/keys.txt
age-keygen -y ~/.config/sops/age/keys.txt

Repository-এর root-এ .sops.yaml-এ public key রাখুন। এতে command line-এ recipient মনে রাখতে হবে না।

creation_rules:
  - age: age1s3cqcks5genc6ru8chl0hkkd04zmxvczsvdxq99ekffe4gmvjpzsedk23c
sops encrypt secrets.yaml > secrets.enc.yaml
sops decrypt secrets.enc.yaml

path_regex ছাড়া rule সবকিছুর সঙ্গে match করে। শুরুতে এটিই প্রয়োজন। পরে rule যোগ করলে এমনভাবে লিখুন, যাতে এটি sops-এ দেওয়া ফাইলের সঙ্গে match করে। কারণ rule input path-এর বিরুদ্ধে পরীক্ষা করা হয়, output redirect করা ফাইলের বিরুদ্ধে নয়।

Runtime-এ value শুধু একটি process-কে দিন:

sops exec-env secrets.enc.yaml './myapp'

sops exec-env memory-তে decrypt করে এবং child process-এর environment-এ value সেট করে। ফলে plaintext disk-এ লেখা হয় না। আগের section-এ উল্লেখ করা environment-এর সীমাবদ্ধতা এই child process-এর ক্ষেত্রেও প্রযোজ্য।

এখানে দুটি সমস্যা প্রায়ই দেখা যায়। systemd-এর অধীনে Failed to get the data key required to decrypt the SOPS file error-এর অর্থ প্রায় সবসময় SOPS ভুল home directory-তে খুঁজেছে। কারণ unit আপনার HOME inherit করে না। unit-এ Environment=SOPS_AGE_KEY_FILE=/etc/sops/age.txt ব্যবহার করে path স্পষ্টভাবে সেট করুন। অন্যদিকে, .sops.yaml edit করলে আগে থেকে থাকা কোনো file re-encrypt হয় না। কোনো সহকর্মীর public key যোগ করলে শুধু নতুন file প্রভাবিত হয়। তাই প্রতিটি existing file-এ sops updatekeys secrets.enc.yaml চালান। আপনার configuration যদি ইতিমধ্যে Ansible-এর মাধ্যমে পরিচালিত হয়, তাহলে Ansible Vault দিয়ে একই value encrypt করা দ্বিতীয় tool ছাড়াই একই ফল দেয়।

systemd credentials: secrets that never reach the environment

Ubuntu 24.04-এ systemd 255 রয়েছে, তাই এটি ইনস্টল করার প্রয়োজন নেই। systemd-creds host-এ একটি secret encrypt করে, এবং systemd সেটি একটি private directory-তে decrypt করে। শুধু সংশ্লিষ্ট service-ই ওই directory পড়তে পারে।

sudo systemd-creds setup
sudo install -d -m 700 /etc/myapp
echo -n 'hunter2' | sudo systemd-creds encrypt --name=db_password - /etc/myapp/db_password.cred
[Service]
User=myapp
LoadCredentialEncrypted=db_password:/etc/myapp/db_password.cred
ExecStart=/usr/local/bin/myapp

service-টি $CREDENTIALS_DIRECTORY দ্বারা নির্ধারিত directory-র ভেতরে db_password নামের file থেকে value পড়ে। value-টি environment-এ থাকে না। তাই /proc/<pid>/environ কোনো কার্যকর তথ্য দেখায় না। plaintext কখনো root filesystem-এ লেখা হয় না।

কোনো unit-এ এটি ব্যবহার করার আগে file-টি decrypt হচ্ছে কি না যাচাই করুন:

sudo systemd-creds decrypt /etc/myapp/db_password.cred -

কোন key দিয়ে এটি encrypt করা হয়েছে তা জেনে রাখুন। আপনার backup কার্যকর হবে কি না, তা এর ওপর নির্ভর করে। ডিফল্ট --with-key=auto উপস্থিত এবং ব্যবহারযোগ্য হলে TPM2 (trusted platform module version 2) chip ব্যবহার করে। অন্যথায় এটি host key ব্যবহার করে। অধিকাংশ VPS instance-এ TPM2 থাকে না।

systemd-analyze has-tpm2

no-এর অর্থ হলো host key ব্যবহার করা হয়েছে। ওই key /var/lib/systemd/credential.secret-এ থাকে এবং এটি শুধু root পড়তে পারে। ওই file ছাড়া নতুন VPS-এ db_password.cred restore করলে কোনোদিনই সেটি decrypt হবে না। একই backup-এ credential.secret copy করুন, অথবা plaintext এমন কোনো স্থানে রাখুন যেখানে পরে সেটি পাওয়া যাবে।

Docker secrets: /run/secrets/<name>-এর অধীনে থাকা ফাইল

Compose host থেকে একটি ফাইল পড়ে সেটি /run/secrets/<name>-এ container-এর ভিতরে mount করে।

services:
  app:
    image: myapp:latest
    environment:
      DB_PASSWORD_FILE: /run/secrets/db_password
    secrets:
      - db_password
secrets:
  db_password:
    file: ./db_password.txt
docker compose exec app cat /run/secrets/db_password
docker compose exec app env | grep -i password

প্রথম কমান্ডটি secret দেখায়। দ্বিতীয়টি শুধু DB_PASSWORD_FILE=/run/secrets/db_password দেখায়। এটাই মূল বিষয়: মানটি কখনও container environment-এ থাকে না, তাই docker inspect-এর output-এও দেখা যায় না। অনেক official image ইতিমধ্যে এই পদ্ধতি প্রত্যাশা করে, এবং Postgres image ঠিক এইভাবে POSTGRES_PASSWORD_FILE পড়ে।

এটি কী, তা স্পষ্টভাবে বুঝুন। Swarm mode-এর বাইরে কোনো স্তরেই encryption নেই: ./db_password.txt host-এর একটি plaintext file, এবং এর একমাত্র সুরক্ষা হলো file mode ও owner। দুটিই নিজে সেট করুন, কারণ Compose কোনো সতর্কতা ছাড়াই world-readable file mount করে দেবে। সাধারণ env_file shortcut-এর তুলনায় এর সুবিধা ও সীমাবদ্ধতাগুলোর বিস্তারিত Compose env file ও secret-এর নির্দেশিকায় দেওয়া আছে।

OpenBao এবং Vault চালানোর প্রকৃত খরচ

OpenBao হলো HashiCorp Vault-এর Linux Foundation fork। 2023 সালে HashiCorp Vault-কে Business Source License-এর অধীনে পুনরায় লাইসেন্স দেওয়ার পর এটি শুরু হয়। OpenBao এখনও MPL 2.0 (Mozilla Public License)-এর অধীনে রয়েছে। 2026 সালের August পর্যন্ত 2.6.2 ছিল বর্তমান release। Fork-টি একই command surface বজায় রাখায় নিচের প্রায় সবকিছু Vault-এর ক্ষেত্রেও প্রযোজ্য।

docker pull docker.io/openbao/openbao

আপগ্রেডগুলো apt দিয়ে পরিচালনা করতে চাইলে OpenBao downloads page-এ Debian এবং Ubuntu package পাওয়া যায়। Server-এর জন্য এমন একটি config file প্রয়োজন, যাতে একটি listener এবং একটি storage backend থাকে:

listener "tcp" {
  address       = "127.0.0.1:8200"
  tls_cert_file = "/path/to/full-chain.pem"
  tls_key_file  = "/path/to/private-key.pem"
}

storage "raft" {
  path = "/path/to/raft/data"
  node_id = "raft_node_1"
}

এরপর একবার এটি start করুন:

bao operator init

ডিফল্টভাবে এটি root key-কে 5টি share-এ ভাগ করে এবং unseal করার জন্য সেগুলোর মধ্যে 3টি share প্রয়োজন। এগুলো হলো -key-shares এবং -key-threshold flag। এটি share এবং initial root token একবার print করে; পরে আর কখনও করে না।

এখন সেই বিষয়টি দেখা যাক, যা অধিকাংশ তুলনায় বাদ পড়ে। Restart করা server sealed server হয়ে যায়। OpenBao root key শুধু memory-তে রাখে। তাই restart-এর পরে কেউ threshold সংখ্যক share না দেওয়া পর্যন্ত এটি নিজের storage decrypt করতে পারে না। ফলে kernel update বা out of memory kill-এর পর server sealed অবস্থায় থাকে এবং application-গুলো log in করতে পারে না।

একজন ব্যবহারকারীর VPS-এ Shamir split কোনো সুরক্ষা দেয় না, কারণ পাঁচটি share-ই একই ব্যক্তির একই password manager-এ থাকে। Auto unseal key-টিকে একটি trusted device বা service-এ সরিয়ে রাখে। বড় cloud environment-এ এটি সাধারণত managed key service বোঝায়। আপনার VPS-এ এর অর্থ সাধারণত data-র সঙ্গে একই disk-এ রাখা একটি key file। এতে security সত্যিই কমে যায়, বিনিময়ে reboot-এর পর server নিজে থেকে চালু হওয়ার সুবিধা পাওয়া যায়। এই trade-off জেনে সিদ্ধান্ত নিন এবং কোন পদ্ধতি বেছে নিয়েছেন তা লিখে রাখুন।

Infisical: একটি UI, একটি database এবং আপনার কাছে থাকা master key

Infisical হলো web interface, project, environment এবং ব্যবহারকারীভিত্তিক access control-সহ একটি secrets platform। Compose ব্যবহার করে এটি self-host করা সংক্ষিপ্ত:

curl -o docker-compose.prod.yml https://raw.githubusercontent.com/Infisical/infisical/main/docker-compose.prod.yml
curl -o .env https://raw.githubusercontent.com/Infisical/infisical/main/.env.example
docker compose -f docker-compose.prod.yml up -d

শেষের command চালানোর আগে .env সম্পাদনা করুন। দুটি value আপনাকে নির্ধারণ করতে হবে, এবং এর একটি পরে আর কখনও পরিবর্তন করা যাবে না:

openssl rand -hex 16
openssl rand -base64 32

প্রথমটি হলো ENCRYPTION_KEY, একটি 16 byte hex string। PostgreSQL-এর ভিতরে আপনার secret encrypt করতে এই key ব্যবহার করা হয়। তাই এটি হারালে সম্পূর্ণ database backup-ও ব্যবহার অযোগ্য ciphertext-এ পরিণত হয়। চলমান instance-এ এটি পরিবর্তন করলে বিদ্যমান secret decrypt করা বন্ধ হয়ে যায়। দ্বিতীয়টি হলো AUTH_SECRET, session-এর জন্য ব্যবহৃত একটি 32 byte base64 string। SITE_URL-এ protocol-সহ আপনি বাস্তবে যে absolute URL-এ পৌঁছাবেন, সেটিই দিতে হবে। তা না হলে login redirect কাজ করবে না।

আপনার প্রকৃত প্রয়োজন যদি মানুষকেন্দ্রিক হয়, তাহলে OpenBao-এর তুলনায় Infisical বেশি উপযোগী। এটি একটি ছোট দলের জন্য web interface এবং environment-গুলোর মধ্যে পৃথকীকরণ দেয়। OpenBao-এর মতো নিজে থেকে মেয়াদ শেষ হওয়া database credential-এর ব্যবস্থাপনা এখানে মূল লক্ষ্য নয়। এর বিনিময়ে PostgreSQL, Redis এবং একটি TLS certificate পরিচালনা করতে হবে। এগুলোর সবকিছুর patching ও backup এখন আপনাকেই করতে হবে।

Secrets service বন্ধ থাকলে এবং আপনার app পুনরায় চালু হলে কী ঘটে

এই প্রশ্নের উত্তরই নির্ধারণ করে secrets service একটি single box-এ রাখা উচিত কি না। Network শুরু হওয়ার আগে file পড়া যায়। কিন্তু service পড়া যায় না।

Box reboot করুন। আপনার application এবং OpenBao একই সময়ে শুরু হবে। Application তার database password চাইবে। OpenBao তখনও sealed থাকবে। Request ব্যর্থ হবে। Unseal share-গুলো কোনো ব্যক্তি paste না করা পর্যন্ত systemd application-টিকে loop-এর মধ্যে পুনরায় চালু করতে থাকবে। কিছুই নষ্ট হয়নি। কিন্তু কিছুই চালুও নেই।

এটি সামলানোর দুটি বাস্তব উপায় আছে। Unit-গুলোর ক্রম নির্ধারণ করুন এবং application-কে retry করতে দিন: After= secrets service, পাশাপাশি Restart=on-failure এবং একটি RestartSec= রাখুন, যাতে আপনি API-তে অতিরিক্ত request না পাঠান। অথবা boot-এর সময় না নিয়ে deploy-এর সময় secret সংগ্রহ করুন: secret-টি mode 600 file অথবা systemd credential হিসেবে লিখুন, যাতে চলমান system একটি API-এর পরিবর্তে file-এর ওপর নির্ভর করে।

Token expiry একই সমস্যা, তবে ধীর সময়সীমায়। OpenBao token এবং lease-এ time to live থাকে। তাই renew না করা দীর্ঘ সময় চলা process deploy-এর সঙ্গে সম্পর্কহীন কোনো সময়ে access হারায়। এই failure বিভ্রান্তিকর, কারণ সেদিন এমন কিছুই পরিবর্তন হয়নি।

স্টোরটি নিজেই ব্যাকআপ করা

এখানে প্রতিটি বিকল্পের একটি key আছে, এবং সেই key ছাড়া ব্যাকআপ মূল্যহীন। আপনার key কোথায় সংরক্ষিত আছে, তা লিখে রাখুন।

env file-এর ক্ষেত্রে file-টিই secret, তাই ব্যাকআপটি encrypted হতে হবে। SOPS-এর ক্ষেত্রে encrypted file যেকোনো public স্থানে রাখা যায়, তবে ~/.config/sops/age/keys.txt-এ থাকা age private key হারানো যাবে না। systemd credentials-এর ক্ষেত্রে /var/lib/systemd/credential.secret-কে .cred file-গুলোর সঙ্গে ব্যাকআপ করুন। Infisical-এর ক্ষেত্রে PostgreSQL dump নিন এবং ENCRYPTION_KEY-কে dump থেকে আলাদা কোনো স্থানে সংরক্ষণ করুন।

OpenBao raft storage ব্যবহার করলে নিজস্ব snapshot নেয়:

bao operator raft snapshot save backup.snap
bao operator raft snapshot restore backup.snap

এই snapshot-এ আপনার encrypted storage থাকে। তাই fresh server-এ এটি restore করতেও bao operator init থেকে unseal share প্রয়োজন হবে। এমন একটি nightly job, যা snapshot object storage-এ কপি করে কিন্তু share কোথাও সংরক্ষণ করে না, আসলে কোনো কিছুরই ব্যাকআপ নয়। এর ওপর নির্ভর করার আগে একটি throwaway VPS-এ restore পরীক্ষা করুন।

অডিট লগিং: কে কোন secret পড়েছে

Files কোনো audit trail দেয় না। mode এবং owner বলে কে secret পড়তে পারত। কিন্তু কে সত্যিই পড়েছে, তা কখনো বলে না। auditd-এ path-এর ওপর watch বসানোই সবচেয়ে কাছাকাছি বিকল্প। তবে এটি শুধু জানায় যে একটি file খোলা হয়েছে; কোন value ব্যবহার করা হয়েছে, তা জানায় না।

আপনি যে audit device সক্রিয় করেন, OpenBao প্রতিটি request সেখানে log করে:

bao audit enable file file_path=/var/log/openbao_audit.log

এই log-এর দুটি বৈশিষ্ট্য server পরিচালনার পদ্ধতি বদলে দেয়। Request ও response-এর অধিকাংশ string HMAC-SHA256 এবং salt ব্যবহার করে hash করা হয়। তাই log-এ plaintext না রেখেই আপনার আগে থেকে জানা কোনো value-এর সঙ্গে log মিলিয়ে দেখা যায়। Integer এবং boolean সরাসরি cleartext-এ লেখা হয়। তাই numeric secret এই hashing থেকে কোনো সুরক্ষা পায় না।

এরপর আসে operational trap: কোনো enabled audit device request record করতে না পারলে OpenBao request-এর উত্তর দেয় না। কোনো device blocking উপায়ে ব্যর্থ হলে, সমস্যা সমাধান না হওয়া পর্যন্ত request hang করে থাকে। /var/log-এর disk পূর্ণ হয়ে গেলে নকশা অনুযায়ী আপনার secrets API বন্ধ হয়ে যায়। প্রথম দিনেই audit log-এর জন্য আলাদা space এবং একটি logrotate rule নির্ধারণ করুন। প্রথম outage-এর পরে নয়।

কোন self-hosted secrets manager চালাবেন?

মেশিনের সংখ্যা এবং ব্যবহারকারীর সংখ্যা হিসাব করে নির্বাচন করুন।

  1. একটি মেশিন, একজন ব্যবহারকারী: root-এর মালিকানাধীন mode 600 env file ব্যবহার করুন এবং service user-কে সেটি পড়ার অনুমতি দিন। মানটি process environment-এর বাইরে রাখতে চাইলে systemd credentials যোগ করুন।
  2. একটি মেশিন, দুই থেকে পাঁচজন ব্যবহারকারী, এবং configuration ইতিমধ্যে git-এ আছে: age সহ SOPS ব্যবহার করুন। প্রত্যেক ব্যবহারকারীর জন্য একটি key pair তৈরি করুন, এবং .sops.yaml-এ decrypt করার অনুমতিপ্রাপ্ত প্রতিটি public key তালিকাভুক্ত করুন।
  3. একাধিক মেশিন, একটি configuration repository, এবং মেয়াদ শেষ হওয়া credentials-এর প্রয়োজন নেই: এখানেও age সহ SOPS ব্যবহার করুন। প্রতিটি host-এর জন্য একটি recipient key রাখুন, যাতে কোনো host key চুরি হলেও শুধু সেই host-এর file decrypt করা যায়।
  4. একাধিক মেশিন ও একাধিক team, যাদের সত্যিই নির্দিষ্ট lifetime-সহ database credentials দরকার, এবং এমন audit trail দরকার যা কেউ পর্যালোচনা করে: OpenBao ব্যবহার করুন। Unseal এবং restore drill-এর জন্য প্রতি মাসে operator-এর এক ঘণ্টা সময় বাজেটে রাখুন।

চার ক্ষেত্রেই মূল নিয়ম একই। মুখে স্পষ্টভাবে বলা যায় এমন requirement পূরণ করে—এমন সবচেয়ে ছোট system চালান। কারণ যে secrets manager down আছে, সেটি খালি secrets manager থেকে আলাদা করে বোঝা যায় না।

FAQ

একক VPS-এর জন্য self-hosted secrets manager কি উপযোগী?

সাধারণত নয়, যদি আপনি OpenBao বা Infisical-এর মতো service বোঝান। একটি box-এ এক বা দুইজন ব্যবহারকারী থাকলে, mode 600-এ রাখা env file বা systemd encrypted credential অন্য কোনো local user-এর বিরুদ্ধে একই সুরক্ষা দেয়। এতে unseal ধাপ বা patch করার জন্য অতিরিক্ত service লাগে না। কয়েকটি machine ও কয়েকজন ব্যবহারকারী থাকলে, অথবা কারও হাতে credential rotate না করেও credential expire করার বাস্তব প্রয়োজন থাকলে secrets service ব্যবহার করা সার্থক হয়।

password manager এবং secrets manager-এর মধ্যে পার্থক্য কী?

password manager এমন credential সংরক্ষণ করে যা একজন ব্যক্তি টাইপ করেন, এবং সেই ব্যক্তি উপস্থিত থাকলে এটি unlock করেন। secrets manager process-কে credential দেয়, তাই রাত 03:00-তেও কাউকে নজরদারি না করেই এটি কাজ করতে হয়। এখানেই মূল পার্থক্য: locked password manager আপনাকে master password আবার টাইপ করতে বাধ্য করে, আর sealed secrets manager sealed থাকা অবস্থায় restart হওয়া প্রতিটি service বন্ধ করে দেয়।

reboot-এর পরে OpenBao sealed থাকলে আমার app-গুলোর কী হয়?

তারা নিজেদের secret সংগ্রহ করতে পারে না, তাই start হতে ব্যর্থ হয়। কেউ unseal threshold সরবরাহ না করা পর্যন্ত systemd তাদের loop-এর মধ্যে restart করতে থাকে। ডিফল্টভাবে unseal threshold হলো 5টি share-এর মধ্যে 3টি। OpenBao root key শুধু memory-তে রাখে, তাই প্রতিটি restart-এর পরে এটি আবার seal হয়ে যায়। আপনি auto unseal চালু করতে পারেন; তবে একক VPS-এ এতে unseal key data-এর একই disk-এ থেকে যায়। অথবা deploy-এর সময় secret file-এ লিখে দিন, যাতে boot কখনো API-এর ওপর নির্ভর না করে।

SOPS encrypted file কি public repository-তে commit করা যায়?

value-গুলো encrypted থাকে, তাই age private key ছাড়া অন্য কারও কাছ থেকে সেগুলো সুরক্ষিত থাকে। তবে key-গুলো encrypted নয়: একজন reader দেখতে পারে যে আপনার কাছে STRIPE_SECRET_KEY এবং SMTP_PASSWORD আছে, এবং প্রতিটি কত ঘন ঘন পরিবর্তিত হয়। অধিকাংশ project-এর জন্য এই metadata গ্রহণযোগ্য, তবে কিছু project-এর জন্য নয়। age private key repository-এর বাইরে রাখুন। কোনো recipient যোগ বা সরানোর সময় বিদ্যমান প্রতিটি file-এ sops updatekeys চালান।

#secrets#security#openbao#sops#systemd#self-hosting