cert-manager، Let’s Encrypt، اور اندرونی TLS کا استعمال کرتے ہوئے Kubernetes ٹریفک کو کیسے انکرپٹ کریں

زیادہ تر انجینئرز فرض کرتے ہیں کہ ان کا Kubernetes کلسٹر تمام ٹریفک کو خفیہ کرتا ہے۔ یہ سچ نہیں ہے۔ استعمال کرنے کا حکم kubectl یہ انکرپٹڈ ہے۔ کلائنٹ اور API سرور TLS استعمال کرتے ہیں۔ API سرورز جو etcd کے ساتھ بات چیت کرتے ہیں وہ بھی عام طور پر انکرپٹ ہوتے ہیں، اس بات پر منحصر ہے کہ کلسٹر کی فراہمی کیسے کی گئی ہے۔

لیکن پھلیوں کے درمیان ٹریفک کا کیا ہوگا؟ یہ بنیادی طور پر سادہ متن ہے۔ کیا انٹرنیٹ سے آپ کی سروس پر آنے والی ٹریفک ہے؟ صرف اس صورت میں خفیہ کیا جاتا ہے جب TLS واضح طور پر کنفیگر ہو۔ اور داخلی خدمات کے سرٹیفکیٹ کے بارے میں کیا خیال ہے؟ آپ کو خود اس کا انتظام کرنا ہوگا۔

یہ Kubernetes کی نگرانی نہیں ہے۔ یہ جان بوجھ کر ڈیزائن کا انتخاب ہے۔ Kubernetes عمارت کے بلاکس فراہم کرتا ہے اور عمل درآمد آپ پر چھوڑ دیتا ہے۔ مسئلہ یہ ہے کہ سرٹیفکیٹ کا انتظام بہت تکلیف دہ ہے۔ آپ کے سرٹیفکیٹ کی میعاد ختم ہو رہی ہے۔ اگر آپ اسے دستی طور پر فراہم کرتے ہیں، تو یہ پیمانہ نہیں ہوگا۔ اگر آپ اسے تبدیل کرنا بھول جاتے ہیں، تو یہ خرابی کا سبب بنے گا۔

cert-manager اس مسئلے کو حل کرتا ہے۔ کلسٹر کے اندر ایک کنٹرولر کے طور پر چلتا ہے۔ Certificate وسائل استعمال کریں، ترتیب شدہ جاری کنندگان سے سرٹیفکیٹ کی درخواست کریں، انہیں Kubernetes Secrets میں اسٹور کریں، اور ان کی میعاد ختم ہونے سے پہلے خود بخود ان کی جگہ لے لیں۔ آپ اعلان کرتے ہیں کہ آپ کیا چاہتے ہیں، اور سرٹیفیک مینیجر اسے ہوتا ہے اور اسے آپ کے لیے برقرار رکھتا ہے۔

اس آرٹیکل میں، ہم اس بات پر ایک نظر ڈالیں گے کہ سرٹیفکیٹ مینیجر کا بنیادی ماڈل کس طرح کام کرتا ہے، لیٹس انکرپٹ کے ساتھ پبلک Ingress TLS کو خودکار بنائیں، کراس سروس انکرپشن کے لیے ایک اندرونی سرٹیفکیٹ اتھارٹی قائم کریں، اور یہ سمجھیں گے کہ سرٹیفکیٹ کی گردش کیسے کام کرتی ہے تاکہ سرٹیفکیٹ کی میعاد ختم ہونے کی وجہ سے بندش ماضی کی بات ہو۔

شرطیں

• ایک قسم کا کلسٹر جس میں nginx Ingress کنٹرولر نصب ہے۔

• ہیلم 3 انسٹال ہے۔

• DNS کے ساتھ ڈومین کا نام جسے آپ کنٹرول کرتے ہیں — Let’s Encrypt ڈیمو کے لیے درکار ہے۔

• TLS کی بنیادی تفہیم: آپ جانتے ہیں کہ سرٹیفکیٹس، نجی کلیدیں، اور CA کیا ہیں۔

تمام ڈیمو فائلیں DevOps-Cloud-Projects GitHub ذخیرہ میں ہیں۔

انڈیکس

کبرنیٹس میں کیا انکرپٹڈ ہے اور کیا انکرپٹ نہیں ہے؟

کسی بھی چیز کو انسٹال کرنے سے پہلے، یہ جاننا اچھا خیال ہے کہ آپ کا کلسٹر پہلے سے کس چیز کی حفاظت کر رہا ہے اور کیا کھلا ہے۔

نقل و حمل کا راستہ	کیا یہ بطور ڈیفالٹ خفیہ کردہ ہے؟	میمو
kubectl → API سرور	ہاں	کلسٹر CA کا استعمال کرتے ہوئے TLS
API سرور → etcd	زیادہ تر	کلسٹر پروویژنر پر منحصر ہے – سیٹنگز چیک کریں۔
API سرور → کوبیلیٹ	ہاں	TLS، لیکن کیوبلیٹ سرٹیفیکیشن کنفیگریشن پر منحصر ہے۔
Pod → Pod (ایک ہی کلسٹر)	نہیں	سادہ متن جب تک کہ آپ سروس میش یا ایم ٹی ایل ایس شامل نہ کریں۔
انٹرنیٹ → داخل	نہیں	آپٹ ان – آپ کے داخلی وسائل کے لیے TLS کنفیگریشن کی ضرورت ہے۔
Pod → Kubernetes API	ہاں	سروس اکاؤنٹ ٹوکن اور کلسٹر CA کے ذریعے

عملی طور پر، دو سب سے اہم خلا انٹر پوڈ ٹریفک اور Ingress TLS ہیں۔ اس مضمون میں Let’s Encrypt کا استعمال کرتے ہوئے Ingress TLS اور پرائیویٹ CAs کا استعمال کرتے ہوئے اندرونی سروس ٹو سروس انکرپشن دونوں کا احاطہ کیا گیا ہے۔

سرٹیفکیٹ مینیجر کیسے کام کرتا ہے۔

cert-manager Kubernetes آپریٹر ہے۔ Kubernetes API کو حسب ضرورت وسائل کے ساتھ بڑھائیں جو سرٹیفکیٹ کی درخواستوں اور ان کی ترتیب کی نمائندگی کرتے ہیں۔ آپ Certificate جب آپ کوئی وسیلہ منتخب کرتے ہیں، تو سرٹیفکیٹ مینیجر کا کنٹرولر اسے منتخب کرتا ہے، کنفیگر شدہ جاری کنندہ سے سرٹیفکیٹ کی درخواست کرتا ہے، اور نتیجے میں آنے والے سرٹیفکیٹ اور نجی کلید کو کبرنیٹس سیکریٹ میں محفوظ کرتا ہے۔ جب کسی سرٹیفکیٹ کی میعاد ختم ہوجاتی ہے، تو سرٹیفکیٹ مینیجر خود بخود اس کی تجدید کرتا ہے۔

