I have linked GA360 to Big Query. I do have a service account added to GCP as per documentation. The account I used has Project Owner permissions as required to link to said project.
Can I remove the Project Owner permissions from the GCP account once the link has been established in GA360? I do not want that account to have such a high access level to the project.
I did run a test on a small scale and it worked but I am not willing to risk a transfer failure on all of the data in production.
Yes, you can remove the permissions from the account you used to link GA360 to BQ.
The permission is only required for the time of setting this up.
It is not being checked whether the account which set up a connection is still active or has the same rights.
We have had multiple views linked by different accounts, of which most are not in the team anymore and therefore do not have "owner" rights anymore. The exports still work though (which makes sense, given that a company might keep using GA and the exports but part ways with the internal/external employee who sat it up).
Related
I want to be able to add domains to Firebase hosting with the API instead of the web UI, is that possible?
I want to add potentially hundreds of domains, is there a domain limit per project in Firebase?
As far as I can tell from the entire CLI documentation, there isn't any way to do this.
Lets take a step back and consider what the web UI process involves i.e. the generation of a TXT record to add to your DNS records, after verifying the presence of said TXT record on the domain, providing A records that you (authorized owner) add to allow redirecting to your firebase hosted site.
In my opinion, this very manual back and forth is necessary as a security measure. The only way it is taken out of the equation via the CLI is by providing a means for you to authenticate ownership of a domain (registered with any one of many domain registrars), and being granted authorization to change your A records. These are both outside the scope of Firebase, and could potentially introduce severe security flaws. Regardless, even if it existed, it would still have to be step-by-step and somewhat manual via CLI rather than the single command it sounds like you're looking for.
It is not possible to add custom domains automatically through an API at this time.
Nor would it allow you to create a reseller or multi-tenant project (i.e. connect a large number of domains or subdomains dynamically) since you cannot connect more than about 36 domains connected to one project.
It's possible to add domains using Firebase Hosting Rest Api. I am not sure why they didn't put it on their official website but I checked today and it works. https://developers.google.com/resources/api-libraries/documentation/firebasehosting/v1beta1/java/latest/com/google/api/services/firebasehosting/v1beta1/FirebaseHosting.Sites.Domains.html
Answer that I've received from Firebase support:
There is no API yet that would allow you to add custom domains, it was
requested as a feature before but unfortunately we have no more
information on that - so for now, only the Console UI allows you to do
it.
When it comes to the limits, in a project, a custom domain is
attached to a site - there can be 36 sites per project, and for one
site there is no hard limit, but we recommend not exceeding 20 custom
domains. You can experience technical issues with SSL certs when you
exceed 20 domains per site, which we won’t be able to troubleshoot
since the system was not designed for such use cases.
My organization set up Cloud SQL as the default for Google App Maker about one month ago. In the last week, we have been unable to preview or publish apps that use Cloud SQL data sources, including the sample applications which worked perfectly before. The failure occurs during the authorization process. When previewing or publishing an app, Google App Maker displays a dialog stating "Deploying this app requires authorization". Next it prompts the user for their Google account and then requests approval for the necessary authorizations (e.g., "Manage the data in your Google SQL Service instances"). After approving the authorization, the prompts to authorize begin over with the dialog stating "Deploying this app requires authorization".
Observations:
We have repeated this problem on multiple different computers, networks, and four different user accounts.
In the SQL cloud console, our Cloud SQL instance shows new databases being created for each app along with new database-specific user accounts
All of the databases appear as expected when I log directly into the Cloud SQL database using phpMyAdmin
Other apps which don't use a Cloud SQL datasource work fine, including an app that uses a calculated data source which is hosted in the same Cloud SQL instance
The only errors in the Stack driver logs for the Cloud SQL database showed "INFO" level communication errors with the database (aborted connection...Got an error reading communication packets)
I'm unable to find Stack driver logs for the apps because I cannot preview or publish them (either option would provide a link to the Stack driver logs)
There are now approximately 20 databases in our SQL instance (mostly associated with simple app tests) and we have only used 1 GB of 10 GB of space in our SQL instance
I haven't seen any related problems on the Google Issue Tracker for Google App Maker
I'd appreciate any help or suggestions on what to check in order to resolve this issue.
I posted an issue to Google Issue Tracker and Google corrected the problem. They also provided a workaround if this problem happens again.
Here is the response from the Google development team posted on Google Issue Tracker: https://issuetracker.google.com/issues/145345198
It's great to hear your up and working again! We are aware of this issue and are working through a longer term fix. The specific bug appears to be related to some changes made in the Google Cloud session policy control that may have rolled out to your domain recently interacting with AppMaker in a way that was not expected. We've spent time diagnosing the underlying issue and we beleive we know the root cause. I suspect your domain admin did a version of the workaround below.
Without getting too far into the details, the specific bug is that for a Deployer of an AppMaker application, if the Google Cloud Session policy is set with any expiration time, the returned token AppMaker sees is invalid, triggering a loop in AppMaker trying to generate a valid security token. Historically, these session tokens never expired but recently there was beta feature launch that allowed domain admins to set them to expire. We strongly suspect your domain recently set this expiration policy explicitly and that's what is causing the bug.
The good news is that these policies are overridable per Organizational Unit and we have tested that OUs which have the original classic Never Expire setting do, in fact, allow AppMaker to work.
My suspicion is that your domain admin has reverted recent, local changes to your organizational policy under the admin.google.com console, specifically under Security > Google Cloud session control (Beta).
If this happens again, here the workaround we would recommend. Note you don't need to do this if you're currently up and working. You will need the help of someone with admin.gogole.com powers, specifically User and Organizational Unit powers at your organization. It is a slight increase in security risk but it restores some classic behavior that was standard until recently.
The summary of the workaround is to override the Google Cloud session control expiration setting such that individuals who need access to AppMaker deployments can have it. To mitigate systemic security risk, this is best done by creating a limited purpose Organizational Unit with just that setting different than the parent OU settings.
The workaround is to:
Contact someone in your domain with Admin powers for your Google for Business license.
Have your admin proceed to https://admin.google.com. The actions below need to be performed by a domain admin.
Under the Users section, identify the specific user account that needs the ability to deploy AppMaker Apps.
Identify the Organizational Unit of that Appmaker dev user and make a note of it.
Under the Organization Units settings, locate the Organization Unit you identified above.
Create a new Organization Unit underneath that user's current Organizational Unit with some descriptive identifying it as special w.r.t AppMaker. So for Developers, make something like DevelopersWhoAreAlsoAppMakerDevs.
Back under the Users tab, locate the user from step 3. Move this user into the new Organizational Unit you've just created. This change can take a while to propagate.
-Interlude- At this point, you've made a new Organizational Unit for just that individual and added them to it. You can certainly add multiple people to that OU, especially if they're already in the same parent OU. Use your discretion as to what amount of Organizational rework you wish to pursue. You may not be using OUs at all or you may decide to just turn off this control for the whole domain. It's up to you.
Under admin.google.com's Security settings, locate the Google Cloud session control (beta) settings.
Under this panel, from the dropdown menu on the left, locate the Organization Unit you just created.
Be sure to select ONLY the OU you intend to change.
Change the "Google Cloud Console and Google Cloud SDK session control" from expiring to "Session Never Expires".
Save your changes.
The account you selected in step 3 should now be able to deploy AppMaker apps.
It appears this OU change is only necessary for the deployer of an AppMaker app, not an individual user. Note also that if you have multiple AppMaker developers who all have different current OU settings, you may need to create multiple daughter OUs to avoid a sudden radical shift in OU settings for an individual account.
I have published a deployment that runs with the developer account. In the deployment settings I have a role called "Supervisors". I have assigned a google group to that role, directorssupervisors#domain.com.
When the deployment runs with the developer account, everythings works fine. But when the deployment is ran by any other user, I get the following error:
appmaker.application.permission.GroupsPermission: Error reading group directorssupervisors#domain.com. Note: The deployer developeraccount#domain.com must have access to this group.
Exception:
Exception: You do not have permission to view the member list for the group: directorssupervisors#domain.com
The group settings are configured so that everyone in the domain can view the membership; moreover, the developer account is a member of the group.
I have checked the information provided in this post and also in this post but none of them seem to help. The developer account was added to the group more than 72 hours ago and the deployment was published more than 48 hours ago.
So far, everything is leading me to believe this is a bug. Before I open a support ticket with the G Suite AppMaker team, I would like to know if anyone has had the same issue and if there was a solution to it.
Thanks in advance for your help!
UPDATE:
Now it is also showing the error when the app is ran by the developer account!
It so happens that the AppMaker team corrected a buggy behavior that allowed the reading of email addresses from groups without having the permission properly set up in the group settings. To make the app work again I had to make sure the group permission had the proper access for viewing email addresses; Group Settings -> Permissions -> Access permissions -> View Email Addresses.
Once I changed the permission to All members of the group, I proceeded to republish the app and then it worked again.
Update 12/31/2019
On top of the already mentioned above, you also need to make sure that the group is visible to all members in the organization:
Group Settings -> Permissions -> Basic permissions -> Group Visibility.
So I'm looking at setting up Google Analytics (GA) for the first time. My app will have three environments (initially):
Dev
UAT
Prod
w.r.t GA I was curious as to whether best practice is to:
Create 3 distinct GA accounts; 1 for each env; or
Create 1 GA account and somehow keep the data separate
According to this accepted + upvoted answer, it sounds like the latter is the preferred way of managing GA across environments. And that the solution is to add filters/views to your configurations so that data from each envrironment gets filtered/routed to the correct environment-specific reports.
My only potential problem with this solution is that I need my developers to have access to the dev data in GA, product & QA to have access to the UAT data, and only a handful of key business/marketing folks to have access to the prod data. Devs should never have access to UAT or Prod data, etc.
I took a look around GA's permissions documentation and I don't see any way of granting users access to specific filters/views. Anybody have any idea how I could create a "Developer" role inside GA and only grant read access to filters/views/etc tagged or marked as being part of the development env?
Otherwise I'll need to sadly create 3 distinct GA accounts, one for each env :-/.
My GA setup is very similar to yours. I have a single GA account that has multiple properties such as web-dev, web-stg, web-prd, mobile-stg, mobile-prod, etc. Each of those properties have a minimum of two views. The first view I title 'Raw Data' as no filters should ever be set on this view to have access to the raw data collected by GA. My second view I call my 'Filtered View', which is the view I look at 99% of the time. In the filtered view, I exclude company IPs, bot IPs, vendor IPs, etc.
To answer your question about access to each property and view, they can be set on any level from the admin menu under the user management option.
I'd like to set up a GA export to BigQuery. I'm following the steps as described here. In step 2.5, it states:
Add the service account to your project.
Add analytics-processing-dev#system.gserviceaccount.com as a member of
the project, and ensure that permission at the project level is set to
Editor (as opposed to BigQuery Data Editor). Editor permission is
required in order to export data from Analytics to BigQuery.
However, I'm reluctant to provide such elevated permissions ("project editor" will allow full access to all resources in my project) on my project.
Why does the GA export need such elevated permissions in order to just talk to BigQuery, and is there a way to provide minimum permissions to the service account instead?
I suspect the documentation is outdated, and hasn't been kept up to date with changes to BigQuery's IAM and permissions.
You do not need to give "Project Editor" access to the service account. And in fact, providing such elevated security permission on a generic service account is violating the principle of least privileges.
Instead, create a custom role within IAM with the following minimum BigQuery permissions for the export to work. This way, it can only interact with BigQuery in your project:
bigquery.datasets.create (allows GA to create the dataset for export)
bigquery.jobs.create (allows GA to run load jobs)
bigquery.tables.create (allow GA to create the tables)
bigquery.tables.delete (allows GA to delete intraday tables)