Cloud Run Permissions
You set up cloud run permissions by assigning Identity and Access Management roles. These roles control who can start containers and what resources those containers reach. Teams often start by using the default compute service account for every app. That default role carries broad editor rights across your entire cloud project. If one container has a flaw, an attacker can reach all project data. You must replace broad defaults with narrow roles for each service you run. How cloud run permissio
AI Agent Permissions: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up cloud run permissions by assigning Identity and Access Management roles. These roles control who can start containers and what resources those containers reach. Teams often start by using the default compute service account for every app. That default role carries broad editor rights across your entire cloud project. If one container has a flaw, an attacker can reach all project data. You must replace broad defaults with narrow roles for each service you run.
How cloud run permissions work in your project
Cloud Run uses two distinct permission layers to keep your containers safe. The first layer controls who can call or trigger your running container. You manage this ingress rule with an invoker role on the service itself. Public web apps let all users call the service URL over the internet. Internal APIs restrict this role to specific user accounts or partner services. When a request arrives, the platform checks the caller token before running code.
The second layer controls what your container can do inside your cloud project. Every service runs as a specific Google Cloud service account identity at runtime. This runtime identity holds roles that allow reading buckets, secrets, or cloud databases. Best practice says you should make one custom service account per app. You then grant that account only the exact roles the app needs. This setup stops a single broken app from touching unrelated cloud data.
Separating deploy roles from runtime identities
A common mistake happens when teams mix developer roles with runtime app roles. An engineer needs permission to deploy a new container image to the platform. To deploy, that engineer also needs permission to attach a service account. If the engineer can attach a high-privilege account, they can escalate their own rights. They could deploy code that reads private keys or changes project settings.
You fix this by scoping the service account user role to specific accounts. Developers should only attach dedicated app identities, never admin or default project accounts. Build pipelines should also use their own separate identity to push new releases. This separation keeps human user rights distinct from automated container runtime rights. You get a clean audit trail showing who deployed the code and when.
AI Agent Permissions: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What native roles solve and where gaps remain
Native cloud roles do a great job of locking down service startup. They make sure only approved callers trigger your app over the network. They also stop a container from reaching storage buckets it does not own. For service-to-service calls, native identity checks handle the initial handshake very well.
Still, cloud roles only check who logs in at the front door. Once a container or engineer connects to a database, IAM steps back. The cloud role cannot see what individual SQL statements or commands do next. If a developer runs a debug task, IAM cannot block a destructive drop table command. It also cannot rewrite sensitive fields like emails, phone numbers, or card numbers. A valid role grants full visibility into every row that the database account holds by default. Teams still need a way to inspect and filter live commands in flight.
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
Why should I avoid the default compute service account?
The default account often holds broad editor rights across your whole cloud project. Sharing it lets any single app read or change data meant for others.
How do I let one service call another private service?
Grant the calling service account the invoker role on the receiving service. The caller must include a valid identity token in its request headers.
Do cloud roles hide sensitive database columns from developers?
No, cloud roles only decide if an account can reach the database instance. They do not filter queries or mask fields like emails or national IDs.