اس ماڈل کا مطلب ہے کہ درخواست سرٹیفکیٹ کے انتظام کے بارے میں نہیں جانتی ہے اور نہ ہی اس کی پرواہ کرتی ہے۔ راز پڑھیں۔ cert-manager اپنے راز کو تازہ ترین رکھتا ہے۔

4 کلیدی وسائل

cert-manager چار حسب ضرورت وسائل متعارف کراتا ہے جنہیں آپ باقاعدگی سے استعمال کریں گے۔

مرضی	یہ کیا نمائندگی کرتا ہے
Issuer	سرٹیفیکیشن اتھارٹی یا ACME اکاؤنٹ – نام کی جگہ کا دائرہ
ClusterIssuer	جاری کنندہ کی طرح، لیکن کلسٹر وسیع دستیاب ہے۔
Certificate	سرٹیفکیٹ کی درخواست – بیان کریں کہ آپ کیا چاہتے ہیں۔
CertificateRequest	انفرادی دستخط کی درخواستیں – سرٹ مینیجر کے ذریعہ خود بخود تیار کی جاتی ہیں اور شاذ و نادر ہی براہ راست چھونے کی ضرورت ہوتی ہے۔

عملی طور پر، یہ زیادہ تر مسائل کا احاطہ کرتا ہے۔ ClusterIssuer اور Certificate. کہ ClusterIssuer سرٹیفکیٹ کی اصلیت کی وضاحت کرتا ہے۔ کہ Certificate سرٹیفکیٹ کی وضاحت کریں جو آپ چاہتے ہیں اور اسے کہاں ذخیرہ کرنا ہے۔

جاری کنندہ اور کلسٹر جاری کنندہ

نہیں Issuer آپ صرف اپنے نام کی جگہ میں سرٹیفکیٹ جاری کر سکتے ہیں۔ کوئی راستہ نہیں ClusterIssuer آپ کسی بھی نام کی جگہ میں سرٹیفکیٹ جاری کر سکتے ہیں۔ Let’s Encrypt جیسے مشترکہ انفراسٹرکچر کے لیے، یہ تقریباً ہمیشہ ہوتا ہے۔ ClusterIssuer. درخواست کے ساتھ مخصوص اندرونی CAs کے لیے Issuer اسے اپنی درخواست کے نام کی جگہ تک پھیلانا ایک محفوظ انتخاب ہے۔

cert-manager متعدد جاری کنندگان کی اقسام کو سپورٹ کرتا ہے۔ جن تینوں کا آپ اکثر سامنا کریں گے وہ ہیں:

زینت — Let’s Encrypt یا ACME-compliant CAs سے عوامی سرٹیفکیٹس کے لیے۔ ڈومین کی ملکیت HTTP-01 یا DNS-01 چیلنج کے ذریعے ثابت ہوتی ہے۔

کیلیفورنیا – ایک CA کے دستخط شدہ داخلی سرٹیفکیٹس کے لیے جس کی نجی کلید Kubernetes Secret میں محفوظ ہے۔ ایک کلسٹر کے اندر خدمات کے درمیان TLS کے لیے استعمال کیا جاتا ہے۔

خود دستخط شدہ – خود دستخط شدہ سرٹیفکیٹ بنائیں۔ یہ اپنے طور پر بہت کم کام کا ہے، لیکن اندرونی CA بناتے وقت بوٹسٹریپنگ قدم کے طور پر ضروری ہے۔

سرٹیفکیٹ لائف سائیکل

آپ Certificate وسائل، سرٹیفکیٹ مینیجر، اس حکم کی پیروی کرتا ہے:

1. نسل CertificateRequest سرٹیفکیٹ پر دستخط کرنے کی درخواست (CSR) استعمال کریں

2. CSR کو کنفیگر کردہ جاری کنندہ کو بھیجیں۔

3. ACME جاری کرنے والوں کے لیے: Challenge وسائل حاصل کریں اور ان پر عمل درآمد کریں (ذیل میں تفصیلات دیکھیں)۔

4. جاری کنندہ سے دستخط شدہ سرٹیفکیٹ حاصل کریں۔

5. سرٹیفکیٹ اور نجی کلید کو کوبرنیٹس سیکریٹ میں محفوظ کریں۔ spec.secretName

6. سرٹیفکیٹ کی میعاد ختم ہونے کی نگرانی کریں۔ پہلے سے طے شدہ طور پر، اس کی تجدید اس وقت ہوتی ہے جب میعاد کا 2/3 گزر جاتا ہے۔

ایپلی کیشن راز کو ماؤنٹ کرتی ہے۔ cert-manager خود بخود اپ ڈیٹ ہوجاتا ہے۔ زیادہ تر ایپلیکیشنز جو فائل کی تبدیلیوں کو دیکھتے ہیں وہ دوبارہ شروع کیے بغیر نیا سرٹیفکیٹ اٹھا لیں گی۔

ACME چیلنج: HTTP-01 بمقابلہ DNS-01

آئیے انکرپٹ کے لیے اس بات کا ثبوت درکار ہے کہ آپ سرٹیفکیٹ جاری کرنے سے پہلے ڈومین کو کنٹرول کرتے ہیں۔ ACME اس کے لیے چیلنج کی دو اقسام کی وضاحت کرتا ہے:

HTTP-01 یہ سرٹیف مینیجر کو ایک عارضی HTTP اینڈ پوائنٹ بنا کر کام کرتا ہے۔ http:///.well-known/acme-challenge/. آئیے انکرپٹ اس URL کو ایک درخواست بھیجتا ہے۔ اگر جواب متوقع ٹوکن سے میل کھاتا ہے، تو چیلنج گزر جاتا ہے۔ اس کے لیے ضروری ہے کہ آپ کا کلسٹر پورٹ 80 کے ذریعے انٹرنیٹ سے قابل رسائی ہو۔

DNS-01 یہ سرٹیف مینیجر کو عارضی DNS TXT ریکارڈ بنا کر کام کرتا ہے۔ _acme-challenge.. آئیے اس ریکارڈ پر ایک چیک کو خفیہ کریں۔ یہ پرائیویٹ کلسٹرز کے لیے ایک اچھا انتخاب ہے کیونکہ اس کے لیے ان باؤنڈ HTTP رسائی کی ضرورت نہیں ہے اور یہ وائلڈ کارڈ سرٹیفکیٹ حاصل کرنے کا واحد طریقہ ہے (*.example.com)۔

