Gitea Scoped Workflows
You set up gitea scoped workflows by binding narrow tokens and runner labels to jobs. This limits each pipeline step to only the repos and targets it needs. Many teams start by giving one shared admin key to every runner. Broad keys let any compromised workflow read private code or change live databases. Scoping down workflow access stops a single bad script from hurting your whole stack. How gitea scoped workflows operate in practice Gitea Actions runs jobs using runner agents that poll the
Access Request Workflows: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up gitea scoped workflows by binding narrow tokens and runner labels to jobs. This limits each pipeline step to only the repos and targets it needs. Many teams start by giving one shared admin key to every runner. Broad keys let any compromised workflow read private code or change live databases. Scoping down workflow access stops a single bad script from hurting your whole stack.
How gitea scoped workflows operate in practice
Gitea Actions runs jobs using runner agents that poll the server for work. Each job receives a temporary token and a set of secret variables. By default, a workflow token might hold broad read and write rights. Teams restrict this by defining exact permission scopes inside the workflow file. You can set a job to read code without letting it push packages. You can also store secrets at the repo level instead of the org level. Repo secrets ensure a test app cannot read keys meant for billing tools. Runner labels add another wall between test jobs and prod jobs. You tag runners by zone and bind sensitive secrets only to prod runners.
What native workflow scoping solves and what keeps the session active
Native scoping stops workflows from grabbing secrets that belong to other repos. It also keeps untrusted pull requests from writing back to the main branch. This setup handles who logs in and which runner picks up the job. Still, native scopes do not watch what happens after a target session starts. A deployment job still needs a real database user or cloud role to work. Once the runner logs in to Postgres or Kubernetes, Gitea steps back. The runner now holds full rights for that database role during the whole job. If a build script has a flaw, it can drop tables or dump rows. Static secrets stored in Gitea also sit idle until someone rotates them by hand. Native controls decide which job gets the key, not what queries run in flight.
Closing the gap for database and cluster tasks
Pipelines often run schema migrations, data checks, or cluster rollouts during a release. Granting a runner direct network reach and a strong password creates a high risk. Teams can reduce this risk by splitting build steps from live target steps. Build jobs only compile code and push images using narrow repo tokens. Deploy jobs then run through strict session rules that check every single command. When a workflow queries a database, data masking can rewrite emails or card numbers. This keeps sensitive customer fields out of build logs and test outputs. Teams also gain a clear audit log of every statement the runner sent.
Access Request Workflows: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
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 do I stop fork pull requests from reading secrets in Gitea?
Gitea blocks secret access for pull requests from forked repos by default. Keep this rule on and never run untrusted code on runners with prod keys.
Should I store workflow secrets at the org level or repo level?
Store secrets at the repo level whenever you can to limit blast radius. Use org secrets only for shared tools that need low permissions across projects.
Why are runner labels not enough to secure production deployments?
Any user who can edit the workflow file can change the runner label tag. Combine runner labels with branch protection rules and strict target command checks.