> After GCPW installation, the device appears in the Admin console Windows device list after the user signs in with their Google Account for the first time.
We use G Suite at work (legacy decision) and it really kills me just how poorly the G Suite product team seems to understand enrollment and authorization workflows.
No, I don't want to allow every device to register itself into the device list. If I'm managing installations of organization-owned devices, then I want to pre-register the device into a device whitelist that I maintain before I allow that device unfettered access to protected resources.
This is right up there with other dumb moves like requiring AWS roles to be added per-user for SAML login and functionally being unable to setup G Suite as an OIDC IdP for Kubernetes because G Suite refuses to expose group membership (or even more importantly, transitive group membership) to service providers.
If Google uses G Suite internally then I have zero idea how they manage to actually get anything done, unless they have a lot of in-house automation that they haven't open-sourced. It doesn't make sense unless they're not eating their own dogfood.
I agree with many of your complaints, this article[1] from Latacora comes to mind. However, a lot of the "good stuff" that fixes some of these problems already exist and are fully implemented in GSuite, they just happen to be locked behind the priciest service tier[2].
I've had many frustrations like these, because if you're on the lower tiers of GSuite you pretty much have to DIY using their API. But, if you choose to bite the bullet and pay up, your life will be way better in many of these aspects.
Also other things about the "GSuite way" just diverge philosophically from the standard IT operation playbooks, if you haven't already, I suggest giving the BeyondCorp paper[3] a read. Most of their IdP-related products build on top of these concepts, rather than plain "directory-management style" ITOps.
> it really kills me just how poorly the G Suite product team seems to understand enrollment and authorization workflows.
> No, I don't want to allow every device to register itself into the device list. If I'm managing installations of organization-owned devices, then I want to pre-register the device into a device whitelist that I maintain before I allow that device unfettered access to protected resources.
you have a best practice, but narrow vision.
the very, very, very large majority of "enterprises" (certainly SMB) do not have an inventory of devices. even if they do, they have to onboard them into the G Suite inventory somehow. just like MDM solutions always have an "open enrollment" method, this is a way to jumpstart that process. by setting a point in time at which open enrollment is allowed, rolling it out, then closing said open enrollment, inventory collection is easily streamlined without needing any IT skill. you could then audit your inventory to make sure there is just 1 device per user. last step, you disable the auto enrollment option.
But possibly not for other Kubernetes deployments. I wonder if this is a business decisions or the consequence of nonpublic technical details.
(Disclosure: I used to work at Google including on GCP, but I have no inside info related to this discussion and haven't worked there in just over 5 years.)
We use G Suite at work (legacy decision) and it really kills me just how poorly the G Suite product team seems to understand enrollment and authorization workflows.
No, I don't want to allow every device to register itself into the device list. If I'm managing installations of organization-owned devices, then I want to pre-register the device into a device whitelist that I maintain before I allow that device unfettered access to protected resources.
This is right up there with other dumb moves like requiring AWS roles to be added per-user for SAML login and functionally being unable to setup G Suite as an OIDC IdP for Kubernetes because G Suite refuses to expose group membership (or even more importantly, transitive group membership) to service providers.
If Google uses G Suite internally then I have zero idea how they manage to actually get anything done, unless they have a lot of in-house automation that they haven't open-sourced. It doesn't make sense unless they're not eating their own dogfood.