Cons: HTTP-01 ترتیب دینا آسان ہے، لیکن صرف ایک ڈومین کے لیے کام کرتا ہے اور انٹرنیٹ تک رسائی کے ساتھ بنیادی ڈھانچے کی ضرورت ہوتی ہے۔ DNS-01 کو آپ کے DNS فراہم کنندہ تک API رسائی درکار ہے، لیکن یہ اندرونی کلسٹرز اور وائلڈ کارڈز کے لیے کام کرتا ہے۔

ڈیمو 1 – پیبل اینڈ لیٹس انکرپٹ کا استعمال کرتے ہوئے سرٹیفکیٹ مینیجر کو انسٹال کرنا اور سرٹیفکیٹ جاری کرنا

پیبل لیٹس انکرپٹ کا مقامی ACME ٹیسٹ سرور ہے۔ یہ ایک کلسٹر کے اندر چلتا ہے، اسی ACME پروٹوکول کا استعمال کرتے ہوئے سرٹیفکیٹ جاری کرتا ہے جیسا کہ Let’s Encrypt، اور اسے عوامی ڈومین یا انٹرنیٹ تک رسائی کی ضرورت نہیں ہے۔ پیبل آپ کو ایک عام کلسٹر پر پورے سرٹیفکیٹ مینیجر کے بہاؤ (چیلنج، اجراء، تجدید) کی جانچ کرنے کی اجازت دیتا ہے۔

ایک بار جب آپ مقامی طور پر بہاؤ کو سمجھ لیں، تو حقیقی Let’s Encrypt پر سوئچ کرنا صرف ایک لائن کی تبدیلی ہے۔ یعنی، ClusterIssuer سرور URL کو تبدیل کریں اور اسے اپنے عوامی طور پر قابل رسائی کلسٹر میں DNS ریکارڈ کی طرف اشارہ کریں۔ باقی ترتیب وہی ہے۔

سرٹیفکیٹ مینیجر اور انسٹال کریں۔ ClusterIssuer Let’s Encrypt کے لیے، Ingress کا استعمال کرتے ہوئے نمونہ ایپلی کیشن کو تعینات کریں اور خود بخود جاری اور ذخیرہ شدہ اصلی سرٹیفکیٹ دیکھیں۔

مرحلہ 1: سرٹیفکیٹ مینیجر انسٹال کریں۔

cert-manager اب OCI ہیلم چارٹ کے ذریعے تقسیم کیا جاتا ہے۔ quay.io/jetstack. کہ --set crds.enabled=true پرچم چارٹ کے حصے کے طور پر ایک حسب ضرورت وسائل کی تعریف کو انسٹال کرتا ہے۔

helm upgrade cert-manager oci://quay.io/jetstack/charts/cert-manager \
  --install \
  --create-namespace \
  --namespace cert-manager \
  --set crds.enabled=true \
  --version v1.17.0 \
  --wait

آپ کو nginx Ingress کنٹرولر کی بھی ضرورت ہوگی۔ cert-manager اس کے ذریعے HTTP-01 کے مسائل کو روٹس کرتا ہے۔ کہ controller.service.type=ClusterIP اوور رائیڈنگ خاص طور پر قسم کے لیے ہے: ڈیفالٹ۔ LoadBalancer خدمت کبھی نہیں EXTERNAL-IP قسم پر منحصر ہے (کوئی کلاؤڈ ایل بی نہیں) --wait اسے ہمیشہ کے لیے لٹکا دو۔ ایک حقیقی کلسٹر میں، ہم اوور رائڈ کو حذف اور رکھتے ہیں۔ LoadBalancer.

helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update

helm install ingress-nginx ingress-nginx/ingress-nginx \
  --namespace ingress-nginx \
  --create-namespace \
  --set controller.service.type=ClusterIP \
  --wait

یقینی بنائیں کہ چاروں اجزاء چل رہے ہیں۔

kubectl get pods -n cert-manager
kubectl get pods -n ingress-nginx

NAME                                       READY   STATUS    RESTARTS   AGE
cert-manager-76f84784c8-r4fx4              1/1     Running   0          6m45s
cert-manager-cainjector-66fbf49587-gv25n   1/1     Running   0          6m45s
cert-manager-webhook-577fddf86-l5wj4       1/1     Running   0          6m45s

NAME                                        READY   STATUS    RESTARTS   AGE
ingress-nginx-controller-6c7cd85885-h7zgx   1/1     Running   0          3m34s

فی زمرہ کے مسائل — nginx کی اجازت یافتہ ویب ہک کو ابھی ہٹا دیں۔ ** زمرہ میں nginx کی اجازت یافتہ ویب ہک خود دستخط شدہ سرٹیفکیٹ کے ساتھ آتا ہے جس کی Kubernetes API سرور تصدیق نہیں کر سکتا۔ جب آپ پہلی بار اسے بنانے کی کوشش کرتے ہیں۔ کوئی بھی داخل ہونے والے وسائل دکھائے گئے۔ failed calling webhook "validate.nginx.ingress.kubernetes.io": ... x509: certificate signed by unknown authority. باقی ڈیمو کو ٹرپ کرنے سے بچنے کے لیے وقت سے پہلے ویب ہک کو حذف کریں۔

kubectl delete validatingwebhookconfiguration ingress-nginx-admission

مرحلہ 2: پیبل انسٹال کریں۔

پیبل ایک مقامی ACME ٹیسٹ سرور ہے جسے JupyterHub پروجیکٹ کے ذریعے تقسیم کیا گیا ہے۔ ساتھی CoreDNS تقسیم کے ساتھ آتا ہے (pebble-coredns) وہ ہے جسے پیبل ACME تصدیق کے دوران ناموں کو حل کرنے کے لیے استعمال کرتا ہے۔

helm install pebble pebble \
  --repo https://jupyterhub.github.io/helm-chart/ \
  --namespace pebble \
  --create-namespace \
  --wait

یقینی بنائیں کہ دونوں پوڈ چل رہے ہیں۔

kubectl get pods -n pebble

NAME                              READY   STATUS    RESTARTS   AGE
pebble-8d8d49d64-lz8ck            1/1     Running   0          36s
pebble-coredns-7fb5c7cbf4-4jw9h   1/1     Running   0          36s

مرحلہ 3: جعلی میزبان نام سے DNS کنیکٹوٹی

ہم سرٹیفکیٹ جاری کرنے کا ارادہ رکھتے ہیں: echo.pebble.local. وہ میزبان نام جعلی ہے۔ یہ حقیقی DNS میں موجود نہیں ہے، اس لیے اسے سکھایا جانا چاہیے۔ دو ایک آزاد حل کرنے والا اشاعت سے پہلے اس پر کام کرتا ہے۔

