[{"_1":2,"_142":-5,"_143":-5},"loaderData",{"_3":4,"_17":18,"_25":26,"_136":137},"root",{"_5":-5,"_6":-7,"_7":8,"_9":-7,"_10":11,"_12":-7,"_13":14,"_15":16},"currentUser","primaryEmail","siteVerification","6LeIxAcTAAAAAJcZVRqyHh71UMIEGNQ_MXjiZKhI","toast","enableDev",false,"incidentStatus","theme","system","contrast","normal","routes/_layout",{"_19":-5,"_20":21,"_22":21,"_23":11,"_24":21},"username","isAskGordonEnabled",true,"isUsingNewTemplate","showMinimalLanding","showHoneypotTrap","routes/_layout.layers.$namespace.$reponame.$tag.(images).($imageUrlDigest)",{"_27":28,"_29":30,"_59":60,"_61":-7,"_62":-7,"_63":-7,"_64":-7,"_65":-5,"_66":-5,"_67":11,"_68":11,"_52":69,"_126":21,"_94":95,"_127":93,"_128":51,"_35":36,"_129":11,"_130":21,"_131":132,"_133":-5,"_134":11,"_135":11},"scanningType","none","tagData",{"_31":32,"_33":34,"_35":36,"_37":38,"_39":40,"_41":42,"_43":44,"_45":34,"_46":47,"_48":49,"_50":51,"_52":53,"_54":-5,"_55":44,"_56":57,"_58":21},"content_type","image","creator",35095401,"digest","sha256:203e410b676a5174d3bfa20c8a41e5cedc6e80b932ae8f641ec52d76986cf0a8","full_size",7947,"id",949324204,"images",[],"last_updated","2025-08-06T17:47:06.090742Z","last_updater","last_updater_username","bitnamibot508","media_type","application/vnd.oci.image.index.v1+json","name","sha256-a0c3411839141ba88dc94b035280eeaf5a7514896de7c5509046871080603e13","repository",24844319,"tag_last_pulled","tag_last_pushed","tag_status","inactive","v2","tagImages",[],"layerOrdinals","packageName","cveId","sbom","scoutSummary","staticSummary","isScoutPaymentRequired","canSeeVulnerabilities",{"_70":71,"_76":77,"_80":81,"_82":83,"_84":11,"_43":85,"_86":87,"_88":89,"_50":93,"_94":95,"_96":97,"_98":32,"_99":100,"_101":102,"_103":104,"_105":-5,"_106":100,"_107":108,"_109":11,"_110":95,"_111":112,"_117":11,"_118":119,"_123":95,"_124":125},"categories",[72],{"_50":73,"_74":75},"Internet of things","slug","internet-of-things","content_types",[78,32,79],"helm","unrecognized","date_registered","2024-08-09T15:43:01.754255Z","description","Bitnami Helm chart for Chainloop","is_private","2025-08-27T18:33:18.615993Z","last_modified","2026-03-16T14:23:14.905505Z","media_types",[90,91,49,92],"application/vnd.cncf.helm.config.v1+json","application/vnd.oci.image.config.v1+json","application/vnd.vmware.tac.metadata.config.v1+json","chainloop","namespace","bitnamicharts","pull_count",2038187,"repository_type","star_count",0,"status",1,"status_description","active","source","collaborator_count","full_description","\n\n# Bitnami Secure Images Helm chart for Chainloop\n\nChainloop is an open-source Software Supply Chain control plane, a single source of truth for metadata and artifacts, plus a declarative attestation process.\n\n[Overview of Chainloop](https://chainloop.dev)\n\nTrademarks: This software listing is packaged by Bitnami. The respective trademarks mentioned in the offering are owned by the respective companies, and use of them does not imply any affiliation or endorsement.\n\n## TL;DR\n\n```console\nhelm install my-release oci://REGISTRY_NAME/REPOSITORY_NAME/chainloop\n```\n\n> Note: You need to substitute the placeholders `REGISTRY_NAME` and `REPOSITORY_NAME` with a reference to your Helm chart registry and repository.\n\n## Introduction\n\nThis chart bootstraps a [Chainloop](https://github.com/chainloop-dev/chainloop) deployment on a [Kubernetes](https://kubernetes.io) cluster using the [Helm](https://helm.sh) package manager.\n\n## Before you begin\n\n- Kubernetes 1.23+\n- Helm 3.2.0+\n- PV provisioner support in the underlying infrastructure (If built-in PostgreSQL is enabled)\n\nCompatibility with the following Ingress Controllers has been verified, other controllers might or might not work.\n\n- [Nginx Ingress Controller](https://kubernetes.github.io/ingress-nginx/)\n- [Traefik](https://doc.traefik.io/traefik/providers/kubernetes-ingress/)\n\n## Installing the Chart\n\nThis chart comes in **two flavors**, [`standard`](#standard-default) and [`development`](#development).\n\n### Standard (default)\n\n![Deployment](https://raw.githubusercontent.com/chainloop-dev/chainloop/main/docs/img/deployment.png)\n\nThe default deployment mode relies on external dependencies to be available in advance.\n\nThe Helm Chart in this mode includes\n\n- Chainloop [Controlplane](https://github.com/chainloop-dev/chainloop/tree/main/app/controlplane)\n- Chainloop [Artifact proxy](https://github.com/chainloop-dev/chainloop/tree/main/app/artifact-cas)\n- A PostgreSQL dependency enabled by default\n\nDuring installation, you'll need to provide\n\n- Open ID Connect Identity Provider (IDp) settings i.e [Auth0 settings](https://auth0.com/docs/get-started/applications/application-settings#basic-information)\n- Connection settings for a secrets storage backend, either [Hashicorp Vault](https://www.vaultproject.io/) or [AWS Secrets Manager](https://aws.amazon.com/secrets-manager)\n- ECDSA (ES512) key-pair used for Controlplane to CAS Authentication\n\nInstructions on how to create the ECDSA keypair can be found [here](#generate-a-ecdsa-key-pair).\n\n#### Installation examples for standard mode\n\n> **NOTE**: **We do not recommend passing nor storing sensitive data in plain text**. For production, please consider having your overrides encrypted with tools such as [Sops](https://github.com/mozilla/sops), [Helm Secrets](https://github.com/jkroepke/helm-secrets) or [Sealed Secrets](https://github.com/bitnami-labs/sealed-secrets).\n\nDeploy Chainloop configured to talk to the bundled PostgreSQL an external OIDC IDp and a Vault instance.\n\n```console\nhelm install [RELEASE_NAME] oci://REGISTRY_NAME/REPOSITORY_NAME/chainloop \\\n # Open ID Connect (OIDC)\n --set controlplane.auth.oidc.url=[OIDC URL] \\\n --set controlplane.auth.oidc.clientID=[clientID] \\\n --set controlplane.auth.oidc.clientSecret=[clientSecret] \\\n # Secrets backend\n --set secretsBackend.vault.address=\"https://[vault address]:8200\" \\\n --set secretsBackend.vault.token=[token] \\\n # Server Auth KeyPair\n --set casJWTPrivateKey=\"$(cat private.ec.key)\" \\\n --set casJWTPublicKey=\"$(cat public.pem)\"\n```\n\nDeploy using AWS Secrets Manager instead of Vault\n\n```console\nhelm install [RELEASE_NAME] oci://REGISTRY_NAME/REPOSITORY_NAME/chainloop \\\n # Open ID Connect (OIDC)\n # ...\n # Secrets backend\n --set secretsBackend.backend=awsSecretManager \\\n --set secretsBackend.awsSecretManager.accessKey=[AWS ACCESS KEY ID] \\\n --set secretsBackend.awsSecretManager.secretKey=[AWS SECRET KEY] \\\n --set secretsBackend.awsSecretManager.region=[AWS region]\\\n # Server Auth KeyPair\n # ...\n```\n\nor using GCP Secret Manager\n\n```console\nhelm install [RELEASE_NAME] oci://REGISTRY_NAME/REPOSITORY_NAME/chainloop \\\n # Open ID Connect (OIDC)\n # ...\n # Secrets backend\n --set secretsBackend.backend=gcpSecretManager \\\n --set secretsBackend.gcpSecretManager.projectId=[GCP Project ID] \\\n --set secretsBackend.gcpSecretManager.serviceAccountKey=[GCP Auth KEY] \\\n # Server Auth KeyPair\n # ...\n```\n\nor Azure KeyVault\n\n```console\nhelm install [RELEASE_NAME] oci://REGISTRY_NAME/REPOSITORY_NAME/chainloop \\\n # Open ID Connect (OIDC)\n # ...\n # Secrets backend\n --set secretsBackend.backend=azureKeyVault \\\n --set secretsBackend.azureKeyVault.tenantID=[AD tenant ID] \\\n --set secretsBackend.azureKeyVault.clientID=[Service Principal ID] \\\n --set secretsBackend.azureKeyVault.clientSecret=[Service Principal secret] \\\n --set secretsBackend.azureKeyVault.vaultURI=[Azure KeyVault URI]\n # Server Auth KeyPair\n # ...\n```\n\nConnect to an external PostgreSQL database instead\n\n```console\nhelm install [RELEASE_NAME] oci://REGISTRY_NAME/REPOSITORY_NAME/chainloop \\\n # Open ID Connect (OIDC)\n # ...\n # Secrets backend\n # ...\n # Server Auth KeyPair\n # ...\n # External DB setup\n --set postgresql.enabled=false \\\n --set controlplane.externalDatabase.host=[DB_HOST] \\\n --set controlplane.externalDatabase.user=[DB_USER] \\\n --set controlplane.externalDatabase.password=[DB_PASSWORD] \\\n --set controlplane.externalDatabase.database=[DB_NAME]\n```\n\n### Development\n\nTo provide an easy way to give Chainloop a try, this Helm Chart has an **opt-in development** mode that can be enabled with the flag `development=true`\n\n> IMPORTANT: DO NOT USE THIS MODE IN PRODUCTION\n\n![Deployment](https://raw.githubusercontent.com/chainloop-dev/chainloop/main/docs/img/deployment-dev.png)\n\nThe Helm Chart in this mode includes\n\n- Chainloop [Controlplane](https://github.com/chainloop-dev/chainloop/tree/main/app/controlplane)\n- Chainloop [Artifact proxy](https://github.com/chainloop-dev/chainloop/tree/main/app/artifact-cas)\n- A PostgreSQL dependency enabled by default\n- **A pre-configured Hashicorp Vault instance running in development mode (unsealed, in-memory, insecure)**\n- **A pre-configured Dex OIDC instance.**\n\nThe pre-setup users configuration on the Chart include two users, the information is as follows:\n\n```text\nusername: sarah@chainloop.local\npassword: password\n\nusername: john@chainloop.local\npassword: password\n```\n\nThe overall OIDC configuration can be found at the `values.yaml` file.\n\n> **CAUTION**: Do not use this mode in production, for that, use the [standard mode](#standard-default) instead.\n\n#### Installation examples for development mode\n\nDeploy by leveraging built-in Vault and PostgreSQL instances\n\n```console\nhelm install [RELEASE_NAME] oci://REGISTRY_NAME/REPOSITORY_NAME/chainloop --set development=true\n```\n\n## AirGap and Relocation Support\n\nThis chart is compatible with relocation processes performed by the [Helm Relocation Plugin](https://github.com/vmware-labs/distribution-tooling-for-helm)\n\nThis is a two-step process (wrap -> unwrap)\n\n- Pull all the container images and Helm chart and wrap them in an intermediate tarball.\n- Unwrap the tarball and push container images, update the Helm Chart with new image references and push it to the target registry.\n\nFor example: to relocate to an Azure Container Registry\n\n```sh\nhelm dt wrap oci://REGISTRY_NAME/REPOSITORY_NAME/chainloop\n# 🎉 Helm chart wrapped into \"chainloop-1.77.0.wrap.tgz\"\n\n# Now you can take the tarball to an air-gapped environment and unwrap it like this\nhelm dt unwrap chainloop-1.77.0.wrap.tgz oci://chainloop.azurecr.io --yes\n# Unwrapping Helm chart \"chainloop-1.77.0.wrap.tgz\"\n# ✔ All images pushed successfully\n# ✔ Helm chart successfully pushed\n#\n# 🎉 Helm chart unwrapped successfully: You can use it now by running \"helm install oci://chainloop.azurecr.io/chart/chainloop --generate-name\"\n```\n\n## How to guides\n\n### CAS upload speeds are slow, what can I do?\n\nChainloop uses gRPC streaming to perform artifact uploads. This method is susceptible to being very slow on high latency scenarios. [#375](https://github.com/chainloop-dev/chainloop/issues/375)\n\nTo improve upload speeds, you need to increase [http2 flow control buffer](https://httpwg.org/specs/rfc7540.html#DisableFlowControl). This can be done in NGINX by setting the following annotation in the ingress resource.\n\n```yaml\n# Improve upload speed by adding client buffering used by http2 control-flows\nnginx.ingress.kubernetes.io/client-body-buffer-size: \"3M\"\n\n```\n\nNote: For other reverse proxies, you'll need to find the equivalent configuration.\n\n### Generate a ECDSA key-pair\n\nAn ECDSA key-pair is required to perform authentication between the control-plane and the Artifact CAS\n\nYou can generate both the private and public keys by running\n\n```bash\n# Private Key (private.ec.key)\nopenssl ecparam -name secp521r1 -genkey -noout -out private.ec.key\n# Public Key (public.pem)\nopenssl ec -in private.ec.key -pubout -out public.pem\n```\n\nThen, you can either provide it in a custom `values.yaml` file override\n\n```yaml\ncasJWTPrivateKey: |-\n -----BEGIN EC PRIVATE KEY-----\n REDACTED\n -----END EC PRIVATE KEY-----\ncasJWTPublicKey: |\n -----BEGIN PUBLIC KEY-----\n REDACTED\n -----END PUBLIC KEY-----\n```\n\nor as shown before, provide them as imperative inputs during Helm Install/Upgrade `--set casJWTPrivateKey=\"$(cat private.ec.key)\"--set casJWTPublicKey=\"$(cat public.pem)\"`\n\n### Enable a custom domain with TLS\n\nChainloop uses three endpoints so we'll need to enable the ingress resource for each one of them.\n\nSee below an example of a `values.yaml` override\n\n```yaml\ncontrolplane:\n ingress:\n enabled: true\n hostname: cp.chainloop.dev\n\n ingressAPI:\n enabled: true\n hostname: api.cp.chainloop.dev\n\ncas:\n ingressAPI:\n enabled: true\n hostname: api.cas.chainloop.dev\n```\n\nA complete setup that uses\n\n- [NGINX as ingress Controller](https://kubernetes.github.io/ingress-nginx)\n- [cert-manager](https://cert-manager.io/) as TLS provider\n\nwould look like\n\n```yaml\ncontrolplane:\n ingress:\n enabled: true\n tls: true\n ingressClassName: nginx\n hostname: cp.chainloop.dev\n annotations:\n # This depends on your configured issuer\n cert-manager.io/cluster-issuer: \"letsencrypt-prod\"\n\n ingressAPI:\n enabled: true\n tls: true\n ingressClassName: nginx\n hostname: api.cp.chainloop.dev\n annotations:\n nginx.ingress.kubernetes.io/backend-protocol: \"GRPC\"\n cert-manager.io/cluster-issuer: \"letsencrypt-prod\"\n\ncas:\n ingressAPI:\n enabled: true\n tls: true\n ingressClassName: nginx\n hostname: api.cas.chainloop.dev\n annotations:\n nginx.ingress.kubernetes.io/backend-protocol: \"GRPC\"\n cert-manager.io/cluster-issuer: \"letsencrypt-prod\"\n # limit the size of the files that go through the proxy\n # 0 means to not check the size of the request so we do not get 413 error.\n # For now we are going to set a limit on 100MB files\n # Even though we send data in chunks of 1MB, this size refers to all the data sent in the streaming connection\n nginx.ingress.kubernetes.io/proxy-body-size: \"100m\"\n```\n\nRemember, once you have set up your domain, make sure you use the [CLI pointing](#configure-chainloop-cli-to-point-to-your-instance) to it instead of the defaults.\n\n### Connect to an external PostgreSQL database\n\n```yaml\n# Disable built-in DB\npostgresql:\n enabled: false\n\n# Provide with external connection\ncontrolplane:\n externalDatabase:\n host: 1.2.3.4\n port: 5432\n user: chainloop\n password: [REDACTED]\n database: chainloop-controlplane-prod\n```\n\nAlternatively, if you are using [Google Cloud SQL](https://cloud.google.com/sql) and you are running Chainloop in Google Kubernetes Engine. You can connect instead via [a proxy](https://cloud.google.com/sql/docs/mysql/connect-kubernetes-engine#proxy)\n\nThis method can also be easily enabled in this chart by doing\n\n```yaml\n# Disable built-in DB\npostgresql:\n enabled: false\n\n# Provide with external connection\ncontrolplane:\n sqlProxy:\n # Inject the proxy sidecar\n enabled: true\n ## @param controlplane.sqlProxy.connectionName Google Cloud SQL connection name\n connectionName: \"my-sql-instance\"\n # Then you'll need to configure your DB settings to use the proxy IP address\n externalDatabase:\n host: [proxy-sidecar-ip-address]\n port: 5432\n user: chainloop\n password: [REDACTED]\n database: chainloop-controlplane-prod\n```\n\n### Use AWS secrets manager\n\nInstead of using [Hashicorp Vault](https://www.vaultproject.io/) (default), you can use [AWS Secrets Manager](https://aws.amazon.com/secrets-manager/) by adding these settings in your `values.yaml` file\n\n```yaml\nsecretsBackend:\n backend: awsSecretManager\n awsSecretManager:\n accessKey: [KEY]\n secretKey: [SECRET]\n region: [REGION]\n```\n\n### Use GCP secret manager\n\nOr [Google Cloud Secret Manager](https://cloud.google.com/secret-manager) with the following settings\n\n```yaml\nsecretsBackend:\n backend: gcpSecretManager\n gcpSecretManager:\n projectId: [PROJECT_ID]\n serviceAccountKey: [KEY]\n```\n\n### Use Azure KeyVault\n\n[Azure KeyVault](https://azure.microsoft.com/en-us/products/key-vault/) is also supported\n\n```yaml\nsecretsBackend:\n backend: azureKeyVault\n azureKeyVault:\n tenantID: [TENANT_ID] # Active Directory Tenant ID\n clientID: [CLIENT_ID] # Registered application / service principal client ID\n clientSecret: [CLIENT_SECRET] # Service principal client secret\n vaultURI: [VAULT URI] # Azure Key Vault URL\n\n```\n\n### Deploy in keyless mode with file-based CA\n\n*This feature is experimental, as it doesn't yet support verification.*\n\nYou can enable keyless signing mode by providing a custom Certificate Authority.\nFor example, these commands generate a self-signed certificate with an RSA private key of length 4096 and AES256 encryption with a validity of 365 days:\n\n```bash\n> openssl genrsa -aes256 -out ca.key 4096\n...\n> openssl req -new -x509 -sha256 -key ca.key -out ca.crt -days 365\n...\n```\n\nThen you can configure your deployment values with:\n\n```yaml\ncontrolplane:\n keylessSigning:\n enabled: true\n backend: fileCA\n fileCA:\n cert: |\n -----BEGIN CERTIFICATE-----\n ...\n -----END CERTIFICATE-----\n key: |\n -----BEGIN ENCRYPTED PRIVATE KEY-----\n ...\n -----END ENCRYPTED PRIVATE KEY-----\n keyPass: \"REDACTED\"\n```\n\n### Insert custom Certificate Authorities (CAs)\n\nIn some scenarios, you might want to add custom Certificate Authorities to the Chainloop deployment. Like in the instance where your OIDC provider uses a self-signed certificate. To do so, add the PEM-encoded CA certificate to the `customCAs` list in either `controlplane` or `cas` sections, in your `values.yaml` file like in the example below.\n\n```yaml\n customCAs:\n - |-\n -----BEGIN CERTIFICATE-----\n MIIFmDCCA4CgAwIBAgIQU9C87nMpOIFKYpfvOHFHFDANBgkqhkiG9w0BAQsFADBm\n BhMCVVMxMzAxBgNVBAoTKihTVEFHSU5HKSBJbnRlcm5ldCBTZWN1cml0eSBSZXNl\n REDACTED\n 5CunuvCXmEQJHo7kGcViT7sETn6Jz9KOhvYcXkJ7po6d93A/jy4GKPIPnsKKNEmR\n 7DiA+/9Qdp9RBWJpTS9i/mDnJg1xvo8Xz49mrrgfmcAXTCJqXi24NatI3Oc=\n -----END CERTIFICATE-----\n```\n\n### Send exceptions to Sentry\n\nYou can configure different sentry projects for both the controlplane and the artifact CAS\n\n```yaml\n# for controlplane\ncontrolplane:\n ...\n sentry:\n enabled: true\n dsn: [your secret sentry project DSN URL]\n environment: production\n# Artifact CAS\ncas:\n ...\n sentry:\n enabled: true\n dsn: [your secret sentry project DSN URL]\n environment: production\n```\n\n### Enable Prometheus Monitoring in GKE\n\nChainloop exposes Prometheus compatible `/metrics` endpoints that can be easily scraped by a Prometheus data collector Server.\n\nGoogle Cloud has a [managed Prometheus offering](https://cloud.google.com/stackdriver/docs/managed-prometheus/setup-managed) that could be easily enabled by setting `--set GKEMonitoring.enabled=true`. This will inject the required `PodMonitoring` custom resources.\n\n### Configure Chainloop CLI to point to your instance\n\nOnce you have your instance of Chainloop deployed, you need to configure the [CLI](https://github.com/chainloop-dev/chainloop/releases) to point to both the CAS and the Control plane gRPC APIs like this.\n\n```bash\nchainloop config save \\\n --control-plane my-controlplane.acme.com:443 \\\n --artifact-cas cas.acme.com:443\n```\n\n### Gateway API\n\nThis chart provides support for exposing Chainloop using the [Gateway API](https://gateway-api.sigs.k8s.io/) and its `HTTPRoute` resource. If you have a Gateway controller installed on your cluster, such as APISIX, Contour, Envoy Gateway, NGINX Gateway Fabric or Kong Ingress Controller you can utilize the Gateway controller to serve your application. To enable Gateway API integration, set `XXX.httpRoute.enabled` to `true` (where `XXX` is `controplane`, or `cas` depending on which component you want to expose).\nThe Gateway to be used can be customized by setting the `XXX.httpRoute.parentRefs` parameter. By default, it will reference a Gateway named `gateway` in the same namespace as the release.\n\nYou can specify the list of hostnames to be mapped to the deployment using the `XXX.httpRoute.hostnames` parameter. Additionally, you can customize the rules used to route the traffic to the service by modifying the `XXX.httpRoute.matches` and `XXX.httpRoute.filters` parameters or adding new rules using the `XXX.httpRoute.extraRules` parameter.\n\nThis chart also supports creating a `BackendTLSPolicy` to define the SNI the Gateway should use to connect to the Chainloop backend pods and how the certificate served by these pods should be verified. To do so, set the `XXX.backendTLSPolicy.enabled` parameter to `true`. Please note it's required to secure traffic using TLS so you need to also set `XXX.tls.existingSecret` to reference a secret containing the TLS certificate and private key used by the component.\n\n### FIPS parameters\n\nThe FIPS parameters only have effect if you are using images from the [Bitnami Secure Images catalog](https://go-vmware.broadcom.com/contact-us).\n\nFor more information on this new support, please refer to the [FIPS Compliance section](https://techdocs.broadcom.com/us/en/vmware-tanzu/bitnami-secure-images/bitnami-secure-images/services/bsi-doc/security-frameworks-FIPS-compliance.html).\n\n## Parameters\n\nThe following subsections list global, common, and component-specific parameters.\n\n### Global parameters\n\n| Name | Description | Value |\n| ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------ |\n| `global.imageRegistry` | Global Docker image registry | `\"\"` |\n| `global.imagePullSecrets` | Global Docker registry secret names as an array | `[]` |\n| `global.defaultFips` | Default value for the FIPS configuration (allowed values: '', restricted, relaxed, off). Can be overridden by the 'fips' object | `restricted` |\n| `global.security.allowInsecureImages` | Allows skipping image verification | `false` |\n| `global.compatibility.openshift.adaptSecurityContext` | Adapt the securityContext sections of the deployment to make them compatible with Openshift restricted-v2 SCC: remove runAsUser, runAsGroup and fsGroup and let the platform use their allowed default IDs. Possible values: auto (apply if the detected running cluster is Openshift), force (perform the adaptation always), disabled (do not perform adaptation) | `auto` |\n| `global.postgresql.auth.username` | PostgreSQL username (overrides `postgresql.auth.username`) | `\"\"` |\n| `global.postgresql.auth.password` | PostgreSQL password (overrides `postgresql.auth.password`) | `\"\"` |\n| `global.postgresql.auth.database` | PostgreSQL database (overrides `postgresql.auth.database`) | `\"\"` |\n| `development` | Deploys Chainloop pre-configured FOR DEVELOPMENT ONLY. It includes a Vault instance in development mode and pre-configured authentication certificates and passphrases | `true` |\n\n### Common parameters\n\n| Name | Description | Value |\n| ------------------- | ---------------------------------------------------------- | ------- |\n| `kubeVersion` | Override Kubernetes version | `\"\"` |\n| `apiVersions` | Override Kubernetes API versions reported by .Capabilities | `[]` |\n| `nameOverride\n\n_Note: the README for this chart is longer than the DockerHub length limit of 25000, so it has been trimmed. The full README can be found at https://techdocs.broadcom.com/us/en/vmware-tanzu/bitnami-secure-images/bitnami-secure-images/services/bsi-app-doc/apps-charts-chainloop-index.html_","has_starred","hub_user","immutable_tags_settings",{"_113":11,"_114":115},"enabled","rules",[116],".*","is_automated","permissions",{"_120":21,"_121":11,"_122":11},"read","write","admin","user","storage_size",42448337,"isOrg","reponame","tag","canDeleteTags","isHubSbxKitsEnabled","currentTab","","tagAttestations","displaySecurityMetadata","showSbxLogoOverride","routes/_layout.layers.$namespace.$reponame.$tag.(images).($imageUrlDigest)._index",{"_27":28,"_63":-7,"_61":-7,"_62":-7,"_29":138,"_35":36,"_140":-7,"_141":11},{"_31":32,"_33":34,"_35":36,"_37":38,"_39":40,"_41":139,"_43":44,"_45":34,"_46":47,"_48":49,"_50":51,"_52":53,"_54":-5,"_55":44,"_56":57,"_58":21},[],"imageWithLayers","hasPermissionToViewRepoSettings","actionData","errors"]

bitnamicharts/chainloop:sha256-a0c3411839141ba88dc94b035280eeaf5a7514896de7c5509046871080603e13