diff --git a/devops-mcp-server/prompts/deploy_prompt.md b/devops-mcp-server/prompts/deploy_prompt.md index 761995a..a9c73c7 100644 --- a/devops-mcp-server/prompts/deploy_prompt.md +++ b/devops-mcp-server/prompts/deploy_prompt.md @@ -50,6 +50,8 @@ Your job is to deploy the user's applications to Cloud Run from an image. These rules apply to all workflows. +Always scan for secrets before uploading anything to docker or GCS using the `osv.scan_secrets` tool. Warn the user of any secrets available. Always ignore directories where scanning is not useful e.g. dependencies which the user has no control over e.g. .vnev or go_modules etc. Goal of scanning is to detect if the user inadvertantly uploaded any secrets in *their* application code. + ### **Error Handling Protocol** 1. **STOP EXECUTION**: If any tool returns an error, immediately halt the plan. diff --git a/devops-mcp-server/rag/client/devops-rag.db b/devops-mcp-server/rag/client/devops-rag.db index cf8179d..a7fa70d 100644 Binary files a/devops-mcp-server/rag/client/devops-rag.db and b/devops-mcp-server/rag/client/devops-rag.db differ diff --git a/local-rag/patterns/git_tag_triggered_canary_release.txt b/local-rag/patterns/git_tag_triggered_canary_release.txt deleted file mode 100644 index 9d16586..0000000 --- a/local-rag/patterns/git_tag_triggered_canary_release.txt +++ /dev/null @@ -1,67 +0,0 @@ -name: "Git Tag-Triggered Canary Release" -description: "A pattern where every commit runs CI, but a deployment is only initiated when a Git tag is pushed. The release to production is managed by Cloud Deploy using a progressive canary strategy (e.g., 25% -> 100%) to reduce risk." - -applicability: - triggers: ["git_commit", "git_tag"] - deployment_style: "progressive_delivery" - use_case_keywords: ["versioned releases", "production pipeline", "canary release", "automated rollout", "reduced blast radius"] - -additional_settings: - delivery_pipeline: - type: "cloud-deploy-pipeline" - details: "A two-stage pipeline deploying to staging, followed by a progressive canary rollout to production." - stages: - - name: "staging" - # Standard deployment to staging for final verification. - - name: "production" - strategy: - canary: - # Defines the traffic percentages for the rollout phases. - percentages: [25, 100] - # Indicates that a verification step (e.g., automated testing) should run after the canary phase. - verification_required: true - -stages: - # The CI stage runs on every commit to verify code quality but does not produce a deployable artifact. - ci: - id: "ci_build_and_test" - type: "cloud-build" - name: "CI Build and Test" - details: "Listens for commits on the main branch. Runs lint, test, and builds the container to ensure it's valid, but does not push it." - steps: - - id: "lint_step" - type: "linter" - name: "Run Linter" - details: "Runs a static code analysis tool appropriate for the project." - - id: "test_step" - type: "test" - name: "Run Unit Tests" - details: "Executes the project's unit test suite." - - id: "dry_run_build_step" - type: "docker" - name: "Dry-Run Build" - details: "Builds the container image to validate the Dockerfile but does not push it." - - # The CD stage is a distinct workflow triggered only by a Git tag. - cd: - trigger: - type: "git_tag" - details: "This stage is initiated by pushing a git tag (e.g., v1.2.0)." - steps: - - id: "build_and_push_release_artifact" - type: "cloud-build" - name: "Build and Push Release Artifact" - details: "Builds the final container image, signs it, and pushes it to Artifact Registry, tagged with the specific Git tag." - - id: "create_cloud_deploy_release" - type: "cloud-deploy" - name: "Create Cloud Deploy Canary Release" - details: "Creates a new formal release in a Cloud Deploy pipeline configured for a canary rollout to production." - -tradeoffs: - pros: - - "Dramatically reduces the risk of production incidents by limiting the blast radius of a bad release." - - "Fully automated process allows for faster and more frequent releases than manual approvals." - - "Enables data-driven decisions based on monitoring metrics during the canary phase." - cons: - - "More complex to set up; requires robust monitoring and observability to be effective." - - "The application must be architected to handle multiple versions running simultaneously." diff --git a/local-rag/patterns/git_tag_triggered_release_with_manual_approval.txt b/local-rag/patterns/git_tag_triggered_release_with_manual_approval.txt deleted file mode 100644 index 995c343..0000000 --- a/local-rag/patterns/git_tag_triggered_release_with_manual_approval.txt +++ /dev/null @@ -1,62 +0,0 @@ -name: "Git Tag-Triggered Release with Manual Approvals" -description: "A pattern where every commit runs CI, but a deployment is only initiated when a Git tag is pushed. The release is managed by Cloud Deploy with a mandatory manual approval gate before promoting to production." - -applicability: - triggers: ["git_commit", "git_tag"] - deployment_style: "gated_continuous_delivery" - use_case_keywords: ["versioned releases", "production pipeline", "manual approval", "compliance", "auditing"] - -additional_settings: - delivery_pipeline: - type: "cloud-deploy-pipeline" - details: "A two-stage pipeline for deploying to staging and production." - stages: - - name: "staging" - requires_approval: false - - name: "production" - requires_approval: true # Explicitly requires manual approval for this target. - -stages: - # The CI stage runs on every commit to verify code quality but does not produce a deployable artifact. - ci: - id: "ci_build_and_test" - type: "cloud-build" - name: "CI Build and Test" - details: "Listens for commits on the main branch. Runs lint, test, and builds the container to ensure it's valid, but does not push it." - steps: - - id: "lint_step" - type: "linter" - name: "Run Linter" - details: "Runs a static code analysis tool appropriate for the project." - - id: "test_step" - type: "test" - name: "Run Unit Tests" - details: "Executes the project's unit test suite." - - id: "dry_run_build_step" - type: "docker" - name: "Dry-Run Build" - details: "Builds the container image to validate the Dockerfile but does not push it." - - # The CD stage is a distinct workflow triggered only by a Git tag. - cd: - trigger: - type: "git_tag" - details: "This stage is initiated by pushing a git tag (e.g., v1.2.0)." - steps: - - id: "build_and_push_release_artifact" - type: "cloud-build" - name: "Build and Push Release Artifact" - details: "Builds the final container image, signs it, and pushes it to Artifact Registry, tagged with the specific Git tag." - - id: "create_cloud_deploy_release" - type: "cloud-deploy" - name: "Create Cloud Deploy Release" - details: "Creates a new formal release in Cloud Deploy using the tagged container image, making it available for promotion to various environments." - -tradeoffs: - pros: - - "Strong separation between integration and deployment, preventing every commit from going to production." - - "Creates a clear audit trail; every release is tied to a specific version tag in Git." - - "Enables controlled promotions (dev -> staging -> prod) via Cloud Deploy." - cons: - - "Slower feedback loop for deployment compared to push-to-deploy." - - "Requires disciplined Git tagging practices from the development team." \ No newline at end of file diff --git a/local-rag/patterns/scheduled_nightly_release.txt b/local-rag/patterns/scheduled_nightly_release.txt deleted file mode 100644 index 840b905..0000000 --- a/local-rag/patterns/scheduled_nightly_release.txt +++ /dev/null @@ -1,42 +0,0 @@ -name: "Scheduled Nightly Release" -description: "A pattern where code is built and tested on every push, but a release is only created at a fixed time (e.g., nightly) for deployment to a staging environment." - -applicability: - triggers: ["schedule", "time-based"] - deployment_style: "automated_scheduled" - use_case_keywords: ["nightly builds", "integration environments", "timed release"] - -# "components" is replaced by the more descriptive "stages" -stages: - # The CI stage runs on every commit - ci: - id: "ci_trigger_step" - name: "Cloud Build CI Trigger" - type: "cloud-build" - details: "Listens for commits on the main branch. Runs build, lint, and tests. Pushes the container image to Artifact Registry." - - # The CD stage is a single workflow that runs on a schedule - cd: - trigger: # Explicitly define how this entire stage is triggered - type: "schedule" - details: "This stage is initiated by a nightly scheduled event." - steps: # The list of sequential steps within the CD stage - - id: "scheduler_step" - name: "Cloud Scheduler Job" - type: "cloud-scheduler" - details: "A cron job configured to run at a specified time invokes the `release_trigger_step`" - - id: "release_trigger_step" - name: "Cloud Build Release Trigger" - type: "cloud-build" - details: "Triggered by the Cloud Scheduler job. It finds the latest successful container image and creates a new release in Cloud Deploy." - - id: "deploy_pipeline_step" - name: "Cloud Deploy Pipeline" - type: "cloud-deploy" - details: "Manages the rollout of the nightly release to the 'staging' environment." - -tradeoffs: - pros: - - "Predictable release cadence." - - "Allows for a full day of commits to be tested together." - cons: - - "A single bad commit can block the nightly release for everyone." \ No newline at end of file diff --git a/local-rag/patterns/secure_git_gated_deployment.txt b/local-rag/patterns/secure_git_gated_deployment.txt deleted file mode 100644 index 2ec2b87..0000000 --- a/local-rag/patterns/secure_git_gated_deployment.txt +++ /dev/null @@ -1,76 +0,0 @@ -# plan.yaml: A complete pattern definition for a secure CI/CD pipeline. -# This pattern integrates multiple security gates to ensure the integrity and safety of production deployments. - -name: "Secure Git-Gated Deployment" -description: "A pattern that enforces security throughout the lifecycle. It includes static code analysis (SAST), container vulnerability scanning, and a Binary Authorization policy to ensure only trusted and verified artifacts are deployed to GKE." - -applicability: - triggers: ["git_commit", "git_tag"] - deployment_style: "secure_continuous_delivery" - use_case_keywords: ["security", "compliance", "SLSA", "SAST", "vulnerability scanning", "Binary Authorization"] - -# The `resources` section defines the security policy infrastructure. -resources: - binary_authorization_policy: - type: "binary-authorization-policy" - name: "gke-deployment-policy" - details: "A policy that requires attestations from both the CI system and a vulnerability scanner before allowing deployment to GKE." - state: "create" - rules: - - evaluation_mode: "REQUIRE_ATTESTATION" - enforcement_mode: "ENFORCED_BLOCK_AND_AUDIT_LOG" - required_attestors: ["built-by-ci-attestor", "vulnerability-scan-attestor"] - -stages: - # The CI stage now includes a SAST step to find vulnerabilities in source code. - ci: - id: "ci_secure_build_and_test" - type: "cloud-build" - name: "CI Secure Build and Test" - details: "Listens for commits. Runs lint, test, and a static analysis security test (SAST) on the source code." - steps: - - id: "lint_step" - type: "linter" - name: "Run Linter" - details: "Runs a static code analysis tool." - - id: "test_step" - type: "test" - name: "Run Unit Tests" - details: "Executes the project's unit test suite." - - id: "sast_scan_step" - type: "sast-scanner" - name: "Static Application Security Testing" - details: "Scans the source code for security vulnerabilities before building." - - # The CD stage includes vulnerability scanning and requires a Binary Authorization attestation. - cd: - trigger: - type: "git_tag" - details: "This stage is initiated by pushing a git tag (e.g., v1.3.0)." - steps: - - id: "build_and_push_artifact" - type: "cloud-build" - name: "Build and Push Release Artifact" - details: "Builds the final container image and pushes it to Artifact Registry." - - id: "vulnerability_scan_step" - type: "artifact-analysis" - name: "Scan for Vulnerabilities" - details: "Triggers Artifact Analysis to scan the newly pushed container for known CVEs." - - id: "create_attestation_step" - type: "binary-authorization" - name: "Create Binary Authorization Attestation" - details: "If the vulnerability scan passes, creates a formal attestation certifying the image is secure and verified." - - id: "deploy_to_gke_step" - type: "cloud-deploy" - name: "Deploy to GKE with Binary Authorization" - details: "Creates a release in Cloud Deploy to a GKE cluster that has the 'gke-deployment-policy' enforced." - -tradeoffs: - pros: - - "Provides a high degree of confidence in the security and integrity of deployed artifacts." - - "Automates security gates, making compliance a part of the standard workflow." - - "Prevents entire classes of vulnerabilities from reaching production." - cons: - - "Increases build time due to additional scanning and analysis steps." - - "Adds complexity to the pipeline setup and requires careful management of signing keys and attestors." - - "Can block releases if new, non-critical vulnerabilities are found, requiring a policy tuning process."