حل کرنے والا	کہاں استعمال کرنا ہے۔	ہمیں کیا ضرورت ہے
pebble-coredns (میں pebble نام کی جگہ)	HTTP-01 کی توثیق کی درخواست کرتے وقت، خود پیبل	حل echo.pebble.local → Incoming-nginx ClusterIP
کلسٹر کور ڈی این ایس (kube-system)	سرٹیفکیٹ مینیجر میں HTTP-01 خود چیک کریں چیلنج کی اطلاع دینے سے پہلے تیار رہیں	اب سے pebble.local چیک کریں pebble-coredns

اگر آپ کسی بھی پرت کو چھوڑ دیتے ہیں، تو آپ کا آرڈر اگلی پر چلا جاتا ہے۔ invalid DNS تلاش ناکام حالت

سب سے پہلے، دو IPs حاصل کریں جن کی آپ کو ضرورت ہے۔

NGINX_IP=$(kubectl get svc -n ingress-nginx ingress-nginx-controller \
  -o jsonpath="{.spec.clusterIP}")
PEBBLE_DNS_IP=$(kubectl get svc pebble-coredns -n pebble \
  -o jsonpath="{.spec.clusterIP}")
echo "NGINX_IP=\(NGINX_IP  PEBBLE_DNS_IP=\)PEBBLE_DNS_IP"

جگہ pebble-coredns جواب *.pebble.local سننے والے کنٹرولر کے IP پر۔ کور ڈی این ایس template پلگ ان ایک حقیقی ملٹی لائن کنفیگ میپ کا اطلاق کرتا ہے کیونکہ جب پورا بلاک ایک لائن میں سمٹ جاتا ہے تو یہ اسے ناقابل اعتبار طور پر پارس کرتا ہے۔

cat <

یقینی بنائیں کہ آپ صحیح جواب دیتے ہیں۔

kubectl run dnstest --rm -it --restart=Never --image=busybox -- \
  nslookup echo.pebble.local ${PEBBLE_DNS_IP}

آپ کو دیکھنا چاہئے Address: جواب میں۔ اگر آپ کو ملتا ہے SERVFAILچیک کریں kubectl logs -n pebble deploy/pebble-coredns – تجزیہ کار کی غلطیاں جیسے: not a TTL: "}" اس کا مطلب ہے کہ ٹیمپلیٹ بلاک کو دوبارہ ایک لائن تک کم کر دیا گیا ہے۔

کلسٹر CoreDNS پیچ لہذا، سرٹیفک مینیجر کا اپنا چیک اسی نام کو حل کرسکتا ہے۔ آگے بڑھانے کے لیے اسٹب ایریا شامل کریں۔ pebble.local کو pebble-coredns:

cat <

تصدیق کریں کہ کلسٹر حل کرنے والا اب جواب دیتا ہے: echo.pebble.local (سرور کی وضاحت نہ کریں اور ڈیفالٹ kube-dns استعمال کریں):

kubectl run dnstest --rm -it --restart=Never --image=busybox -- \
  nslookup echo.pebble.local

دونوں Server: 10.96.0.10 اور Address: آپ کو دکھانا ہوگا۔

مرحلہ 4: پیبل CA درآمد کریں اور ایک کلسٹر جاری کنندہ بنائیں

پیبل سرٹیفکیٹ پر خود دستخط شدہ جڑ کے ساتھ دستخط کرتا ہے: pebble ConfigMap کے تحت root-cert.pem. cert-manager کو پیبل کی ACME ڈائرکٹری کے ساتھ بات چیت کرنے کے لیے اس CA پر بھروسہ کرنے کی ضرورت ہے، لہذا ہم اسے base64 انکوڈنگ میں پاس کرتے ہیں۔ caBundle کلسٹر جاری کرنے والے میں:

kubectl get configmap pebble -n pebble \
  -o jsonpath="{.data.root-cert\.pem}" > pebble-ca.crt

head -1 pebble-ca.crt   # should print -----BEGIN CERTIFICATE-----

CA_BUNDLE=$(base64 -i pebble-ca.crt | tr -d '\n')
echo "CA_BUNDLE length: ${#CA_BUNDLE}"   # ~1600 chars, one continuous line

heredoc کا استعمال کرتے ہوئے ایک ClusterIssuer بنائیں۔ ${CA_BUNDLE} شیل متغیرات کو YAML سے تبدیل کر دیا جاتا ہے اس سے پہلے کہ kubectl ان کو پڑھے۔

kubectl apply -f - <

یقینی بنائیں کہ آپ کا جاری کنندہ تیار ہے۔

kubectl get clusterissuer pebble

NAME     READY   AGE
pebble   True    5s

اگر READY قیام Falseدو سب سے عام وجوہات ایک خراب کیبنڈل ہیں (یقینی بنائیں کہ یہ ایک واحد غیر ٹوٹی ہوئی بیس 64 لائن ہے جس میں کوئی نئی لائن نہیں ہے) یا پیبل۔ cert-manager نام کی جگہ۔ کنیکٹیویٹی چیک کرنے کے لیے، درج ذیل کام کریں:

kubectl run test-curl --rm -it --restart=Never \
  --image=curlimages/curl:latest \
  --namespace cert-manager -- \
  curl -k https://pebble.pebble.svc.cluster.local/dir

JSON واپس آنے کے بعد، آپ پیبل تک رسائی حاصل کر سکتے ہیں۔

مرحلہ 5: نمونہ ایپلیکیشن تعینات کریں۔

# echo-app.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: echo
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: echo
  template:
    metadata:
      labels:
        app: echo
    spec:
      containers:
        - name: echo
          image: ealen/echo-server:latest
          ports:
            - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: echo
  namespace: default
spec:
  selector:
    app: echo
  ports:
    - port: 80
      targetPort: 80

kubectl apply -f echo-app.yaml

تصدیق کریں کہ وسیلہ ظاہر ہے۔

kubectl get deploy,pod,svc -n default

NAME                   READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/echo   1/1     1            1           32s

NAME                        READY   STATUS    RESTARTS   AGE
pod/echo-5665fbcfdd-mbgxj   1/1     Running   0          36s

NAME                 TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
service/echo         ClusterIP   10.96.103.114           80/TCP    40s
service/kubernetes   ClusterIP   10.96.0.1               443/TCP   32m

مرحلہ 6: TLS کا استعمال کرتے ہوئے ایک سنیں بنائیں

کہ cert-manager.io/cluster-issuer: pebble تشریح سرٹیف مینیجر سے کہتی ہے کہ وہ اسے خود بخود تیار کرے۔ Certificate ابھی آپ نے جو جاری کنندہ بنایا ہے اسے استعمال کرتے ہوئے اس Ingress کے لیے وسائل فراہم کریں۔ میزبان نام echo.pebble.local باہر سے چیک کرنے کی ضرورت نہیں ہے۔ ہم نے آپ کو مرحلہ 3 میں دونوں DNS حل کرنے والوں کے بارے میں سکھایا۔

