- গিটহাব অ্যাকশনের গোপন তথ্য হলো এনক্রিপ্ট করা, স্কোপড এনভায়রনমেন্ট ভেরিয়েবল যা রিপোজিটরি, এনভায়রনমেন্ট এবং অর্গানাইজেশন লেভেলে সাবধানে স্কোপ করা আবশ্যক।
- নিরাপত্তা নির্ভর করে ন্যূনতম সুবিধা, লগ এক্সপোজার এড়ানো, গোপনীয়তা ঘোরানো এবং নিরীক্ষণ করা এবং সংবেদনশীল উৎপাদন পরিবেশকে বিচ্ছিন্ন করার উপর।
- স্ক্রিপ্ট ইনজেকশন, থার্ড-পার্টি অ্যাকশন এবং সেলফ-হোস্টেড রানারদের ঝুঁকির জন্য পিনিং, কোড পর্যালোচনা এবং কঠোর রানার এবং অনুমতি নীতি প্রয়োজন।
- ওপেনআইডি কানেক্ট এবং বহিরাগত গোপন ব্যবস্থাপকরা দীর্ঘস্থায়ী শংসাপত্রগুলিকে স্বল্পস্থায়ী টোকেন এবং কেন্দ্রীভূত, নিরীক্ষণযোগ্য গোপন কর্মপ্রবাহ দিয়ে প্রতিস্থাপন করতে সহায়তা করে।
GitHub Actions-এ গোপনীয়তা ব্যবস্থাপনা এমন একটি বিষয় যা প্রথম নজরে সহজ মনে হলেও, যখন আপনার পাইপলাইনগুলি উৎপাদন, ক্লাউড প্রদানকারী এবং তৃতীয় পক্ষের পরিষেবাগুলিকে স্পর্শ করতে শুরু করে, তখন এটি দ্রুত একটি গুরুত্বপূর্ণ নিরাপত্তা উদ্বেগের বিষয় হয়ে ওঠে। আপনার CI/CD ওয়ার্কফ্লো নিয়মিতভাবে API কী, ডাটাবেস পাসওয়ার্ড, SSH কী, টোকেন এবং আরও অনেক কিছু নিয়ে কাজ করে এবং যদি অসাবধানতাবশত পরিচালনা করা হয় তবে এই প্রতিটি মান আক্রমণকারীর জন্য একটি সম্ভাব্য প্রবেশ বিন্দু হতে পারে।
এই নির্দেশিকায় আমরা GitHub Actions-এ গোপন তথ্য কীভাবে কাজ করে, সংগ্রহস্থল, পরিবেশ এবং সংগঠন পর্যায়ে কীভাবে সেগুলি কনফিগার করা যায়, লিক এবং সরবরাহ শৃঙ্খল আক্রমণের বিরুদ্ধে কীভাবে কর্মপ্রবাহকে কঠোর করা যায় এবং কখন বহিরাগত গোপন ব্যবস্থাপকদের আনা যুক্তিসঙ্গত হয় সে সম্পর্কে গভীরভাবে আলোচনা করব। ধারণাটি হল আপনাকে একটি ব্যবহারিক, নিরাপত্তা-কেন্দ্রিক ওভারভিউ দেওয়া যাতে আপনি আপনার পাইপলাইনগুলিকে দ্রুত রাখতে পারেন। এবং দৈনন্দিন কাজকে মাথাব্যথায় পরিণত না করে নিরাপদ।
গিটহাব অ্যাকশনের গোপন রহস্যগুলো আসলে কী?
গিটহাব অ্যাকশনে, একটি "সিক্রেট" হল একটি এনক্রিপ্ট করা পরিবেশ পরিবর্তনশীল যার মান UI, লগ এবং রিপোজিটরি কন্টেন্ট থেকে লুকানো থাকে। আপনি এটি একবার সংজ্ঞায়িত করুন (রেপো, অর্গ বা পরিবেশ স্তরে), এবং তারপর আপনার ওয়ার্কফ্লো YAML-এ এটি ব্যবহার করে উল্লেখ করুন secrets. context ব্যবহার করতে পারে, যাতে আপনার পাইপলাইনগুলি কোডবেসে কখনও কমিট না করেই সংবেদনশীল মান ব্যবহার করতে পারে।
গোপন তথ্যের আড়ালে, GitHub শক্তিশালী ক্রিপ্টোগ্রাফি (Libsodium সিল করা বাক্স) ব্যবহার করে গোপন তথ্য এনক্রিপ্ট করে, এমনকি GitHub-এর সার্ভারে পৌঁছানোর আগেই, এবং মানগুলি কেবল ওয়ার্কফ্লো রানারে রানটাইমে ডিক্রিপ্ট করা হয়। একবার তৈরি হয়ে গেলে, গোপনীয়তাগুলি UI থেকে অপরিবর্তনীয় থাকে: আপনি সেগুলি ওভাররাইট করতে পারেন কিন্তু আপনি সেগুলি আবার পড়তে পারবেন না, এবং যখন সেগুলি লগে উপস্থিত হয় তখন সেগুলি স্বয়ংক্রিয়ভাবে মুখোশযুক্ত হয়ে যায় *** যেখানে সম্ভব.
এই মডেলটিতে কিছু গুরুত্বপূর্ণ ডিজাইনের সীমাবদ্ধতা রয়েছে যা সম্পর্কে আপনার সচেতন থাকা প্রয়োজন: গোপন তথ্য UI বা API এর মাধ্যমে পুনরুদ্ধার করা যায় না, সেগুলি লগ থেকে মুছে ফেলা হয় এবং সেগুলি একটি নির্দিষ্ট স্কোপে থাকে: সংগ্রহস্থল, একটি সংগ্রহস্থলের মধ্যে পরিবেশ, অথবা প্রতিষ্ঠান। সঠিক সুযোগ নির্বাচন করা একটি সুস্থ গোপন কৌশলের জন্য প্রথম বড় সিদ্ধান্ত।
সংগ্রহস্থল, পরিবেশ এবং প্রতিষ্ঠানের গোপনীয়তা
গিটহাব গোপনীয়তার জন্য তিনটি প্রধান স্তর অফার করে: রিপোজিটরি গোপনীয়তা, পরিবেশ গোপনীয়তা এবং সংগঠন গোপনীয়তা, প্রতিটির নিজস্ব ব্যবহারের ক্ষেত্রে এবং অগ্রাধিকারের নিয়ম রয়েছে। তারা কীভাবে মিথস্ক্রিয়া করে তা বোঝা আপনাকে দ্বন্দ্ব এড়াতে এবং সংবেদনশীল মূল্যবোধগুলিকে তাদের প্রাসঙ্গিক স্থানে রাখতে সহায়তা করে।
সংগ্রহস্থল-স্তরের গোপনীয়তা
রিপোজিটরি সিক্রেটগুলি একটি একক রেপোর সাথে আবদ্ধ এবং সেই রিপোজিটরির সমস্ত কর্মপ্রবাহের জন্য উপলব্ধ। এগুলি প্রকল্প-নির্দিষ্ট মানগুলির জন্য উপযুক্ত, যেমন কোনও পরিষেবার API কী, একটি স্থাপনার পাসওয়ার্ড বা কেবল সেই রেপো দ্বারা ব্যবহৃত একটি ওয়েবহুক টোকেন।
UI থেকে একটি রিপোজিটরি সিক্রেট তৈরি করতে, আপনাকে টার্গেট রেপোতে যেতে হবে, "সেটিংস" → "সিক্রেটস অ্যান্ড ভ্যারিয়েবলস" → "অ্যাকশনস" খুলতে হবে, এবং তারপর "নতুন রিপোজিটরি সিক্রেট" এ ক্লিক করতে হবে। আপনি এটিকে আন্ডারস্কোর সহ একটি বড় হাতের নাম দিন (উদাহরণস্বরূপ PAYMENTS_API_KEY), গোপন মানটি পেস্ট করুন এবং সংরক্ষণ করুন; সেই মুহূর্ত থেকে, কর্মপ্রবাহগুলি এটিকে অ্যাক্সেস করতে পারবে ${{ secrets.PAYMENTS_API_KEY }}.
রেপোতে লেখার অ্যাক্সেস আছে এমন প্রত্যেকেই ওয়ার্কফ্লোতে এই গোপনীয়তাগুলি উল্লেখ করতে পারে, তাই রিপোজিটরির অনুমতিগুলি আপনার নিরাপত্তা গল্পের অংশ হয়ে ওঠে। যদি আপনি আকস্মিকভাবে অনেক ব্যবহারকারীকে লেখার অ্যাক্সেস দেন, তাহলে আপনি পরোক্ষভাবে তাদের অটোমেশনে প্রতিটি রিপোজিটরি সিক্রেট ব্যবহারের অ্যাক্সেস দিচ্ছেন।
পরিবেশ-নির্দিষ্ট গোপনীয়তা
পরিবেশ গোপনীয়তা রিপোজিটরি সিক্রেটসের এক স্তর নীচে অবস্থিত এবং আপনাকে প্রতি পরিবেশে বিভিন্ন মান সংজ্ঞায়িত করতে দেয় যেমন dev, staging, বা production. এগুলি একটি নামযুক্ত পরিবেশের সাথে সংযুক্ত থাকে এবং প্রয়োজনীয় পর্যালোচক বা অপেক্ষা টাইমারের মতো নিয়ম দিয়ে সুরক্ষিত করা যেতে পারে যাতে কোনও কাজ তাদের বিরুদ্ধে চলতে পারে।
আপনি "সেটিংস" → "পরিবেশ" এ গিয়ে, একটি পরিবেশ তৈরি বা নির্বাচন করে, এবং তারপর সেই পরিবেশ কনফিগারেশনের ভিতরে গোপনীয়তা যোগ করে এগুলি কনফিগার করতে পারেন। গোপন নামগুলি এখনও ব্যবহার করে secrets. প্রেক্ষাপট (উদাহরণস্বরূপ secrets.PROD_DB_PASSWORD), কিন্তু মানগুলি কেবলমাত্র সেই পরিবেশে স্পষ্টভাবে পরিচালিত চাকরির জন্য উপলব্ধ হয়।
একটি গুরুত্বপূর্ণ বিশদ হল যে পরিবেশগত গোপনীয়তাগুলি একই নাম ভাগ করলে রিপোজিটরি গোপনীয়তাগুলিকে ওভাররাইড করে। এর মানে হল আপনি সংজ্ঞায়িত করতে পারেন DB_PASSWORD স্থানীয়/পরীক্ষা ব্যবহারের জন্য রেপো স্তরে এবং তারপর একটি ভিন্ন DB_PASSWORD উৎপাদনের জন্য একটি পরিবেশগত গোপনীয়তা হিসেবে যা উৎপাদন কাজে প্রাধান্য পায়, কর্মপ্রবাহের বাক্য গঠন পরিবর্তন না করেই।
পরিবেশ "প্রয়োজনীয় পর্যালোচক" অথবা "শুধুমাত্র নির্দিষ্ট শাখা থেকে" এর মতো সুরক্ষা নিয়মগুলিকেও সক্ষম করে, যা আপনার সবচেয়ে সংবেদনশীল গোপনীয়তাগুলিতে অ্যাক্সেসের চারপাশে রেলিং স্থাপনের জন্য অবিশ্বাস্যভাবে কার্যকর। উদাহরণস্বরূপ, একটি উৎপাদন পরিবেশের গোপনীয়তা ব্যবহার করে কোনও কাজ চালানোর আগে DevOps-এর অনুমোদনের প্রয়োজন হতে পারে।
সংগঠন-ব্যাপী গোপনীয়তা
প্রতিষ্ঠানের গোপনীয়তা একটি প্রতিষ্ঠানের একাধিক সংগ্রহস্থলে ভাগ করা হয় এবং শেয়ার্ড স্ল্যাক ওয়েবহুক বা কেন্দ্রীয় মেট্রিক্স API টোকেনের মতো বিস্তৃতভাবে পুনঃব্যবহারযোগ্য শংসাপত্রের জন্য আদর্শ। এগুলো ডুপ্লিকেশন কমায় এবং ঘূর্ণন সহজ করে তোলে কারণ আপনি একবার সিক্রেট আপডেট করলে সমস্ত গ্রাহক রেপো নতুন মান গ্রহণ করে।
প্রশাসকরা প্রতিষ্ঠানের "সেটিংস" → "গোপনীয়তা এবং ভেরিয়েবল" → "ক্রিয়াকলাপ" বিভাগে এগুলি তৈরি করে, "নতুন প্রতিষ্ঠানের গোপনীয়তা" এ ক্লিক করে এবং তারপর কোন সংগ্রহস্থলগুলি সেই গোপনীয়তা অ্যাক্সেস করতে পারে তা বেছে নেয়। আপনি সমস্ত বর্তমান এবং ভবিষ্যতের রিপোগুলিকে অনুমতি দিতে পারেন অথবা এটিকে একটি নির্দিষ্ট উপসেটে সীমাবদ্ধ রাখতে পারেন।
একটি অগ্রাধিকার শৃঙ্খল আছে যা আপনার মনে রাখা উচিত: organization secret repository secret < environment secret when names collapse. অন্য কথায়, একটি পরিবেশগত গোপনীয়তা একটি সংগ্রহস্থলের গোপনীয়তার উপর জয়লাভ করে, যা একটি প্রতিষ্ঠানের গোপনীয়তার উপর জয়লাভ করে যদি তারা সকলেই একই কী ভাগ করে নেয়।
রানটাইমে সিক্রেটস কীভাবে আচরণ করে
একবার সংজ্ঞায়িত হয়ে গেলে, রানটাইমের মাধ্যমে চাকরির জন্য গোপনীয়তা উপলব্ধ হয়ে যায় secrets প্রসঙ্গ এবং রেফারেন্স করা হলে পরিবেশের ভেরিয়েবল হিসেবে ইনজেক্ট করা হয়। ডিফল্টরূপে এগুলি প্রতিটি ধাপে বিস্তৃতভাবে রপ্তানি করা হয় না; আপনি স্পষ্টভাবে এগুলিকে আপনার env: গোপন তথ্যকে ইনপুট হিসেবে সমর্থন করে এমন ক্রিয়ায় ব্লক করে বা প্রেরণ করে।
GitHub একটি বিশেষ প্রদান করে GITHUB_TOKEN প্রতি ওয়ার্কফ্লো রান, যা ম্যানুয়ালি সংজ্ঞায়িত গোপনীয়তা নয় কিন্তু এটির মতো আচরণ করে এবং প্রায়শই API কল বা সংগ্রহস্থল ক্রিয়াকলাপের জন্য ব্যবহৃত হয়। আপনি এই টোকেনের সূক্ষ্ম অনুমতিগুলি ব্যবহার করে সুরক্ষিত করতে পারেন (এবং করা উচিত) permissions: ব্লক করুন যাতে প্রতিটি কাজের জন্য প্রয়োজনীয় ন্যূনতম সুযোগ থাকে।
দুর্ঘটনাজনিত এক্সপোজার কমাতে, GitHub ওয়ার্কফ্লো লগে নিবন্ধিত গোপনীয়তার সাথে মেলে এমন যেকোনো মান মাস্ক করে, এটি দিয়ে প্রতিস্থাপন করে ***. এই মাস্কিংটি রানার সাইডে করা হয়, এবং এটি সাধারণত কাঁচা স্ট্রিংগুলির জন্য ভাল কাজ করে, তবে এটি ধরে নেয় যে আউটপুটে সঠিক গোপন মান প্রদর্শিত হবে। যদি আপনি গোপনটি রূপান্তর করেন (উদাহরণস্বরূপ base64-এ এটি এনকোড করুন বা স্ট্রাকচার্ড JSON-এ এম্বেড করুন), তাহলে মাস্কটি এটি ধরতে ব্যর্থ হতে পারে।
যেহেতু মাস্কিং সবচেয়ে ভালো প্রচেষ্টা এবং গাণিতিকভাবে নিশ্চিত নয়, তাই আপনার এমনভাবে ওয়ার্কফ্লো ডিজাইন করা উচিত যাতে গোপন তথ্য বা তাদের ডেরিভেটিভগুলি লগে মুদ্রণ করা একেবারেই এড়ানো যায় এবং রানটাইমে আপনার তৈরি করা অতিরিক্ত মানগুলির জন্য মাস্কিং কমান্ড ব্যবহার করা উচিত। লগগুলিকে আপনার প্রত্যাশার চেয়ে বেশি লোকের কাছে দৃশ্যমান বলে মনে করুন এবং ধরে নিন যে মুদ্রিত যেকোনো কিছু ফাঁস হতে পারে।
ব্যবহারিক ব্যবহার: কর্মপ্রবাহে গোপনীয়তা উল্লেখ করা
বেশিরভাগ সময় আপনি গোপন তথ্যগুলিকে একটি নির্দিষ্ট ধাপ বা কাজে পরিবেশের ভেরিয়েবলের সাথে ম্যাপ করে ব্যবহার করবেন এবং তারপর আপনার স্ক্রিপ্ট বা সরঞ্জামগুলিকে পরিবেশ থেকে পড়তে দেবেন। একটি ক্লাসিক প্যাটার্ন এইরকম দেখাচ্ছে:
– নাম: API-তে স্থাপন করুন
env:
API_KEY: ${{ গোপনীয়তা.PROD_API_KEY }}
রান: |
curl -H “অনুমোদন: বাহক $API_KEY” https://api.example.com/deploy
আপনি রানারে একটি ফাইলে একটি গোপনীয়তাও লিখতে পারেন, যা ততক্ষণ পর্যন্ত নিরাপদ থাকে যতক্ষণ না ফাইলটি কাজের ক্ষণস্থায়ী কর্মক্ষেত্রের মধ্যে থাকে এবং একটি শিল্পকর্ম হিসাবে প্রতিশ্রুতিবদ্ধ বা আপলোড করা না হয়। উদাহরণস্বরূপ, একটি SSH কী সংরক্ষণ করা:
– নাম: ফাইলে SSH কী লিখুন
শেল: ব্যাশ
env:
SSH_KEY: ${{ গোপনীয়তা.SSH_KEY }}
রান: |
"$SSH_KEY" > কী প্রতিধ্বনি করুন
chmod 600 কী
লগগুলি থেকে আপনি কেবল আসল শেল কমান্ডটি দেখতে পাবেন (সঙ্গে $SSH_KEY), কিন্তু গোপন মানটি নয়, যা সম্পাদনা করা হবে বা লুকানো হবে। যেহেতু কাজ শেষ হওয়ার পরে GitHub-হোস্টেড রানারগুলি ধ্বংস হয়ে যায়, সেই অস্থায়ী ফাইলটি VM-এর সাথে অদৃশ্য হয়ে যায়; স্ব-হোস্টেড রানারদের ক্ষেত্রে আপনাকে পরিষ্কার করার বিষয়ে আরও কঠোর হতে হবে।
GitHub অ্যাকশনে গোপন তথ্যের জন্য নিরাপত্তার সর্বোত্তম অনুশীলন
শুধু সিক্রেট UI ব্যবহার করা যথেষ্ট নয়; কিছু ভুল হলে বিস্ফোরণের ব্যাসার্ধ কমানোর জন্য আপনার কিছু অভ্যাস এবং সুরক্ষা ব্যবস্থার প্রয়োজন। গিটহাবে অনেক নব আছে, কিন্তু সেগুলো সঠিকভাবে চালু করা আপনার ব্যাপার।
ন্যূনতম সুযোগ-সুবিধার নীতি প্রয়োগ করুন
প্রতিটি গোপন তথ্য এবং প্রতিটি টোকেন কেবলমাত্র সেইসব অনুমতি প্রদান করবে যা একটি নির্দিষ্ট কাজের জন্য একেবারে প্রয়োজনীয়। বহিরাগত পরিষেবার জন্য, পূর্ণ-অ্যাডমিন কী পুনঃব্যবহার করার পরিবর্তে স্কোপড অনুমতি (উদাহরণস্বরূপ "শুধুমাত্র স্থাপন করুন" বা "শুধুমাত্র পঠনযোগ্য মেট্রিক্স") সহ ডেডিকেটেড শংসাপত্র তৈরি করুন।
একই নীতি বিল্ট-ইনের ক্ষেত্রেও প্রযোজ্য GITHUB_TOKEN; ডিফল্ট অনুমতিগুলি সর্বনিম্ন (প্রায়শই) সেট করুন contents: read) এবং তারপর শুধুমাত্র নির্দিষ্ট কাজের জন্য অনুমতি বাড়াতে হবে যেগুলির আরও বেশি প্রয়োজন। আপনি এটি একটি দিয়ে কনফিগার করুন permissions: কর্মপ্রবাহ বা কাজের স্তরে বিভাগটি যাতে কোনও আপোসপ্রাপ্ত কাজ নীরবে ইচ্ছামত লেখা না করতে পারে।
লগে গোপন তথ্য মুদ্রণ বা এনকোড করা এড়িয়ে চলুন
ডিবাগিং সুবিধার জন্য গোপন তথ্য কখনই ওয়ার্কফ্লো ফাইলে হার্ডকোড করা উচিত নয় বা প্লেইন টেক্সটে মুদ্রিত করা উচিত নয়। যদি আপনার কাছে এমন অন্যান্য সংবেদনশীল মান থাকে যা GitHub সিক্রেটস হিসেবে নিবন্ধিত না থাকে (উদাহরণস্বরূপ, রানটাইমে তৈরি হওয়া একটি টোকেন), তাহলেও আপনি রানারকে কমান্ড সিনট্যাক্স ব্যবহার করে সেগুলিকে সিক্রেটস হিসেবে বিবেচনা করতে বলতে পারেন:
"::add-mask::$GENERATED_TOKEN" প্রতিধ্বনি করুন
JSON, XML বা বৃহৎ YAML ডকুমেন্টের মতো স্ট্রাকচার্ড ব্লবগুলি গোপনীয়তা হিসাবে বিশেষভাবে বিপজ্জনক কারণ GitHub এর মাস্কার সঠিক স্ট্রিং ম্যাচিংয়ের উপর নির্ভর করে। যদি আপনি একটি বৃহৎ JSON স্ট্রিং-এর ভিতরে একাধিক সংবেদনশীল মান রাখেন এবং সেটিকে একটি গোপনীয়তা হিসেবে ব্যবহার করেন, তাহলে সামান্য ফর্ম্যাটিং পরিবর্তনের ফলে মাস্কিং ব্যর্থ হতে পারে; পরিবর্তে, প্রতিটি সূক্ষ্ম ক্ষেত্রের জন্য পৃথক গোপনীয়তা নির্ধারণ করুন।
কর্মপ্রবাহ পরীক্ষা করার সময় সর্বদা লগগুলি পর্যালোচনা করুন, ত্রুটি বার্তা এবং স্ট্যাক ট্রেসের দিকে বিশেষ মনোযোগ দিন। কিছু টুল আনন্দের সাথে stderr-এ কমান্ড এবং ফ্ল্যাগ প্রতিধ্বনিত করে, যা দুর্ঘটনাক্রমে গোপন মান অন্তর্ভুক্ত করতে পারে যদি না আপনি স্পষ্টভাবে সেই প্যাটার্নটি এড়িয়ে যান।
নিয়মিত গোপন তথ্য ঘোরান এবং নিরীক্ষণ করুন
গোপনে পরিবর্তন আনা ক্লান্তিকর, কিন্তু নিরাপত্তার কথা চিন্তা করলে তা নিয়ে আলোচনা করা যায় না; বছরের পর বছর ধরে তথ্য অপরিবর্তিত রাখলে আক্রমণকারীদের জন্য সুযোগের দ্বার বৃদ্ধি পায়। একটি যুক্তিসঙ্গত ভিত্তি হল আপনার সবচেয়ে গুরুত্বপূর্ণ উৎপাদন গোপনীয়তাগুলি প্রতি মাসে, উচ্চ-ঝুঁকিপূর্ণ গোপনীয়তাগুলি প্রতি কয়েক মাস অন্তর এবং বাকি সবকিছু কমপক্ষে ত্রৈমাসিকভাবে পরিবর্তন করা।
আপনি গোপনীয়তার জন্য GitHub REST API ব্যবহার করে এর কিছু অংশ স্বয়ংক্রিয় করতে পারেন, যা আপনাকে একটি সংগ্রহস্থল বা সংস্থার পাবলিক কী আনতে এবং নতুন এনক্রিপ্ট করা মান আপলোড করতে দেয়। এটি বিশেষ করে বৃহৎ প্রতিষ্ঠানগুলির জন্য কার্যকর যেখানে অনেক রিপো থাকে এবং যারা পরিষেবা অ্যাকাউন্ট শেয়ার করে এবং ঘটনার প্রতিক্রিয়ায় দ্রুত সেগুলি পরিবর্তন করতে হয়।
নিরীক্ষণও সমানভাবে গুরুত্বপূর্ণ: পর্যায়ক্রমে কনফিগার করা গোপনীয়তার তালিকা পর্যালোচনা করুন এবং যেগুলি আর ব্যবহার করা হয় না সেগুলি মুছে ফেলুন, এবং GitHub-এর নিরাপত্তা/অডিট লগ ব্যবহার করে ইভেন্টগুলি ট্র্যাক করুন যেমন org.update_actions_secret. এইভাবে আপনি জানতে পারবেন কে কখন কী পরিবর্তন করেছে, এবং আপনি সন্দেহজনক পরিবর্তনগুলিকে অন্যান্য কার্যকলাপের সাথে সম্পর্কিত করতে পারবেন।
পরিবেশ-ভিত্তিক পৃথকীকরণ ব্যবহার করুন
পরিবেশগত গোপনীয়তা হল আপনার পাইপলাইনগুলিকে শক্ত করার সবচেয়ে সহজ উপায়গুলির মধ্যে একটি, কারণ তারা আপনাকে স্পষ্ট অনুমোদনের পিছনে অত্যন্ত সংবেদনশীল মানগুলি (যেমন উৎপাদন ডিবি শংসাপত্র) আলাদা করতে দেয়। আপনি মানব পর্যালোচকদের প্রয়োজন করতে পারেন, কোন শাখাগুলি স্থাপন করা যাবে তা সীমাবদ্ধ করতে পারেন, এমনকি স্থাপন শুরু হওয়ার আগে কুলিং-অফ টাইমারও যোগ করতে পারেন।
একটি সাধারণ ধরণ হল একটি staging হালকা সুরক্ষা ব্যবস্থা সহ পরিবেশ এবং একটি production কঠোর নিয়ম এবং পৃথক গোপনীয়তা সহ পরিবেশ। কর্মপ্রবাহগুলি তখন প্রতিটি পরিবেশকে লক্ষ্য করে এমন কাজগুলিকে সংজ্ঞায়িত করে, নিশ্চিত করে যে প্রোড সিক্রেটগুলি কখনই পরীক্ষার কাজে দুর্ঘটনাক্রমে ব্যবহার করা হয় না।
স্পষ্ট নামকরণের রীতিনীতি বেছে নিন
গোপনীয়তার জন্য ভালো নামকরণ আপনাকে হতাশাজনক অনুমান এবং বিপজ্জনক জটিলতা থেকে রক্ষা করে। সাধারণ নামের পরিবর্তে যেমন API_KEY, নামের মধ্যে পরিষেবা এবং পরিবেশ এনকোড করুন, উদাহরণস্বরূপ STRIPE_PROD_API_KEY or AWS_STAGING_DEPLOY_ROLE_ARN.
অনেক পরিষেবা নিয়ে কাজ করা দলগুলি প্রায়শই একটি প্যাটার্ন গ্রহণ করে যেমন <SERVICE>_<ENV>_<PURPOSE>. তাহলে তোমার থাকতে পারে SLACK_PROD_ALERTS_WEBHOOK, GCP_DEV_BUILD_SERVICE_ACCOUNT, এবং DB_STAGING_PASSWORD। এর ফলে কোন গোপন কথাটি কোন কাজে ব্যবহার করা উচিত তা আরও স্পষ্ট হয়ে ওঠে।
স্ক্রিপ্ট ইনজেকশন এবং তৃতীয় পক্ষের ঝুঁকি থেকে রক্ষা করা
গোপন তথ্যগুলি কেবল ভুল কনফিগারেশনের ঝুঁকিতে থাকে না; তারা কর্মপ্রবাহে স্ক্রিপ্ট ইনজেকশন এবং দূষিত বা আপোস করা তৃতীয় পক্ষের ক্রিয়াকলাপের জন্যও প্রলুব্ধকর লক্ষ্যবস্তু। সতর্ক না থাকলে, একটি দুর্বল পদক্ষেপ কাজের সাথে সম্পর্কিত প্রতিটি গোপন তথ্য ফাঁস করে দিতে পারে।
ইনলাইন ধাপে স্ক্রিপ্ট ইনজেকশন কমানো
যখন আপনি অবিশ্বস্ত ডেটা (যেমন পুল রিকোয়েস্ট টাইটেল, ব্রাঞ্চের নাম বা ইস্যু মন্তব্য) সরাসরি শেল স্ক্রিপ্টে ইন্টারপোলেট করেন, তখন আপনি ইনজেকশনের দরজা খুলে দেন। উদাহরণস্বরূপ, একটি পিআর শিরোনাম তৈরি করা যেতে পারে যাতে একটি কমান্ড ভেঙে আপনার রানারে ইচ্ছামত শেল কোড চালানো যায়।
সবচেয়ে নিরাপদ পদ্ধতি হল ফার্স্ট-পার্টি বা সু-নিরীক্ষিত জাভাস্ক্রিপ্ট/টাইপস্ক্রিপ্ট অ্যাকশনে জটিল লজিক পরিচালনা করা এবং অবিশ্বস্ত মানগুলিকে শেলে ইনলাইন করার পরিবর্তে ইনপুট হিসাবে পাস করা। এই মডেলে, অ্যাকশনটি স্ট্রিংগুলিকে আর্গুমেন্ট হিসেবে গ্রহণ করে এবং হাইজ্যাক করা যেতে পারে এমন শেল স্ক্রিপ্ট তৈরি না করেই সেগুলিকে প্রক্রিয়া করে।
যদি আপনাকে ইনলাইন শেল ব্যবহার করতেই হয়, তাহলে প্রথমে পরিবেশ ভেরিয়েবলে অবিশ্বস্ত মান সংরক্ষণ করুন এবং তারপর সেই ভেরিয়েবলগুলিকে উল্লেখ করুন, বিশেষ করে ডাবল কোটের মধ্যে। এইভাবে মানটিকে স্ক্রিপ্ট কাঠামোর অংশ হিসেবে না দেখে ডেটা হিসেবে বিবেচনা করা হয়, যার ফলে ইনজেকশন প্রচেষ্টা সফল হওয়ার সম্ভাবনা অনেক কম হয়ে যায়।
তৃতীয় পক্ষের অ্যাকশনগুলি পিন করুন এবং পর্যালোচনা করুন
আপনার কর্মপ্রবাহে আপনার নেওয়া প্রতিটি তৃতীয় পক্ষের পদক্ষেপ কাজের পরিবেশ এবং গোপনীয়তাগুলিতে অ্যাক্সেস সহকারে চলে, তাই আপনার এগুলিকে কোড নির্ভরতা হিসাবে বিবেচনা করা উচিত যার জন্য তদন্ত প্রয়োজন। একটি দূষিত বা আপোষিত পদক্ষেপ গোপন তথ্য পড়তে পারে এবং একটি HTTP কলের মাধ্যমে আক্রমণকারীর কাছে পাঠাতে পারে।
ট্যাগ বা শাখার পরিবর্তে সম্পূর্ণ কমিট SHA দ্বারা অ্যাকশন পিন করাই সবচেয়ে ভালো অভ্যাস, কারণ ট্যাগগুলি সরানো বা ওভাররাইট করা যেতে পারে। একটি SHA কোডের একটি সঠিক সংস্করণকে বোঝায়, যার ফলে আক্রমণকারীর পক্ষে কর্মপ্রবাহ আপডেট না করেই নীরবে নতুন আচরণ ইনজেক্ট করা অনেক কঠিন হয়ে পড়ে।
কোনও অ্যাকশন ব্যবহার করার আগে, এর সোর্স কোড (অথবা অন্তত একটি নিরাপত্তা পর্যালোচনা) স্কিম করে নিশ্চিত করুন যে এটি দায়িত্বের সাথে গোপনীয়তা পরিচালনা করে এবং সেগুলি লগ করে না বা অজানা এন্ডপয়েন্টে পাঠায় না। যদি আপনি মার্কেটপ্লেস অ্যাকশন ব্যবহার করেন, তাহলে সম্ভব হলে প্রকাশককে যাচাই করুন এবং দুর্বলতা এবং আপডেট সম্পর্কে সতর্ক করার জন্য Dependabot-এর উপর নির্ভর করুন।
হোস্টেড বনাম স্ব-হোস্টেড রানার এবং গোপন এক্সপোজার
আপনার কর্মপ্রবাহ কোথায় চলে তা গোপনীয়তা কতটা নিরাপদে পরিচালনা করা হয় তার উপর বিশাল প্রভাব ফেলে। গিটহাব-হোস্টেড রানার এবং সেলফ-হোস্টেড রানাররা বিচ্ছিন্নতা এবং স্থায়িত্বের দিক থেকে খুব আলাদা আচরণ করে।
গিটহাব-হোস্টেড রানাররা প্রতিটি কাজের জন্য নতুন ভার্চুয়াল মেশিন তৈরি করে, আপনার কর্মপ্রবাহ চালায় এবং তারপর সেগুলি ভেঙে ফেলে। এটি আপনাকে প্রতিবার একটি পরিষ্কার পরিবেশ দেয় এবং নিশ্চিত করে যে কাজটি সম্পন্ন হওয়ার পরে যেকোনো ফাইল বা পরিবেশের ভেরিয়েবল (ডিস্কে লেখা গোপনীয়তা সহ) ধ্বংস হয়ে যায়।
বিপরীতে, স্ব-হোস্টেড রানাররা হল দীর্ঘস্থায়ী মেশিন যা আপনি পরিচালনা করেন, যার অর্থ গোপন তথ্য অ্যাক্সেস সহ যেকোনো কোড সম্ভাব্যভাবে একটি একক কাজের জীবনের পরেও সেগুলি টিকে থাকতে বা নির্গত করতে পারে। পাবলিক রিপোজিটরিগুলিতে, স্ব-হোস্টেড রানাররা বিশেষভাবে ঝুঁকিপূর্ণ কারণ অবিশ্বস্ত অবদানকারীরা পুল রিকোয়েস্ট খুলতে পারে যা কর্মপ্রবাহকে ট্রিগার করে।
যদি আপনি স্ব-হোস্টেড রানার ব্যবহার করেন, তাহলে সংবেদনশীলতা স্তর অনুসারে তাদের আলাদা করুন, কোন রেপো কোন রানার ব্যবহার করতে পারে তা সীমাবদ্ধ করুন এবং সেই মেশিনগুলিতে আর কী থাকে (SSH কী, ক্লাউড শংসাপত্র, অভ্যন্তরীণ পরিষেবাগুলিতে নেটওয়ার্ক অ্যাক্সেস ইত্যাদি) সে সম্পর্কে ভীত থাকুন। কিছু প্রতিষ্ঠান "just-in-time" (JIT) স্ব-হোস্টেড রানার ব্যবহার করে যা API এর মাধ্যমে একটি কাজের জন্য তৈরি করা হয় এবং তারপর ধ্বংস করা হয়, কিন্তু তারপরেও আপনাকে নিশ্চিত করতে হবে যে কাজগুলি একই রানারকে অপ্রত্যাশিতভাবে ভাগ করে না নেয়।
দীর্ঘস্থায়ী ক্লাউড সিক্রেটের পরিবর্তে OpenID Connect (OIDC) ব্যবহার করা
GitHub Actions-এ গোপন স্বাস্থ্যবিধির ক্ষেত্রে সবচেয়ে বড় জয়গুলির মধ্যে একটি হল OpenID Connect-এর মাধ্যমে দীর্ঘস্থায়ী ক্লাউড অ্যাক্সেস কীগুলিকে স্বল্পস্থায়ী শংসাপত্র দিয়ে প্রতিস্থাপন করা। AWS, Azure বা GCP কীগুলিকে গোপন হিসেবে সংরক্ষণ করার পরিবর্তে, আপনার কর্মপ্রবাহগুলি GitHub-কে পরিচয় প্রদানকারী হিসেবে ব্যবহার করে ক্লাউড প্রদানকারীর কাছ থেকে অস্থায়ী টোকেনের অনুরোধ করে।
প্রবাহটি মোটামুটি এইরকম দেখাচ্ছে: কাজটি GitHub-এর OIDC এন্ডপয়েন্ট থেকে একটি স্বাক্ষরিত JWT অনুরোধ করে, আপনার ক্লাউড প্রদানকারী সেই টোকেনটি যাচাই করে এবং স্বল্পস্থায়ী শংসাপত্রের জন্য বিনিময় করে, এবং কর্মপ্রবাহ কাজের সময়কালের জন্য সেই শংসাপত্রগুলি ব্যবহার করে। কোনও স্থির গোপনীয়তা কখনও GitHub-এ থাকার প্রয়োজন হয় না।
উদাহরণস্বরূপ, AWS এর মাধ্যমে আপনি একটি IAM ভূমিকা কনফিগার করেন যা GitHub OIDC প্রদানকারীর উপর বিশ্বাস রাখে এবং কোন সংগ্রহস্থল/শাখাগুলি সেই ভূমিকা গ্রহণ করতে পারে তা সীমাবদ্ধ করে। তারপর আপনার কর্মপ্রবাহে আপনি একটি ক্রিয়া ব্যবহার করেন যেমন aws-actions/configure-aws-credentials OIDC অনুমতির মাধ্যমে তাৎক্ষণিকভাবে শংসাপত্র প্রাপ্ত করা সম্ভব।
এই পদ্ধতির একাধিক সুবিধা রয়েছে: GitHub-এর ভিতরে ঘোরানোর মতো কিছুই নেই, টোকেনগুলি স্বয়ংক্রিয়ভাবে স্বল্পস্থায়ী হয়, অ্যাক্সেসের সুযোগ সীমিত হয় এবং আপনি ক্লাউড সাইডে প্রতিটি ভূমিকা অনুমান ট্র্যাক করে সম্পূর্ণ অডিট লগ পান। উচ্চ-নিরাপত্তা পরিবেশের জন্য, সমর্থিত স্থানে OIDC ডিফল্ট হওয়া উচিত।
নেটিভ টুলিং এবং বহিরাগত গোপন ব্যবস্থাপক
GitHub-এর অন্তর্নির্মিত গোপনীয়তা অনেক পরিস্থিতিতেই দুর্দান্ত, তবে এক পর্যায়ে আপনি আরও কেন্দ্রীয়, বৈশিষ্ট্য সমৃদ্ধ গোপন ব্যবস্থাপক চাইতে পারেন যা একাধিক প্ল্যাটফর্ম এবং পরিবেশে বিস্তৃত। এই উদ্দেশ্যে GitHub Actions-এর পাশাপাশি HashiCorp Vault, Infisical বা Doppler-এর মতো টুলগুলি প্রায়শই ব্যবহার করা হয়।
এই সিস্টেমগুলি গতিশীল গোপনীয়তা (উদাহরণস্বরূপ, স্বল্পস্থায়ী ডাটাবেস ব্যবহারকারী তৈরি করা), উন্নত অ্যাক্সেস নিয়ন্ত্রণ নীতি, বিস্তারিত অডিট লগ এবং ঘূর্ণন কর্মপ্রবাহ পরিচালনা করতে পারে যা কেবল GitHub-এর অফারগুলির বাইরেও যায়। এরপর GitHub Actions এই পরিচালকদের কাছে প্রমাণীকরণ করে (প্রায়শই OIDC বা অন্য কোনও প্রমাণীকরণ পদ্ধতির মাধ্যমে), রানটাইমে তাদের প্রয়োজনীয় গোপনীয়তাগুলি নিয়ে আসে এবং রেপোতে দীর্ঘমেয়াদী শংসাপত্র সংরক্ষণ না করেই সেগুলি ব্যবহার করে।
এছাড়াও এমন কমিউনিটি অ্যাকশন এবং প্লাগইন রয়েছে যা বহিরাগত পরিচালকদের কাছ থেকে গোপন তথ্য সরাসরি কর্মপ্রবাহে টেনে আনার জন্য ডিজাইন করা হয়েছে। এগুলি ব্যবহার করার সময়, একই পরামর্শ প্রযোজ্য: অ্যাকশনের উৎস পর্যালোচনা করুন, এটিকে একটি কমিট SHA-তে পিন করুন এবং বহিরাগত সিস্টেমে পৌঁছানোর জন্য এটি যে টোকেন বা ভূমিকা ব্যবহার করে তাতে প্রদত্ত সুযোগ-সুবিধা সীমিত করুন।
GitHub Actions-এ নিরাপদ গোপন ব্যবস্থাপনার অর্থ হল প্রতিটি গোপনীয়তার জন্য সঠিক সুযোগ বেছে নেওয়া, ন্যূনতম বিশেষাধিকার প্রয়োগ করা, উপযুক্ত স্থানে পরিবেশ এবং OIDC ব্যবহার করা, লগ এবং তৃতীয় পক্ষের ক্রিয়াকলাপগুলিকে সম্ভাব্য আক্রমণাত্মক পৃষ্ঠ হিসাবে বিবেচনা করা এবং যখন আপনার স্কেল বা সম্মতির প্রয়োজনীয়তাগুলি এটির দাবি করে তখন বহিরাগত গোপন পরিচালকদের উপর নির্ভর করা। এই পদ্ধতিগুলি কার্যকর থাকলে, আপনার CI/CD পাইপলাইনগুলি নমনীয় এবং দ্রুত থাকতে পারে এবং একই সাথে একটি ভুল টোকেন বা খারাপভাবে পর্যালোচনা করা কর্মপ্রবাহ সম্পূর্ণরূপে বিকশিত ঘটনায় পরিণত হওয়ার সম্ভাবনা নাটকীয়ভাবে হ্রাস করে।
