-title:GitOps examples

url:"/cd-examples"

-title:Pipeline integrations

url:"/integrations"

pages:

-title:Codefresh Hosted GitOps

url:"/codefresh-hosted-gitops"

-title:Git Providers

url:"/git-providers"

-title:Kubernetes

url:"/kubernetes"

-title:Amazon Services

url:"/amazon-web-services"

-title:Microsoft Azure

url:"/microsoft-azure"

-title:Google Cloud

url:"/google-cloud"

-title:Docker registries

url:"/docker-registries"

sub-pages:

-title:Docker Hub

url:"/docker-hub"

-title:Azure Docker Registry

url:"/azure-docker-registry"

-title:Amazon EC2 Container Registry

url:"/amazon-ec2-container-registry"

-title:Google Container Registry

url:"/google-container-registry"

-title:Google Artifact Registry

url:"/google-artifact-registry"

-title:JFrog Bintray.io/Artifactory

url:"/bintray-io"

-title:Quay.io

url:"/quay-io"

-title:GitHub Container Registry

url:"/github-container-registry"

-title:DigitalOcean Container Registry

url:"/digital-ocean-container-registry"

-title:Other Registries

url:"/other-registries"

-title:Secret Storage

url:"/secret-storage"

-title:Hashicorp Vault

url:"/hashicorp-vault"

-title:Helm Integration

url:"/helm"

-title:ArgoCD Integration

url:"/argocd"

-title:Datadog Integration

url:"/datadog"

-title:Jira Integration

url:"/jira"

-title:Jenkins Integration

url:"/jenkins-integration"

-title:Codecov Integration

url:"/codecov-integration"

-title:Google Cloud builder

url:"/gcloud-builder"

-title:Google Marketplace Installation

url:"/google-marketplace"

-title:GitHub Actions

url:"/github-actions"

-title:Notifications

url:"/notifications"

sub-pages:

-title:Slack

url:"/slack-integration"

-title:Jira

url:"/jira-integration"

-title:Codefresh API

url:"/codefresh-api"

-title:GitOps integrations

url:"/gitops-integrations"

pages:

-title:Image enrichment with GitOps integrations

url:"/image-enrichment-overview"

-title:GitOps CI integrations

url:"/ci-integrations"

sub-pages:

-title:Codefresh Classic

url:"/codefresh-classic"

-title:GitHub Actions

url:"/github-actions"

-title:Jenkins

url:"/jenkins"

-title:GitOps issue tracking integrations

url:"/issue-tracking"

sub-pages:

-title:Jira

url:"/jira"

-title:GitOps container registry integrations

url:"/container-registries"

sub-pages:

-title:Amazon ECR

url:"/amazon-ecr"

-title:Docker Hub Registry

url:"/dockerhub"

-title:GitHub Container Registry

url:"/github-cr"

-title:JFrog Artifactory

url:"/jfrog"

-title:Quay Registry

url:"/quay"

-title:Deployments

url:"/deployments"

-title:Sharing file systems

url:"/sharing-file-system"

-title:CI/CD testing

url:"/testing"

pages:

-title:Unit tests

url:"/unit-tests"

-title:Integration tests

url:"/integration-tests"

-title:Creating test reports

url:"/test-reports"

-title:Creating compositions

url:"/create-composition"

-title:Dynamic preview environments

url:"/automatic-preview-environments"

-title:Security scanning

url:"/security-scanning"

-title:SonarQube scanning

url:"/sonarqube-integration"

-title:Clients

url:"/clients"

title:"Git tokens"

description:""

group:reference

redirect_from:

-/docs/administration/git-tokens/

toc:true

Codefresh requires two types of Git tokens for authentication:

* Git runtime token for runtime installation

Used by:

* Argo CD clone repositories and pull changes to sync the desired state in Git to the live state on the cluster.

* Argo Events to create webhooks in Git repositories for Event Sources in Delivery Pipelines

The Git runtime token is runtime-specific but not user-specific.