# echo-ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: echo
  namespace: default
  annotations:
    cert-manager.io/cluster-issuer: pebble
spec:
  ingressClassName: nginx
  tls:
    - hosts:
        - echo.pebble.local
      secretName: echo-tls     # cert-manager will create this Secret
  rules:
    - host: echo.pebble.local
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: echo
                port:
                  number: 80

kubectl apply -f echo-ingress.yaml

مرحلہ 7: جاری ہونے والا سرٹیفکیٹ دیکھیں

# Watch the Certificate resource (Ctrl-C once Ready=True)
kubectl get certificate echo-tls -n default -w

NAME       READY   SECRET     AGE
echo-tls   False   echo-tls   5s
echo-tls   True    echo-tls   28s

جب READY بن جاتا ہے۔ Trueسرٹیفکیٹ درج ذیل جگہ پر جاری اور محفوظ کیا گیا ہے: echo-tls خفیہ مکمل سلسلہ (CertificateRequest → Order → Challenge → Solver Pod → Secret) ایک صحت مند کلسٹر پر 1 منٹ سے بھی کم وقت میں ہوتا ہے۔

kubectl get certificate,certificaterequest,order,challenge -n default

NAME                                   READY   SECRET     AGE
certificate.cert-manager.io/echo-tls   True    echo-tls   81s

NAME                                            APPROVED   DENIED   READY   ISSUER   AGE
certificaterequest.cert-manager.io/echo-tls-1   True                True    pebble   81s

NAME                                               STATE   AGE
order.acme.cert-manager.io/echo-tls-1-1824732543   valid   81s

(آرڈر مکمل ہونے کے بعد چیلنج خود بخود حذف ہوجاتا ہے، لہذا kubectl get challenge -n default عام طور پر اس مقام پر کچھ بھی ظاہر نہیں ہوتا ہے۔ یہ ناکامی نہیں بلکہ کامیابی ہے۔)

اگر READY قیام False براہ کرم اس سیکشن کے آخر میں ٹربل شوٹنگ کی تجاویز دیکھنے کے لیے کم از کم ایک منٹ نکالیں۔

جاری کردہ سرٹیفکیٹ کو چیک کریں کہ اس پر پیبل کے دستخط ہیں۔

kubectl get secret echo-tls -n default -o jsonpath="{.data.tls\.crt}" | \
  base64 -d | openssl x509 -noout -issuer -subject -dates

issuer=CN=Pebble Intermediate CA 05478c
subject=
notBefore=May 17 19:09:22 2026 GMT
notAfter=Aug 15 19:09:21 2026 GMT

جاری کنندہ پیبل کا انٹرمیڈیٹ CA ہے۔ اس سے ثابت ہوتا ہے کہ ACME کے پورے بہاؤ نے شروع سے آخر تک کام کیا۔ سرٹیفکیٹس 90 دنوں کے لیے درست ہیں اور سرٹیفکیٹ مینیجر خود بخود 60 دنوں میں ان کی تجدید کر دیتا ہے۔

کلسٹر کے اندر، یہ یقینی بنانے کے لیے HTTPS پر سننے کی کوشش کریں کہ ہر چیز ایک ساتھ جڑی ہوئی ہے۔

kubectl run curltest --rm -it --restart=Never --image=curlimages/curl -- \
  curl -sk https://echo.pebble.local/

ایکو سرور کو JSON بلاب واپس کرنا چاہئے۔ "x-forwarded-proto":"https" یہ فیلڈ ثابت کرتی ہے کہ درخواست TLS پر nginx کے ذریعے کی گئی تھی۔

اگر سرٹیفکیٹ تیار حالت میں داخل نہیں ہوتا ہے تو مسئلہ حل کریں:

• kubectl describe order -n default – ایونٹ میں "DNS ایشوز” یا "کنکشن سے انکار” تلاش کریں۔

• kubectl logs -n pebble deploy/pebble --tail=50 – پیبل بالکل وہی یو آر ایل لاگ کرتا ہے جسے اس نے بازیافت کرنے کی کوشش کی تھی اور تصدیق کے دوران ہونے والی کوئی غلطی۔

• اگر کوئی آرڈر ایونٹ کے بغیر زیر التوا ہے: سرٹیف مینیجر سے ابھی تک صلح نہیں ہوئی ہے۔ بس 30 سیکنڈ انتظار کریں۔

• اگر آپ کا آرڈر ہے: invalid: دو DNS تہوں میں سے ایک (سطح 3) غلط طریقے سے ترتیب دی گئی ہے۔ دونوں کو دوبارہ چلائیں nslookup چیکر

• اگر Ingress ایپلی کیشن خود x509 ویب ہک کی خرابی کے ساتھ ناکام ہوجاتی ہے: kubectl delete validatingwebhookconfiguration ingress-nginx-admission مرحلہ 1 پر جائیں۔

مرحلہ 8: چلو انکرپٹ سٹیجنگ پر سوئچ کریں (اصل عوامی ڈومین)

پیبل نے ثابت کیا کہ بہاؤ مقامی طور پر کام کرتے ہیں۔ اب اپنے عوامی طور پر قابل رسائی ڈومین پر جائیں، جو آپ کے عوامی طور پر قابل رسائی کلسٹر کی طرف اشارہ کرتا ہے۔ تین سطحی DNS اسکیم ختم ہو گئی ہے۔ چونکہ ڈومین ایک حقیقی ڈومین ہے، دونوں حل کرنے والے بغیر کسی مداخلت کے ڈومین تلاش کرتے ہیں۔

آئیے انکرپٹ کا استعمال کریں۔ ڈرامہ کاری پہلے یہ اسی ACME پروٹوکول کو پروڈکشن کے طور پر استعمال کرتا ہے، لیکن اس کی شرح کی حد ہوتی ہے لہذا جانچ کے دوران ناکام کوششیں آپ کو مسدود نہیں کرتی ہیں۔

# clusterissuer-staging.yaml
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-staging
spec:
  acme:
    server: https://acme-staging-v02.api.letsencrypt.org/directory
    email: your-email@example.com
    privateKeySecretRef:
      name: letsencrypt-staging-account-key
    solvers:
      - http01:
          ingress:
            ingressClassName: nginx

kubectl apply -f clusterissuer-staging.yaml

# Point the Ingress at staging and the real hostname, then force re-issuance
kubectl annotate ingress echo \
  cert-manager.io/cluster-issuer=letsencrypt-staging --overwrite -n default
kubectl delete secret echo-tls -n default

