Gemini Enterprise has a different licensing model than Workspace, Cloud Identity and other admin.google.com license types. It's licenses are:
- managed per-GCP project and per region.
- assigned and unaasigned from users using the Discovery Engine API, not Enterprise License Manager API.
- need a GCP project to have billing enabled (though there's a free 30 day trial).
I've created a simple Python script that can do most of what makes sense for GAM to manage the licenses. We don't need to worry about things like moving licenses between products / regions / apps as the admin can do that in the cloud console. See:
https://gist.github.com/jay0lee/5c8632cb8883268cbadd2ea8106b7d49
Because GE licensing has special requirements I think the way we go about this needs to be different:
- turning discoveryengine.googleapis.com on for a project requires a billing account for the project which GAM projects typically don't have. Nor should we assume the admin wants to manage GE licenses for the GAM project itself. As such, we should not turn discoveryengine.googleapis.com on for the GAM project, instead GAM can use
the regular GAM project but then set the target GE project as the "quota project". See:
https://gist.github.com/jay0lee/5c8632cb8883268cbadd2ea8106b7d49#file-ge_license_mgr-py-L119
-
We don't want GAM to store sensitive API scopes like cloud-platform in the regular admin token and since this is GCP and GAM already has a service account, we should just expect the admin to assign the correct IAM roles on the target GE project to GAM's service account and always authenticate as the service account itself (no DwD, no user auth). Using the service account is also safer because even if it's credentials were stolen, the attacker would only have access to do what the service account has explicitely been granted (as opposed to our admin user credentials that may be super adminl, GCP org admin, etc).
-
The main goal here would be to make managing GE licenses as simple as it is to manage Workspace license with GAM "one liners" like sync licenses, add/remove, print, etc.
-
since this is going to require some setup on the GAM user's part with GCP permissions we should try to offer helpful errors on permission errors that describe what IAM roles the account needs to be granted. Let's allow users to make those changes themselves though as GAM trying to change GCP IAM itself is risky.
Gemini Enterprise has a different licensing model than Workspace, Cloud Identity and other admin.google.com license types. It's licenses are:
I've created a simple Python script that can do most of what makes sense for GAM to manage the licenses. We don't need to worry about things like moving licenses between products / regions / apps as the admin can do that in the cloud console. See:
https://gist.github.com/jay0lee/5c8632cb8883268cbadd2ea8106b7d49
Because GE licensing has special requirements I think the way we go about this needs to be different:
the regular GAM project but then set the target GE project as the "quota project". See:
https://gist.github.com/jay0lee/5c8632cb8883268cbadd2ea8106b7d49#file-ge_license_mgr-py-L119
We don't want GAM to store sensitive API scopes like
cloud-platformin the regular admin token and since this is GCP and GAM already has a service account, we should just expect the admin to assign the correct IAM roles on the target GE project to GAM's service account and always authenticate as the service account itself (no DwD, no user auth). Using the service account is also safer because even if it's credentials were stolen, the attacker would only have access to do what the service account has explicitely been granted (as opposed to our admin user credentials that may be super adminl, GCP org admin, etc).The main goal here would be to make managing GE licenses as simple as it is to manage Workspace license with GAM "one liners" like sync licenses, add/remove, print, etc.
since this is going to require some setup on the GAM user's part with GCP permissions we should try to offer helpful errors on permission errors that describe what IAM roles the account needs to be granted. Let's allow users to make those changes themselves though as GAM trying to change GCP IAM itself is risky.