Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hardening and Security Tracker #8738

Open
7 of 31 tasks
PrivatePuffin opened this issue May 3, 2023 · 0 comments
Open
7 of 31 tasks

Hardening and Security Tracker #8738

PrivatePuffin opened this issue May 3, 2023 · 0 comments
Labels
enhancement New feature or request

Comments

@PrivatePuffin
Copy link
Member

PrivatePuffin commented May 3, 2023

This issue tracks the steps we can take to increase security of our project.
It's mostly supplied as a way to inform users that we're aware improvements could be made and is not intended as a discussion platform (please use the dev channel on discord for that)

  • Add signing of Helm Charts (lowers MITM/spoofing supply-chain attack-surface)
  • Add signing of docker images (lowers MITM/spoofing supply-chain attack-surface)
  • Ensure provenance generation for Helm Charts
  • Add automatic SBOM generation to docker build process (using syft for example, ensures SLSA L1 compliance)
  • Add provenance generation to docker build process (ensures SLSA L1 compliance))
  • Validate helm dependency signatures in chart testing pipeline
  • Move bot to user with less privileges (decreases the scope when the bot gets compromised)
  • Move org-wide admin access to dedicated account (decreases the scope when maintainers get compromised)
  • Validate container signatures in chart testing pipeline
  • Validate container signatures prior to SCALE catalog release in CI
  • Move helm deps train to immutable repo
  • Validate helm dependency signatures prior in catalog repo staging
  • Validate helm dependency signatures in helm-staging repo staging
  • Add copyright header to all files (lower potential copyright issues)
  • Move more complicated charts to use our BSL license (prevents other projects/iX rebranding)
  • Publish common helm security scan results on website (ensures users are informed on security practices)
  • Publish common container security scan results on website (ensures users are informed on security practices)
  • Write guides to help users setup signed commits (enables us to enforced signed commits in the future)
  • Move to enforcing signed commits (decreases the chance of contributor spoofing injecting bad-actor code)
  • host our own github actions instead of relying on upstreams (lowers potential supply-chain attack surface)
  • Add mandatory basic security scanning prior to publication (to prevent bad code making it to releases)
  • Move away from manifest manager where we can (directly loading code from the internet is a security risk)
  • Move signing/release pipelines to private repositories (prevents chances of key leakage)
  • Add virus scanning to container build pipeline where possible
  • Add automatic SBOM generation to Helm charts themselves (ensures SLSA L1 compliance))
  • Remove dependency on bitnami helm charts as they are unsigned (so we can enforce signature on deps)
  • Move Helm Registry to OCI registry, under main "truecharts" account
  • Remove docker containers from main quay account "truecharts"
  • Move Container Base images to different OCI account (tccrbase)
  • Move Container mirror to different OCI account (tccrmirror)
  • Move Container non-mirror (self-build) to different OCI account (tccr)

For provenance and SBOM for docker images see:
https://marcofranssen.nl/secure-your-software-supply-chain-using-sigstore-and-github-actions

Proposed flow:

  • PR commits (signed)
  • Tests verify signature of both dependencies and containers
  • 1 (preferably 2) reviews for non-automatic PR's from users with Write but not Admin access and 2FA enabled

After merge:

  • Validate on fetching deps again for catalog repo
  • Don't validate before sending to helm-staging (as it gets (re)build there anyway)

On catalog-repo (not accepting PR's, locked down repo):

  • Validate again in staging branch
  • publish from main branch

On helm-staging (not accepting PR's, locked down repo):

  • Validate again in a staging branch
  • Sign from main branch before publish
  • publish deps seperately

Bottom line: Signatures get checked during PR testing AND right before the build is finalised

@PrivatePuffin PrivatePuffin added the enhancement New feature or request label May 3, 2023
@PrivatePuffin PrivatePuffin pinned this issue May 3, 2023
@PrivatePuffin PrivatePuffin changed the title Hardening Tracker Hardening and Security Tracker May 3, 2023
@truecharts truecharts locked and limited conversation to collaborators May 3, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant