|
| 1 | +# Catalog-fed-ramp |
| 2 | +The following folder contains guidelines and examples on how to create scorecards based on custom attributes, as an example to meet FIPS compliance. See https://harness.atlassian.net/wiki/spaces/IE1/pages/22281127180/IDP+PS+Best+Practice+Implementations for case studies. |
| 3 | + |
| 4 | +The scorecards are being reviewed by development team each week, and OPA policies will be eventually used to warn or enforce from deployment until dev team fixes defects to be in federal compliance. |
| 5 | + |
| 6 | +The score card will be relying on several custom attributes to pass: |
| 7 | + |
| 8 | +metadata.cve.warn |
| 9 | +metadata.cve.fail |
| 10 | +metadata.baseImage.compliance |
| 11 | +metadata.fips.compliance |
| 12 | + |
| 13 | +These attributes are populated using 3 pipelines to test the service Dockerfile, Jira tickets, and deployed image. The pipelines run once a day for each registered service to update these flags. Timestamp attributes are stamped for each execution. |
| 14 | + |
| 15 | +In this example, the pipelines are store in infra-harness repo, along with python scripts, and catalog-info.yaml. But there should be logic to allow overrides to use catalog-info.yaml residing in the service repo. |
| 16 | + |
| 17 | +# Catalog |
| 18 | +Catalog file is centralized in a repo managed by Infra team, or it could be maintained by each development team owning the service. However, the pipeline that performs the checks should be owned by infra or security team. |
| 19 | + |
| 20 | +Here is an example of a typical registration of catalog component. |
| 21 | + |
| 22 | +```yaml |
| 23 | +# see https://developer.harness.io/docs/internal-developer-portal/catalog/how-to-create-idp-yaml/ |
| 24 | + |
| 25 | +apiVersion: backstage.io/v1alpha1 |
| 26 | +kind: Component |
| 27 | +metadata: |
| 28 | +# name of the service |
| 29 | + name: test-service |
| 30 | +# tags - python/go/nodejs/java and fedramp are required for the scorecard to include only fedramp tags (exclusion rule does not exist yet) |
| 31 | + tags: |
| 32 | + - auto-generated |
| 33 | + - python |
| 34 | + - fedramp |
| 35 | +# useful links |
| 36 | + links: |
| 37 | + - url: https://app.harness.io/ng/account/xyz/module/cd/orgs/demo/projects/testervice/overview |
| 38 | + title: Deployment Dashboard |
| 39 | + icon: dashboard |
| 40 | + # recommended annotations |
| 41 | + annotations: |
| 42 | +# source code location for catalog-info.yaml, omit if move to service repo |
| 43 | + backstage.io/source-location: url:https://github.com/acme/test-service |
| 44 | +# service repository |
| 45 | + github.com/project-slug: acme/test-service |
| 46 | +# jira project key |
| 47 | + jira/project-key: xyz |
| 48 | +# optional jira component |
| 49 | + jira/component: xyz-service |
| 50 | +# technical doc |
| 51 | + backstage.io/techdocs-ref: url:https://github.com/acme/test-service |
| 52 | +# project url required for feature flag plugin |
| 53 | + harness.io/project-url: https://app.harness.io/ng/account/xyz/all/orgs/xyz/projects/testservice |
| 54 | +# serviceId required for listing CD and also used in OPA |
| 55 | + harness.io/cd-serviceId: testserviceid |
| 56 | +# numerate pipelines as needed (cd-serviceId list its default pipelines) |
| 57 | + harness.io/pipelines: | |
| 58 | + All in One Pipeline: |
| 59 | + Daily Security Scans: https://app.harness.io/ng/account/xyz/module/ci/orgs/demo/projects/testservice/pipelines/Daily_Security_Scan... |
| 60 | +# enumerate services as needed (cd-serviceId list its default service) |
| 61 | + harness.io/services: | |
| 62 | + test-service: http://... |
| 63 | +# optional jql warn / fail override (custom) |
| 64 | + acme/cve-warn: 'project = <<projectKey>> AND type = CVE AND "CVE SLA: Due date[Date]" >= endOfDay() AND "CVE SLA: Due date[Date]" <= 5d AND statusCategory != Done' |
| 65 | + acme/cve-fail: 'project = <<projectKey>> and type = CVE and "CVE SLA: Due date[Date]" < endOfDay() AND statusCategory != Done' |
| 66 | + |
| 67 | + |
| 68 | +spec: |
| 69 | + type: service |
| 70 | + lifecycle: staging |
| 71 | +# claim owner |
| 72 | + owner: devops_usergroup |
| 73 | +# optional reference to grpc definition |
| 74 | + providesApis: |
| 75 | + - test-service-grpc-api |
| 76 | +``` |
| 77 | +
|
| 78 | +## Python scripts |
| 79 | +
|
| 80 | +# common.py |
| 81 | +Contains commonly used python functions used across scripts: |
| 82 | +
|
| 83 | +extract_image_and_tag - extracts the Dockerfile's image_name and tag. Requires stage name to be labelled. |
| 84 | +
|
| 85 | +fetch_catalog_attributes - reads the catalog info and extract any custom info from catalog info using annotations acme/docker-path and tags for languages |
| 86 | +
|
| 87 | +updateCatalogAttributes - very useful fucntion to update IDP catalog attributes |
| 88 | +
|
| 89 | +determine_catalog_path - determines where to pull catalog info yaml, either from service repo path ./harness/idp/catalog-info.yaml or from harness-infra repo (the repo hosting all the catalog-info.yaml owned by infra or security team) |
| 90 | +
|
| 91 | +# Base tag compliance check |
| 92 | +docker-basetag-check.py inspects the Dockerfile looking for specific stage tags, and inspects whether the image used matches the ones defined in compliant_image function. The results are posted back to IDP catalog. |
| 93 | +
|
| 94 | +# CVE check |
| 95 | +jira-cve-check-dir.py iterates through the catalog configuration file for warn / fail overrides (use default jql query defined in the code otherwise), and post queries to Jira. Results are updated into IDP catalog. |
| 96 | +
|
| 97 | +
|
| 98 | +# fetch-repo-default-branch.py |
| 99 | +Queries GITHUB to determine a service's default branch (main or master for example). |
| 100 | +
|
| 101 | +# checks language FIPs compliance |
| 102 | +fips-validator.py uses different logic to check if the image built by the service passes compliance for different languages. It examines the service's helm chart, determine the image built, pulls the image. It will perform MD5 tests for nodejs and python. It will check for specific attributes in the docker image for labels matching chain guard inages. Chain guard images are useful for fed compliance. |
| 103 | +
|
| 104 | +# experimental |
| 105 | +docker-image-fips.py is an experimental docker n docker build and execute commands. Deprecated. Uses fips subfolder for docker n docker build as an example |
| 106 | +
|
| 107 | +# catalog-cve-scorecard.yaml |
| 108 | +Pipeline to pull information from Jira to populate cve ticket violates into IDP |
| 109 | +
|
| 110 | +# dockerverifications-pipeline.yaml |
| 111 | +Pipeline to very base image used |
| 112 | +
|
| 113 | +# fips-pipeline.yaml |
| 114 | +Examine the helm chart in the service repo to pull the latest image, to check for FIPS compliance for different languages |
| 115 | +
|
| 116 | +# Custom checks for score card |
| 117 | +# Fips compliance check |
| 118 | +Catalog Info YAML |
| 119 | +Equal to TRUE |
| 120 | +jexl: <+metadata.fips.compliance> |
| 121 | +
|
| 122 | +# Base Image Compliance |
| 123 | +Catalog Info YAML |
| 124 | +Equal to TRUE |
| 125 | +jexl: <+metadata.baseImage.compliance> |
| 126 | +
|
| 127 | +# CVE Fail |
| 128 | +Catalog Info YAML |
| 129 | +Equal to 0 |
| 130 | +jexl: <+metadata.cve.fail> |
| 131 | +
|
| 132 | +# CVE Warn |
| 133 | +Catalog Info YAML |
| 134 | +Equal to 0 |
| 135 | +jexl: <+metadata.cve.warn> |
0 commit comments