Harness Git
You set up harness git by linking your source repo to your pipeline project. This link lets your team store pipeline files and trigger builds from code commits. Many teams start by using one shared token or key for the whole project. When that role is too broad, any user or job can change live configs. How the native harness git workflow runs The platform links your pipelines to your code host in two directions. Changes made in the visual editor write new commits back to your chosen branch. A
Git Commit Signing (GPG, SSH) + Harness Security Features: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up harness git by linking your source repo to your pipeline project. This link lets your team store pipeline files and trigger builds from code commits. Many teams start by using one shared token or key for the whole project. When that role is too broad, any user or job can change live configs.
How the native harness git workflow runs
The platform links your pipelines to your code host in two directions. Changes made in the visual editor write new commits back to your chosen branch. At the same time, git pushes send webhook events to update the platform state. This two-way sync keeps your visual pipelines and code files matching at all times.
To make this work, you create a source code manager connector in your project. You pick a network route so the platform can reach your git host. Public hosts run over the internet, while private hosts route through a local worker. You also attach a secret key or token so the connector can log in.
Next, you choose where to store the connector and secret within the platform hierarchy. You can place them at the account, group, or single project level. Each level has its own role rules that control who can use the connector. Once active, the platform tests the link and starts reading files from your branch.
Where native repository permissions fall short
Native roles do a good job of controlling who can edit pipeline settings. They also verify that your source code host is online and ready for commits. Branch rules on your git host add another check by requiring peer code reviews. Together, these controls help teams manage how code moves from a branch to a build.
Still, a shared git connector uses the same identity for every action it takes. Once a pipeline starts running, the platform checks who triggered the job at the start. It does not inspect every single command or query that the job runs next. If a script inside the repo runs a bad command, the broad role allows it.
This gap grows when pipelines touch live databases or cloud servers during a deploy. Static tokens stored in secrets managers stay valid long after the job finishes. Teams also lack a unified log that links git commits to exact database queries. Without command-level checks, one bad commit can read or drop live customer tables.
Git Commit Signing (GPG, SSH) + Harness Security Features: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Sensitive data in build logs creates another big risk for platform teams. When a deployment job queries a database, raw output often prints to the console. That output might hold customer emails, phone numbers, or payment card numbers. Standard git and pipeline roles do not rewrite those fields in the query results.
Managing secrets and roles across branches
To reduce risk, teams should split connectors across different stages of work. Never use the same git token or worker for both test and live branches. Give test jobs a read-only token so they cannot push tags back to main. Keep production secrets locked in a separate project scope with strict user groups.
You should also rotate the tokens and keys used by your git connectors often. If an engineer leaves the team, replace any shared personal tokens right away. Better yet, use short-lived app tokens from your git provider instead of personal keys. Pair these habits with strict branch locks to keep your deployment pipelines safe.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
How does two-way git sync handle merge conflicts in pipelines?
When a conflict happens, the platform blocks the sync and shows an error alert. You must pull the branch, fix the file conflict in git, and push again.
Should we use personal tokens or app tokens for the git link?
Always use dedicated app tokens or machine accounts instead of personal user tokens. Personal tokens break pipelines when that person leaves the team or loses repo roles.
Can we store pipeline files and app code in different repos?
Yes, you can keep pipeline files in a central ops repo if you prefer. Your pipeline can then pull app code from a second repo during the build.