google / google/agents-cli

agents-cli deploy has no --ingress flag for Cloud Run, blocking internal-ingress deploys required by enterprise security policy

Open
#87 1 comment 0 reactions 1 assignee Claimed by @asrujana-44 View on GitHub
Dominant language
Python
Stars
5.9k
Forks
660
PR merge metrics
No merged PRs in 30d

Description

### What is your feature suggestion?

Add an `--ingress` flag to `agents-cli deploy` for the `cloud_run` target, mapping to `gcloud run deploy --ingress` (`all` | `internal` | `internal-and-cloud-load-balancing`).

### Description

`agents-cli deploy --deployment-target cloud_run` can only create services with Cloud Run's default ingress of `all`. The Cloud Run branch of `cmd_deploy.py` builds a closed argument list for `gcloud run deploy` — `--project`, `--region`, `--source`/`--image`, the shape flags applied by `_shape_flag`, `--no-allow-unauthenticated`, `--no-cpu-throttling`, `--port`, `--update-env-vars` and `--labels`. There is no `--ingress`, and nothing else influences it.

Note that `--agent-gateway-ingress` is unrelated. It binds an Agent Gateway on Agent Runtime and has no effect on Cloud Run's ingress setting.

### Reproduce

```bash
agents-cli scaffold create my-agent --agent adk --deployment-target cloud_run --region us-east1 --cicd-runner skip
cd my-agent
agents-cli deploy --project --dry-run
```

Observed — the printed command carries no `--ingress`, so the service is created with `all`:

```
Would run: gcloud run deploy my-agent --project --region us-east1 --source . --memory 4Gi --cpu 1 --min-instances 0 --max-instances 10 --concurrency 8 --no-allow-unauthenticated --no-cpu-throttling --update-env-vars '...' --labels '...'
```

### Requested fix

Add `--ingress [all|internal|internal-and-cloud-load-balancing]` to `agents-cli deploy`, forwarded to `gcloud run deploy` for the `cloud_run` target.

### What will this enable you to do?

**`--ingress=internal` is frequently a hard security requirement in enterprise environments.** The agent must not be reachable from the public internet. Only callers classified internal may reach it — services in the same project, VPC networks with Private Google Access, on-premises hosts over Cloud VPN or Interconnect, and projects inside the same VPC Service Controls perimeter.

This is not a hypothetical configuration. Gemini Enterprise can call an A2A agent on a Cloud Run service deployed with `--ingress=internal`, given `roles/run.invoker` for the Discovery Engine service agent. It is a supported, working architecture that `agents-cli` currently cannot produce.

**Deploy-then-flip is not an adequate workaround, and in some projects it is not a workaround at all.**

Without an org policy, you can run `agents-cli deploy` and then `gcloud run services update --ingress=internal`. That leaves a window during which the agent is publicly reachable. In a regulated environment that window is itself an audit finding.

With `constraints/run.allowedIngress` enforced, the create is rejected outright. There is no service to update afterwards, so `agents-cli deploy` cannot be used at all.

### Additional context

**Relationship to #83.** That issue is the same shape for a different target — a missing flag makes an entire class of deploys impossible, while the underlying capability already exists one layer down. Two instances in a week suggests the flag surface under-covers projects operating under org policy constraints.

**Relationship to #20, and what I am *not* asking for.** #20 asked for the `EXTRA_ARGS` passthrough removed in 0.1.2. I am not requesting that, and I understand the reasoning given there for avoiding it. This request is deliberately the alternative offered in that thread:

> one thing we can do is examine if it would make sense to promote it to be part of the `--deploy` interface

`--ingress` is a small, stable, Cloud Run-native concept with three documented values. It is a first-class flag, not a general escape hatch, and it does not couple the `agents-cli` interface to an arbitrary surface.

**On the `--dry-run` workaround suggested in #20.** It works for a one-off, but it has two problems. It breaks CI/CD for the reason given in #20 — you cannot pause a pipeline to edit a command. And the printed command is not directly runnable, because `redact_command` in `deploy/_utils.py` masks every env-var and label value:

```
Would run: gcloud run deploy ... --update-env-vars 'GOOGLE_GENAI_USE_VERTEXAI=***,GOOGLE_CLOUD_PROJECT=***,...' --labels 'created-by=***'
```

Every value must be reconstructed by hand before the command will run.

**Minor, in the same code path.** `agents-cli deploy --help` states that the `cloud_run` target dispatches to `gcloud beta run deploy`. The command actually constructed is `gcloud run deploy`, with no `beta`.

Version: `agents-cli` 1.4.2.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.