نئے سرٹیفکیٹ جاری کرنے والے ہیں: (STAGING) Let's Encrypt.

مرحلہ 9: آئیے انکرپٹ پروڈکشن میں منتقلی۔

ایک بار جب اسٹیجنگ کام کرتی ہے، پروڈکشن کلسٹر جاری کرنے والے کا استعمال کرتے ہوئے دہرائیں۔ فرق صرف اتنا ہے server URL:

# clusterissuer-prod.yaml
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: your-email@example.com
    privateKeySecretRef:
      name: letsencrypt-prod-account-key
    solvers:
      - http01:
          ingress:
            ingressClassName: nginx

kubectl apply -f clusterissuer-prod.yaml
kubectl annotate ingress echo \
  cert-manager.io/cluster-issuer=letsencrypt-prod --overwrite -n default
kubectl delete secret echo-tls -n default

سرٹیفکیٹ مینیجر گمشدہ رازوں کا پتہ لگاتا ہے اور فوری طور پر لیٹس انکرپٹ پروڈکشن سے براؤزر کے ذریعہ قابل اعتماد سرٹیفکیٹ کی درخواست کرتا ہے۔

cert-manager گمشدہ راز کا پتہ لگاتا ہے اور فوری طور پر پروڈکشن جاری کنندہ کا استعمال کرتے ہوئے ایک نئی سرٹیفکیٹ کی درخواست کو متحرک کرتا ہے۔

DNS-01 کے ساتھ وائلڈ کارڈ سرٹیفکیٹ کیسے حاصل کریں۔

HTTP-01 چیلنجز عوامی استقبال کے ساتھ واحد ڈومین کے لیے موزوں ہیں۔ تاہم، اس کے بجائے دو صورتیں ہیں جہاں DNS-01 کی ضرورت ہے: اس کا مطلب ہے کہ آپ کا کلسٹر عوامی طور پر قابل رسائی نہیں ہے (اندرونی کلسٹر، ایئر گیپڈ ماحول، VPN کے پیچھے سٹیجنگ نام کی جگہ) اور آپ کو ایک وائلڈ کارڈ سرٹیفکیٹ کی ضرورت ہے جو آپ کے ڈومین کے تمام ذیلی ڈومینز کا احاطہ کرتا ہو۔

DNS-01 کو سرٹیفکیٹ مینیجر کی ضرورت ہے، جو آپ کے DNS فراہم کنندہ میں TXT ریکارڈ بنا اور حذف کر سکتا ہے۔ cert-manager کے پاس Route53، Cloud DNS، Cloudflare، Azure DNS، اور بہت سے دوسرے کے لیے بلٹ ان سپورٹ ہے۔

یہاں ClusterIssuer AWS Route53 کا استعمال کرتے ہوئے DNS-01 کے لیے:

# clusterissuer-dns01.yaml
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-dns01
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: your-email@example.com
    privateKeySecretRef:
      name: letsencrypt-dns01-account-key
    solvers:
      - dns01:
          route53:
            region: us-east-1
            # Use IRSA (IAM Roles for Service Accounts) in production
            # rather than static credentials
            hostedZoneID: YOUR_HOSTED_ZONE_ID

وائلڈ کارڈ Certificate اس جاری کنندہ کا استعمال کرتے ہوئے:

# wildcard-cert.yaml
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: wildcard-example-com
  namespace: default
spec:
  secretName: wildcard-example-com-tls
  issuerRef:
    name: letsencrypt-dns01
    kind: ClusterIssuer
  commonName: "*.example.com"
  dnsNames:
    - "*.example.com"
    - "example.com"        # Also cover the apex domain
  duration: 2160h           # 90 days
  renewBefore: 720h         # Renew 30 days before expiry

نتیجہ راز wildcard-example-com-tls کوئی بھی داخلہ اس کا حوالہ دے سکتا ہے۔ default نام کی جگہ۔ تمام ذیلی ڈومینز – api.example.com، dashboard.example.com، staging.example.com – ایک واحد، خود بخود گھومنے والے سرٹیفکیٹ کے ذریعے محفوظ۔

Route53 کے بجائے Cloudflare کے لیے، سولور سیکشن اس طرح لگتا ہے:

    solvers:
      - dns01:
          cloudflare:
            email: your-email@example.com
            apiTokenSecretRef:
              name: cloudflare-api-token
              key: api-token

ڈیمو 2 – سروس ٹو سروس TLS کے لیے ایک اندرونی CA ترتیب دینا

آئیے انکرپٹ سرٹیفکیٹ عوامی خدمت کے لیے موزوں ہیں۔ تاہم، اندرونی خدمات کے لیے (gRPC مائیکرو سروسز جو دوسری سروسز کو کال کرتی ہیں، ویب ایپلیکیشنز جو ڈیٹا بیس سے بات کرتی ہیں)، عوامی اعتماد کی ضرورت نہیں ہے۔ آپ کو ایک CA کی ضرورت ہے جس پر آپ کا کلسٹر بھروسہ کرتا ہے، اور آپ کو خدمت کے ناموں کے لیے سرٹیفکیٹ جاری کرنے کے لیے CA کی ضرورت ہے جو عوامی DNS ریکارڈز میں موجود نہیں ہیں۔

سرٹیف مینیجر میں CA جاری کنندہ اسے سنبھالتا ہے۔ ایک روٹ CA بنائیں، اسے سرٹیفکیٹ مینیجر کو مطلع کریں، اور اس CA کو داخلی خدمات کے لیے سرٹیفکیٹ جاری کرنے کے لیے استعمال کریں۔ کوئی بھی سروس جو روٹ CA پر بھروسہ کرتی ہے اس کے جاری کردہ کسی بھی سرٹیفکیٹ پر بھروسہ کرے گی۔

مرحلہ 1: خود دستخط شدہ کلسٹر جاری کنندہ بنائیں

ایک خود دستخط شدہ جاری کنندہ ایک سرٹیفکیٹ بناتا ہے جس پر خود سرٹیفکیٹ کے دستخط ہوتے ہیں۔ یہ اس کا اپنا CA ہے۔ ہم اسے روٹ CA سرٹیفکیٹ بنانے کے لیے بوٹسٹریپ قدم کے طور پر استعمال کرتے ہیں۔

# selfsigned-issuer.yaml
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: selfsigned
spec:
  selfSigned: {}

kubectl apply -f selfsigned-issuer.yaml

مرحلہ 2: روٹ CA سرٹیفکیٹ بنائیں

خود دستخط شدہ جاری کنندہ کا استعمال کرتے ہوئے CA سرٹیفکیٹ بنائیں۔ کہ isCA: true فیلڈ سرٹیفکیٹ مینیجر کو بتاتی ہے کہ یہ سرٹیفکیٹ دوسرے سرٹیفکیٹس پر دستخط کر سکتا ہے۔

