GitHub Actions cache-এ চার স্তরের অনুমতি—ভুল write-এ ঝুঁকি ফিরবে
GitHub ১০ সেপ্টেম্বর ২০২৬-এ GitHub Actions-এর cache-mode github.com-এর সব প্ল্যানে সাধারণভাবে উন্মুক্ত করেছে। GitHub-এর প্রকাশিত ঘোষণায় read, write, write-only ও none—এই চার মানের পাশাপাশি workflow ও job স্তরে cache access নিয়ন্ত্রণের সুবিধা নিশ্চিত করা হয়েছে।
নতুন ব্যবস্থায় read শুধু cache restore করে, write restore ও save দুটিই করে, write-only শুধু save করে এবং none উভয় কাজ বন্ধ রাখে। তবে low-trust trigger-এর read-only default স্পষ্টভাবে write বা write-only দিয়ে বদলে দিলে অনির্ভরযোগ্য run আবার shared cache-এ উপাদান রাখতে পারে; ১১ সেপ্টেম্বর প্রকাশিত C# Corner-এর স্বাধীন বিশ্লেষণেও পরবর্তী trusted workflow সেই উপাদান restore ও execute করার ঝুঁকিটি ব্যাখ্যা করা হয়েছে।
চার mode-এর restore ও save ক্ষমতা
cache-mode মূলত cache পড়া ও লেখার ক্ষমতাকে আলাদা করে। Workflow-এর top level-এ বসানো মান সাধারণভাবে সব job-এ প্রযোজ্য, কিন্তু jobs.<job_id>.cache-mode-এ আলাদা মান দিলে সংশ্লিষ্ট job সেটিই ব্যবহার করে।
- read — restore: হ্যাঁ, save: না। আগে তৈরি cache ব্যবহার করা যায়, কিন্তু job সেটি তৈরি বা হালনাগাদ করতে পারে না। Pull request পরীক্ষা বা অন্য low-trust কাজের জন্য এটি সাধারণত উপযুক্ত সীমা।
- write — restore: হ্যাঁ, save: হ্যাঁ। একই job পুরোনো cache ব্যবহার এবং নতুন cache সংরক্ষণ করতে পারে। Repository-নিয়ন্ত্রিত code থেকে cache রক্ষণাবেক্ষণ করা trusted build-এ এই ক্ষমতা প্রয়োজন হতে পারে।
- write-only — restore: না, save: হ্যাঁ। job পুরোনো cache গ্রহণ না করে নতুন entry প্রকাশ করতে পারে। Trusted input থেকে আলাদা cache তৈরির job-এ এটি কাজে লাগে; low-trust job-এ দিলে লেখার ঝুঁকি থেকেই যায়।
- none — restore: না, save: না। shared cache-এর সঙ্গে job-এর সম্পর্ক পুরোপুরি বন্ধ থাকে। Cache প্রয়োজন নেই বা shared state গ্রহণ করা উচিত নয়—এমন কাজের জন্য এটিই সংকীর্ণতম সীমা।
GitHub-এর dependency caching reference অনুযায়ী, নির্বাচিত mode scoped cache token দিয়ে কার্যকর হয়। নিষিদ্ধ restore cache miss হিসেবে গণ্য হয় এবং নিষিদ্ধ save বাদ পড়ে; শুধু এ কারণে step বা workflow ব্যর্থ হয় না। কার্যকর মান ACTIONS_CACHE_MODE environment variable-এও পাওয়া যায়।
Trigger অনুযায়ী কোন mode মানানসই
cache-mode লেখা না থাকলে GitHub trigger-এর trust অনুযায়ী default নির্ধারণ করে। push-এর মতো trusted trigger সাধারণভাবে write পায়, আর pull_request_target, issue_comment বা default branch-এ চলা নির্দিষ্ট workflow_run-এর মতো low-trust trigger read-only access পায়।
তবে event-এর নাম একা সিদ্ধান্তের জন্য যথেষ্ট নয়। Job কোন code ও string process করে, cache key বা saved path কে প্রভাবিত করতে পারে এবং কোন privileged workflow পরে cache restore করবে—এসব মিলিয়ে trust boundary নির্ধারণ করতে হয়। সেই ভিত্তিতে সিদ্ধান্তের সারণিটি দাঁড়ায়:
- Trusted push, cache রক্ষণাবেক্ষণ প্রয়োজন: write; restore ও save দুটিই অনুমোদিত।
- Low-trust pull_request_target: read; restore অনুমোদিত, save বন্ধ। Mode না লিখলেও secure default একই হতে পারে, কিন্তু explicit read উদ্দেশ্যটি review-তে দৃশ্যমান করে।
- Trusted dedicated cache builder: write-only; পুরোনো cache না নিয়ে নতুন cache প্রকাশের প্রয়োজন হলে প্রযোজ্য।
- Cache-বিচ্ছিন্ন পরীক্ষা বা deployment ধাপ: none; restore ও save—দুটিই বন্ধ।
write-only-কে read-এর আরও কঠোর সংস্করণ ভাবা ঠিক নয়। read লেখার পথ বন্ধ রেখে cache গ্রহণ করে; write-only গ্রহণের পথ বন্ধ রেখে cache প্রকাশ করে। ফলে low-trust trigger-এ write-only-ও write-capable অনুমতি।
ভুল write কীভাবে poisoning-এর পথ খোলে
Low-trust workflow-তে mode না লিখলে read-only সীমা shared cache বদলাতে বাধা দেয়। কিন্তু workflow বা job-এ cache-mode: write অথবা cache-mode: write-only বসালে সেই default override হয় এবং GitHub warning annotation দেখালেও run থামায় না।
ঝুঁকির জন্য তিনটি অবস্থা একসঙ্গে দরকার: অনির্ভরযোগ্য input cache-এর content প্রভাবিত করতে পারে, সংশ্লিষ্ট job-এর save access আছে এবং পরবর্তী বেশি ক্ষমতাসম্পন্ন workflow সেই cache restore করে ব্যবহার করে। এমন অবস্থায় cached dependency, build output বা executable file-এর মাধ্যমে attacker-controlled content trusted pipeline-এ পৌঁছাতে পারে।
এ কারণে low-trust job-এর জন্য read এবং trusted push workflow-এর জন্য cache রক্ষণাবেক্ষণের দায়িত্ব আলাদা রাখা সবচেয়ে সরল সীমা। কোনো ব্যতিক্রমে write প্রয়োজন হলে সেটি নিরাপদ প্রমাণিত হয় শুধু তখনই, যখন save হওয়ার আগে fork-এর code, pull request-এর file, ব্যবহারকারী-নিয়ন্ত্রিত expression বা script output cache content ও key-কে প্রভাবিত করতে পারে না।
Reusable workflow-তে caller-এর সীমা
Reusable workflow-এ cache access caller থেকে propagate করে। Calling job-এ explicit cache-mode থাকলে, অথবা caller workflow থেকে সেটি inherited হলে, called workflow সেই সীমার বাইরে restore বা save ক্ষমতা চাইতে পারে না; বেশি access চাইলে run শুরু হওয়ার আগেই validation error হয়।
read ও write-only একই ক্রমের ছোট-বড় permission নয়, কারণ একটির ক্ষমতা restore এবং অন্যটির ক্ষমতা save। তাই read সীমার caller-এর অধীনে called workflow write-only চাইলে সেটিও অতিরিক্ত access হিসেবে ধরা হয়।
গুরুত্বপূর্ণ ব্যতিক্রমটি implicit default নিয়ে। Calling job বা তার workflow-এ explicit cache-mode না থাকলে low-trust trigger কার্যত read পেলেও called reusable workflow নিজে write চাইতে পারে। Reusable workflow-কে নিশ্চিতভাবে read-only রাখতে হলে তাকে যে job calls করছে, সেই job-এ cache-mode: read লেখা প্রয়োজন।
Migration audit-এ যে YAML স্থানগুলো দেখতে হবে
পর্যালোচনার প্রথম লক্ষ্য .github/workflows-এর top-level cache-mode এবং প্রতিটি jobs.<job_id>.cache-mode। কারণ নিরাপদ workflow-level মান একটি job override-এ বদলে যেতে পারে, আবার reusable workflow caller-এ explicit ceiling না থাকলে called workflow প্রত্যাশার চেয়ে বেশি access চাইতে পারে।
- on অংশে push, pull_request_target, issue_comment ও workflow_run শনাক্ত করে দেখুন কার input run-এ পৌঁছাতে পারে এবং কোন branch-এর cache scope ব্যবহৃত হচ্ছে।
- actions/cache, cache-সক্ষম setup action ও custom action কোথায় restore বা save করে তা চিহ্নিত করুন।
- Top-level mode-এর সঙ্গে প্রতিটি job override মিলিয়ে write ও write-only কোন trigger-এ কার্যকর হচ্ছে তা বের করুন।
- uses দিয়ে reusable workflow ডাকা job-এ explicit cache-mode ceiling আছে কি না এবং called workflow কোন access চায় তা মিলিয়ে নিন।
- Write-capable low-trust path থাকলে cache key, cached path ও save-এর আগের প্রতিটি step অনির্ভরযোগ্য input গ্রহণ করছে কি না যাচাই করুন।
- পরিবর্তনের পরে cache log ও warning annotation পরীক্ষা করুন, কারণ mode কোনো operation আটকালেও workflow সফল দেখাতে পারে।
এখন পর্যন্ত নিশ্চিত অবস্থা হলো, চারটি mode github.com-এর সব GitHub প্ল্যানে ব্যবহারযোগ্য এবং enforcement cache service-এর scoped token-এ হচ্ছে। তবে কোন job-কে write দেওয়া নিরাপদ, সেই repository-specific সিদ্ধান্ত GitHub স্বয়ংক্রিয়ভাবে নেয় না; low-trust trigger-এর explicit override, job-level ব্যতিক্রম এবং reusable workflow caller-এর অনুল্লিখিত সীমাই migration review-এর প্রধান অনিশ্চয়তা।
আরও পড়ুন:
আমাদের নিউজলেটার নিন
সর্বশেষ Web3, AI ও ক্রিপ্টো সংবাদ সরাসরি আপনার ইনবক্সে পান।