Gitea Actions Secrets
You set up gitea actions secrets by saving encrypted values inside your repo settings. Your workflow runners then read these values as variables during a build run. Teams often store database keys and cloud tokens in this central store. When roles are too broad, any workflow in that group can read production keys. A bad script or pull request can then use those keys to change live data. How gitea actions secrets work in your build pipeline Gitea lets you store sensitive keys at the user, grou
K8s Secrets Management + GitHub Actions Security: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up gitea actions secrets by saving encrypted values inside your repo settings. Your workflow runners then read these values as variables during a build run. Teams often store database keys and cloud tokens in this central store. When roles are too broad, any workflow in that group can read production keys. A bad script or pull request can then use those keys to change live data.
How gitea actions secrets work in your build pipeline
Gitea lets you store sensitive keys at the user, group, or repo level. You write the value once, and the server hides it from the screen. You cannot read the value back from the web page after you save it. When a build event happens, the server checks which keys that repo can use. It sends those keys over the network to the runner machine. The runner loads the values into memory for the active build step. The build script then uses the key to log in to a database or cloud host. If a key exists at both the group and repo level, the repo value wins. This setup helps teams share common keys while keeping repo keys separate. The runner also tries to scrub the exact secret string from the build logs.
Where native secret storage falls short in production
Native secret storage solves the problem of plain text keys in your source code. Developers do not have to paste database passwords into their scripts anymore. Yet this setup only controls how the runner gets the key at the start. Once the runner logs in to your database or server, Gitea steps back. The build job now holds a live session with whatever role that key owns. Gitea does not check which SQL queries or shell commands the runner sends next. A flawed script can drop a table or read customer emails and card numbers. Also, static keys sit in the secret store for months without rotation. If a runner prints a key using base64 encoding, the log filter misses it. Anyone who can read the build log now owns that long-lived key. Static secrets decide who logs in, not what commands do in flight.
Best practices for scoping workflow keys
You can lower your risk by keeping keys at the lowest possible level. Save production keys inside single repos instead of sharing them across the whole group. Create separate database roles for each build job so one runner cannot touch everything. Give those roles only the exact read or write rights the job needs. Rotate your stored keys on a regular schedule so old values expire fast. Check your workflow files during code review to see which steps call sensitive variables. Lock down your main branches so untrusted code cannot run with production keys. Keep your test and live systems on separate accounts with different secret values.
K8s Secrets Management + GitHub Actions Security: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
Can you view a secret value after saving it in Gitea?
No, the server hides the value as soon as you save it. You can only overwrite the old secret with a brand new value.
What happens when a repo secret shares a name with a group secret?
The build runner uses the repo secret instead of the group secret. More specific scopes override broader scopes during a workflow run.
Do workflow logs hide secret values by default?
Yes, the runner replaces exact matches of the secret string with stars in logs. Still, changed or encoded versions of the secret can still leak into text output.