# internal-ca.yaml
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: internal-ca
  namespace: cert-manager    # Store in cert-manager namespace
spec:
  isCA: true
  commonName: internal-ca
  secretName: internal-ca-secret
  duration: 87600h           # 10 years — this is a root CA
  renewBefore: 720h
  privateKey:
    algorithm: ECDSA
    size: 256
  issuerRef:
    name: selfsigned
    kind: ClusterIssuer

kubectl apply -f internal-ca.yaml
kubectl get certificate internal-ca -n cert-manager

NAME          READY   SECRET               AGE
internal-ca   True    internal-ca-secret   8s

مرحلہ 3: ایک CA ClusterIssuer بنائیں جسے روٹ CA کی حمایت حاصل ہو۔

اب ClusterIssuer روٹ CA راز کا استعمال کریں جو آپ نے ابھی بنایا ہے۔ داخلی خدمات کے لیے سرٹیفکیٹ پر دستخط کرنے والے جاری کنندگان میں شامل ہیں:

# internal-ca-issuer.yaml
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: internal-ca
spec:
  ca:
    secretName: internal-ca-secret   # References the Secret in cert-manager namespace

kubectl apply -f internal-ca-issuer.yaml
kubectl get clusterissuer internal-ca

NAME          READY   AGE
internal-ca   True    5s

مرحلہ 4: داخلی خدمات کے لیے سرٹیفکیٹ جاری کریں۔

اب ہم اپنی داخلی جی آر پی سی خدمات کے لیے سرٹیفکیٹ جاری کریں گے۔ کہ dnsNames Kubernetes اندرونی DNS نام استعمال کریں – ..svc.cluster.local:

# payments-cert.yaml
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: payments-tls
  namespace: production
spec:
  secretName: payments-tls-secret
  issuerRef:
    name: internal-ca
    kind: ClusterIssuer
  commonName: payments.production.svc.cluster.local
  dnsNames:
    - payments.production.svc.cluster.local
    - payments.production.svc
    - payments
  duration: 2160h     # 90 days
  renewBefore: 360h   # Renew 15 days before expiry

kubectl create namespace production
kubectl apply -f payments-cert.yaml
kubectl get certificate payments-tls -n production

NAME           READY   SECRET                AGE
payments-tls   True    payments-tls-secret   6s

خفیہ payments-tls-secret اب شامل ہے۔ tls.crt، tls.keyاور ca.crt. اسے اپنے ایپلیکیشن پوڈ پر لگائیں۔

# In your Deployment spec
volumes:
  - name: tls
    secret:
      secretName: payments-tls-secret
containers:
  - name: payments
    volumeMounts:
      - name: tls
        mountPath: /etc/tls
        readOnly: true

آپ کی درخواست اس طرح نظر آتی ہے: /etc/tls/tls.crt اور /etc/tls/tls.key TLS کو ترتیب دیں۔ دوسری خدمات پڑھیں جن پر آپ کو بھروسہ کرنے کی ضرورت ہے۔ /etc/tls/ca.crt.

مرحلہ 5: ٹرسٹ مینیجر کا استعمال کرتے ہوئے CA بنڈل کو تعینات کریں۔

کسٹم CA کے ساتھ مسئلہ یہ ہے کہ ہر سروس کو اس کے بارے میں جاننے کی ضرورت ہے۔ Trust-manager، cert-manager کا ایک ساتھی ٹول، CA بنڈل کو اس طرح تقسیم کر کے اس کو سنبھالتا ہے: ConfigMap تمام نام کی جگہوں میں:

helm upgrade trust-manager oci://quay.io/jetstack/charts/trust-manager \
  --install \
  --namespace cert-manager \
  --wait

بنانا Bundle CA سرٹیفکیٹ حاصل کرنے کے وسائل internal-ca-secret پورے کلسٹر میں تعینات کریں۔

# ca-bundle.yaml
apiVersion: trust.cert-manager.io/v1alpha1
kind: Bundle
metadata:
  name: internal-ca-bundle
spec:
  sources:
    - secret:
        name: internal-ca-secret
        key: ca.crt
  target:
    configMap:
      key: ca-bundle.crt
    namespaceSelector:
      matchLabels:
        # Distribute to all namespaces with this label
        kubernetes.io/metadata.name: production

kubectl apply -f ca-bundle.yaml

چند سیکنڈ کے بعد، آپ کے پاس تمام مماثل نام کی جگہوں کے لیے ایک ConfigMap کا نام ہوگا۔ internal-ca-bundle CA سرٹیفکیٹ شامل ہے۔ ایپلی کیشنز اس ConfigMap کو بغیر کسی سروس کے مخصوص کنفیگریشن کے اندرونی طور پر جاری کردہ سرٹیفکیٹس پر بھروسہ کرنے کے لیے ماؤنٹ کرتی ہیں۔

مرحلہ 6: سرٹیفکیٹ چین کی تصدیق کریں۔

# Extract the CA cert and service cert
kubectl get secret payments-tls-secret -n production \
  -o jsonpath="{.data.ca\.crt}" | base64 -d > ca.crt

kubectl get secret payments-tls-secret -n production \
  -o jsonpath="{.data.tls\.crt}" | base64 -d > payments.crt

# Verify the cert was signed by the CA
openssl verify -CAfile ca.crt payments.crt

payments.crt: OK

سرٹیفکیٹ کی گردش کیسے کام کرتی ہے۔

سرٹیفکیٹ کی گردش سرٹیفکیٹ مینجمنٹ کا وہ حصہ ہے جو اکثر پروڈکشن کلسٹرز کے ناکام ہونے کا سبب بنتا ہے۔ cert-manager اسے خود بخود ہینڈل کرتا ہے، لیکن طریقہ کار کو سمجھنے سے آپ کو مسائل پیدا ہوتے ہی ٹیون اور ڈیبگ کرنے میں مدد ملے گی۔

cert-manager روزانہ مانیٹر کرتا ہے۔ Certificate رازوں کی ڈیفالٹ سرٹیفکیٹ کی میعاد ختم ہونے کے انتظام اور جانچ کے لیے ایک وسیلہ۔ اگر باقی ماندہ مدت درستگی کی مدت سے کم ہے، renewBefore جب حد تک پہنچ جاتی ہے، سرٹیف مینیجر ایک تجدید کو متحرک کرتا ہے۔ پہلے سے طے شدہ renewBefore سرٹیفکیٹ کی کل میعاد کی مدت کا 1/3 ہے۔ لہذا، 90 دن کے سرٹیفکیٹ کی تجدید 60 دن سے شروع ہوتی ہے۔

