mirror of
https://github.com/google-gemini/gemini-cli.git
synced 2026-02-01 22:48:03 +00:00
Add new enterprise instructions (#8641)
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
This commit is contained in:
@@ -159,6 +159,50 @@ This results in the following merged configuration:
|
|||||||
By using the system settings file, you can enforce the security and
|
By using the system settings file, you can enforce the security and
|
||||||
configuration patterns described below.
|
configuration patterns described below.
|
||||||
|
|
||||||
|
### Enforcing system settings with a wrapper script
|
||||||
|
|
||||||
|
While the `GEMINI_CLI_SYSTEM_SETTINGS_PATH` environment variable provides
|
||||||
|
flexibility, a user could potentially override it to point to a different
|
||||||
|
settings file, bypassing the centrally managed configuration. To mitigate this,
|
||||||
|
enterprises can deploy a wrapper script or alias that ensures the environment
|
||||||
|
variable is always set to the corporate-controlled path.
|
||||||
|
|
||||||
|
This approach ensures that no matter how the user calls the `gemini` command,
|
||||||
|
the enterprise settings are always loaded with the highest precedence.
|
||||||
|
|
||||||
|
**Example wrapper script:**
|
||||||
|
|
||||||
|
Administrators can create a script named `gemini` and place it in a directory
|
||||||
|
that appears earlier in the user's `PATH` than the actual Gemini CLI binary
|
||||||
|
(e.g., `/usr/local/bin/gemini`).
|
||||||
|
|
||||||
|
```bash
|
||||||
|
#!/bin/bash
|
||||||
|
|
||||||
|
# Enforce the path to the corporate system settings file.
|
||||||
|
# This ensures that the company's configuration is always applied.
|
||||||
|
export GEMINI_CLI_SYSTEM_SETTINGS_PATH="/etc/gemini-cli/settings.json"
|
||||||
|
|
||||||
|
# Find the original gemini executable.
|
||||||
|
# This is a simple example; a more robust solution might be needed
|
||||||
|
# depending on the installation method.
|
||||||
|
REAL_GEMINI_PATH=$(type -aP gemini | grep -v "^$(type -P gemini)$" | head -n 1)
|
||||||
|
|
||||||
|
if [ -z "$REAL_GEMINI_PATH" ]; then
|
||||||
|
echo "Error: The original 'gemini' executable was not found." >&2
|
||||||
|
exit 1
|
||||||
|
fi
|
||||||
|
|
||||||
|
# Pass all arguments to the real Gemini CLI executable.
|
||||||
|
exec "$REAL_GEMINI_PATH" "$@"
|
||||||
|
```
|
||||||
|
|
||||||
|
By deploying this script, the `GEMINI_CLI_SYSTEM_SETTINGS_PATH` is set within
|
||||||
|
the script's environment, and the `exec` command replaces the script process
|
||||||
|
with the actual Gemini CLI process, which inherits the environment variable.
|
||||||
|
This makes it significantly more difficult for a user to bypass the enforced
|
||||||
|
settings.
|
||||||
|
|
||||||
## Restricting tool access
|
## Restricting tool access
|
||||||
|
|
||||||
You can significantly enhance security by controlling which tools the Gemini
|
You can significantly enhance security by controlling which tools the Gemini
|
||||||
@@ -434,7 +478,39 @@ prompted to switch to the enforced method. In non-interactive mode, the CLI will
|
|||||||
exit with an error if the configured authentication method does not match the
|
exit with an error if the configured authentication method does not match the
|
||||||
enforced one.
|
enforced one.
|
||||||
|
|
||||||
## Putting it all together: Example system `settings.json`
|
### Restricting logins to corporate domains
|
||||||
|
|
||||||
|
For enterprises using Google Workspace, you can enforce that users only
|
||||||
|
authenticate with their corporate Google accounts. This is a network-level
|
||||||
|
control that is configured on a proxy server, not within Gemini CLI itself. It
|
||||||
|
works by intercepting authentication requests to Google and adding a special
|
||||||
|
HTTP header.
|
||||||
|
|
||||||
|
This policy prevents users from logging in with personal Gmail accounts or other
|
||||||
|
non-corporate Google accounts.
|
||||||
|
|
||||||
|
For detailed instructions, see the Google Workspace Admin Help article on
|
||||||
|
[blocking access to consumer accounts](https://support.google.com/a/answer/1668854?hl=en#zippy=%2Cstep-choose-a-web-proxy-server%2Cstep-configure-the-network-to-block-certain-accounts).
|
||||||
|
|
||||||
|
The general steps are as follows:
|
||||||
|
|
||||||
|
1. **Intercept Requests**: Configure your web proxy to intercept all requests
|
||||||
|
to `google.com`.
|
||||||
|
2. **Add HTTP Header**: For each intercepted request, add the
|
||||||
|
`X-GoogApps-Allowed-Domains` HTTP header.
|
||||||
|
3. **Specify Domains**: The value of the header should be a comma-separated
|
||||||
|
list of your approved Google Workspace domain names.
|
||||||
|
|
||||||
|
**Example header:**
|
||||||
|
|
||||||
|
```
|
||||||
|
X-GoogApps-Allowed-Domains: my-corporate-domain.com, secondary-domain.com
|
||||||
|
```
|
||||||
|
|
||||||
|
When this header is present, Google's authentication service will only allow
|
||||||
|
logins from accounts belonging to the specified domains.
|
||||||
|
|
||||||
|
## Putting it all together: example system `settings.json`
|
||||||
|
|
||||||
Here is an example of a system `settings.json` file that combines several of the
|
Here is an example of a system `settings.json` file that combines several of the
|
||||||
patterns discussed above to create a secure, controlled environment for Gemini
|
patterns discussed above to create a secure, controlled environment for Gemini
|
||||||
|
|||||||
Reference in New Issue
Block a user