* Git user token, a user-specific personal access token for each runtime, unique to every user

Unique to every user, the Git user token is used to authenticate the user for client-based actions, such as Git clone and push operations on specific repositories.

Git user token requirements translate to permission scopes which differ for the different Git providers.

After installation, you need to authorize Git access for every provisioned runtime either through OAuth2 or through a personal access token from your Git provider.

Every user can view the list of runtimes and tokens assigned to each runtime in[User Settings](https://g.codefresh.io/2.0/user-settings){:target="\_blank"}. Codefresh flags and notifies you of invalid, revoked, or expired tokens.

The Git runtime token is mandatory for runtime installation.

{::nomarkdown}

</br>

{:/}

{::nomarkdown}

</br>

{:/}

{::nomarkdown}

</br>

{:/}

***Account**:`Read`

***Workspace membership**:`Read`

***Webhooks**:`Read and write`

***Repositories**:`Write`,`Admin`

{::nomarkdown}

</br></br>

{:/}

The Git personal token is a user-specific personal access token per provisioned runtime. Unique to each user, it may be required after to authenticate Git-based actions per runtime in Codefresh, based on how your admin has set up authentication for Git providers.

You must configure the token for each runtime.

{::nomarkdown}

</br>

{:/}

{::nomarkdown}

</br>

{:/}

*`write_repository` (includes`read-repository`)

{::nomarkdown}

</br>

{:/}

***Account**:`Read`

***Workspace membership**:`Read`

***Repositories**:`Write`,`Admin`

[User settings]({{site.baseurl}}/docs/administration/user-settings/)

title:"Secrets"

description:"Learn how Codefresh stores secrets"

group:reference

toc:true

Codefresh provides out-of-the-box management for secrets, generally to store secrets for third-party integrations.

For secure secret storage, every Codefresh runtime uses the[Bitnami Sealed Secrets controller](https://github.com/bitnami-labs/sealed-secrets){:target="_blank"} behind the scenes.

This controller is installed as part of the runtime and automatically managed by Codefresh.

Sealed Secrets are based on[public/private key encryption](https://en.wikipedia.org/wiki/Public-key_cryptography){:target="_blank"}. When the controller is installed, it gets a public and private key. The private key stays within the cluster. The public key can be given anywhere to encrypt secrets.

Any kind of secret can be encrypted with the public key (also via the`kubeseal` executable), and then passed to the cluster for decryption when needed.

For GitOps applications, encryption for secrets is critical, as it means that you can commit any kind of secret in Git as long as it is encrypted.

Here's the event flow for Sealed Secrets:

1. A secret is encrypted by an operator and/or developer with the`kubeseal` executable.

1. A custom Kubernetes resource called SealedSecret is created.

1. The secret is committed in Git.

1. During application deployment, the Codefresh runtime applies this secret to the cluster.

1. The Sealed Secret controller identifies the Sealed Secret object and decrypts it using the private key of the cluster.

1. The Sealed Secret is converted to a[standard Kubernetes secret](https://kubernetes.io/docs/concepts/configuration/secret/) {:target="_blank"} inside the cluster.

1. It is then passed to the application like any other secret, as a mounted file or environment variable.

1. The application uses the secret in its decrypted form.

For more details, you can read our[blog post for sealed secrets](https://codefresh.io/blog/handle-secrets-like-pro-using-gitops/){:target="_blank"}.

The Sealed Secret controller is fully managed by the Codefresh runtime, and secret encryption and decryption are fully automated.

The applications you deploy with Codefresh should also have no knowledge of the controller. All secrets that you need in your own applications should be accessed using the standard Kubernetes methods.

[Set up a hosted (Hosted GitOps environment]({{site.baseurl}}/docs/runtime/hosted-runtime)

[Install hybrid runtimes]({{site.baseurl}}/docs/runtime/installation)

[Image enrichment with integrations]({{site.baseurl}}/docs/integrations/image-enrichment-overview)