جب آپ تجدید کرتے ہیں تو کچھ نیا پیدا ہوتا ہے۔ CertificateRequestجاری کرنے کے پورے بہاؤ سے گزریں اور اپنے موجودہ مقام سے راز کو اپ ڈیٹ کریں۔ نیا سرٹیفکیٹ جوہری طور پر پرانے سرٹیفکیٹ کی جگہ لے لیتا ہے۔ وہ ایپلیکیشنز جو فائل ماؤنٹس کا استعمال کرتی ہیں اور تبدیلیوں پر نظر رکھتی ہیں (جو زیادہ تر جدید ویب سرورز اور جی آر پی سی فریم ورک کرتے ہیں) دوبارہ شروع کیے بغیر نیا سرٹیفکیٹ اٹھا لیں گی۔

# See the current rotation status
kubectl describe certificate echo-tls -n default

آؤٹ پٹ میں درج ذیل فیلڈز تلاش کریں:

Status:
  Not After:   2024-06-18T10:00:00Z
  Not Before:  2024-03-20T10:00:00Z
  Renewal Time: 2024-05-18T10:00:00Z   # When cert-manager will start renewing
  Conditions:
    Type:    Ready
    Status:  True
    Message: Certificate is up to date and has not expired

اگر تجدید ناکام ہو جاتی ہے، مثال کے طور پر کیونکہ HTTP-01 چیلنج مکمل نہیں ہو سکتا، تو سرٹیف مینیجر ایکسپونیشنل بیک آف کا استعمال کرتے ہوئے دوبارہ کوشش کرتا ہے۔ موجودہ سرٹیفکیٹس اس وقت تک پیش کیے جاتے رہیں گے جب تک کہ ان کی اصل میعاد ختم نہ ہو جائے، مسئلہ کو ڈیبگ کرنے کے لیے ایک ونڈو فراہم کرتے ہیں۔

تجدید کے واقعات کو حقیقی وقت میں دیکھنے کے لیے، ان مراحل پر عمل کریں:

kubectl get events -n default --field-selector reason=Issued
kubectl get events -n default --field-selector reason=Failed

ماحول renewBefore صحیح طریقے سے: عوامی خدمات کے لیے، 90 دن کا سرٹیفکیٹ حاصل کرنے سے 30 دن پہلے ایک معقول بفر ہے۔ اندرونی قلیل مدتی سرٹیفکیٹس کے لیے (24 گھنٹے درست)، درج ذیل کو سیٹ کریں: renewBefore زیادہ سے زیادہ 8 گھنٹے ہیں، اس لیے اگر پہلی کوشش ناکام ہو جائے تو بھی میعاد ختم ہونے سے پہلے ہی متبادل ہو جائے گا۔ سیٹ نہیں ہے۔ renewBefore آدھے سے زیادہ سرٹیفکیٹ کی درستگی کے ساتھ — سرٹیفکیٹ مینیجر فوری طور پر اس سرٹیفکیٹ کی تجدید کرنے کی کوشش کرے گا جسے اس نے ابھی جاری کیا ہے۔

صفائی

# Remove demo resources
kubectl delete ingress echo -n default
kubectl delete service echo -n default
kubectl delete deployment echo -n default
kubectl delete secret echo-tls -n default
kubectl delete certificate payments-tls -n production
kubectl delete namespace production

# Uninstall cert-manager and trust-manager
helm uninstall trust-manager -n cert-manager
helm uninstall cert-manager -n cert-manager
kubectl delete namespace cert-manager

# Remove ClusterIssuers
kubectl delete clusterissuer letsencrypt-staging letsencrypt-prod \
  internal-ca selfsigned 2>/dev/null

نتیجہ

Kubernetes TLS کنفیگریشن کو مکمل طور پر آپ پر چھوڑ دیتا ہے۔ اس مضمون میں آپ نے اس ذمہ داری کے عوامی اور اندرونی دونوں پہلوؤں پر توجہ دی ہے۔

عوامی سطح پر، میں فی الحال OCI ہیلم چارٹ کا استعمال سرٹیفیک مینیجر کو انسٹال کرنے کے لیے کرتا ہوں۔ ClusterIssuer Let’s Encrypt کے تعاون سے، ہم نے سرٹیفکیٹ مینیجر کو ACME HTTP-01 چیلنج فلو سے گزرتے ہوئے دیکھا، ایک عارضی سولور پوڈ بنانے سے لے کر ایک درست سرٹیفکیٹ کو کوبرنیٹس سیکریٹ میں اسٹور کرنے تک۔ ہم نے دیکھا ہے کہ کس طرح سٹیجنگ سے پروڈکشن میں تبدیل ہونا ایک سطری تبصرے کی تبدیلی ہے، اور کس طرح سرٹیفکیٹ مینیجر سرٹیفکیٹس کی میعاد ختم ہونے سے پہلے خود بخود تجدید کرتا ہے۔

اندرونی طرف، آپ سرٹیف مینیجر کے خود دستخط شدہ جاری کنندہ کا استعمال کرتے ہوئے ایک نجی CA بوٹسٹریپ کرتے ہیں اور ClusterIssuer اس CA کے تعاون سے، ہم نے داخلی خدمت کے ناموں کے لیے سرٹیفکیٹ جاری کیے جو صرف کلسٹر کے اندر موجود ہیں۔ CA بنڈل کو کلسٹر میں تقسیم کرنے کے لیے، ہم نے ٹرسٹ مینیجر کا استعمال کیا تاکہ سروسز کو بغیر کسی سروس کے مخصوص کنفیگریشن کے ایک دوسرے کے سرٹیفکیٹس پر بھروسہ کرنے کی اجازت دی جائے۔ ہم نے یہ بھی دیکھا کہ سرٹیفکیٹ چین کو کیسے چیک کیا جائے۔ openssl آپ تصدیق کر سکتے ہیں کہ یہ پروڈکشن میں تعینات کرنے سے پہلے کام کرتا ہے۔

سرٹیفکیٹ کی گردش کو سمجھنا وہی ہے جو ایک ٹیم جو اعتماد کے ساتھ TLS کا انتظام کرتی ہے اور ایک ٹیم کے درمیان فرق کرتا ہے جو میعاد ختم ہونے والے سرٹیفکیٹس کے ساتھ صبح 3 بجے اٹھتی ہے۔ cert-manager تجدید کو خودکار کرتا ہے، لیکن renewBefore فیلڈ سیفٹی مارجن ہے۔ اسے درست طریقے سے ترتیب دینے کا طریقہ جانیں اور اپنی تجدید کی حیثیت کو پڑھیں۔

اس دستاویز کے لیے تمام YAML مینی فیسٹس اور ہیلم ویلیوز DevOps-Cloud-Projects GitHub ریپوزٹری میں دستیاب ہیں۔