Securing CI/CD for Open Source: Credentials and Verification in Kubernetes
In open source projects, securing your CI/CD pipeline is critical to prevent unauthorized access and ensure the integrity of your software. With the rise of supply chain attacks, implementing robust security measures is no longer optional. This article focuses on how to manage credentials and verification processes effectively within a Kubernetes environment, emphasizing the importance of using GITHUB_TOKENs and signing container images.
The mechanism begins with the use of GITHUB_TOKENs, which by default are scoped to minimal read permissions on contents and packages. This limits exposure and reduces the risk of credential leakage. Additionally, you can manage two distinct sets of registry credentials behind separate GitHub protected environments. CI credentials can push to your development image registry, while production credentials require explicit maintainer approval before use. This layered approach ensures that sensitive operations are tightly controlled. Moreover, every actions/checkout call sets persist-credentials: false, preventing the GITHUB_TOKEN from being stored in the runner’s git config, which could lead to accidental leaks.
In production, integrating tools like Sigstore Cosign is essential. Every container image released is signed using keyless OIDC, providing an extra layer of verification. Additionally, a Software Bill of Materials (SBOM) is generated for each container image, which helps in tracking dependencies and vulnerabilities. Implementing DCO sign-off enforcement ensures that every commit carries a Signed-off-by line, further solidifying the integrity of your codebase. Be aware of the specific versions you are using; for instance, the Cosign installer is at v4.1.1 and the SBOM action at v0.24.0, which are crucial for compatibility and security enhancements.
Key takeaways
- →Utilize GITHUB_TOKENs with minimal read permissions to limit exposure.
- →Manage CI and production credentials in separate GitHub protected environments.
- →Sign container images with Sigstore Cosign using keyless OIDC for enhanced security.
- →Generate SBOMs for container images to track dependencies and vulnerabilities.
- →Enforce DCO sign-off to ensure every commit is verified.
Why it matters
In production, a compromised CI/CD pipeline can lead to significant security breaches. By implementing these practices, you protect your project from potential supply chain attacks and maintain trust with your users.
Code examples
- name: Install Cosign
uses: sigstore/cosign-installer@cad07c2e89fa2edd6e2d7bab4c1aa38e53f76003 # v4.1.11- name: Generate SBOM
2 uses: anchore/sbom-action@e22c389904149dbc22b58101806040fa8d37a610 # v0.24.0
3 with:
4 artifact-name: sbom_${{ inputs.sbom_name }}.spdx.json
5 output-file: ./sbom_${{ inputs.sbom_name }}.spdx.json
6 image: ${{ inputs.image_tag }}- name: Sign Container Image
shell: bash
run: cosign sign -y "${{ inputs.image }}"When NOT to use this
The official docs don't call out specific anti-patterns here. Use your judgment based on your scale and requirements.
Want the complete reference?
Read official docsIndustry-standard certifications built by the people behind Linux and Kubernetes. Earn the CKA — the gold standard Kubernetes administrator cert. OpsCanary readers get 30% off year-round with code OPSCANARY3.
Get CKA certified →KubeletInUserNamespace: Elevating Security in Kubernetes v1.37
Kubernetes v1.37 takes a significant step in security by promoting the KubeletInUserNamespace feature gate to beta. This feature allows node components to run as non-root users, reducing the risk of potential damage. Discover how this works and what you need to know for production.
Kubernetes v1.37: Mastering Pod Certificates and Cluster Trust Bundles
Kubernetes v1.37 introduces Pod Certificates and Cluster Trust Bundles, revolutionizing how you manage identity and trust in your clusters. With built-in X.509 certificate issuance, you can streamline TLS and mTLS for your workloads. Dive into the mechanics and production realities of this powerful feature.
Break-Glass Access for EKS: Your Emergency Lifeline
When federated identity systems fail, you need a reliable backup. Break-glass access for Amazon EKS provides an emergency path that requires no external identity system, ensuring you can regain control when it matters most.
Get the daily digest
One email. 5 articles. Every morning.
No spam. Unsubscribe anytime.