Are you using BYOID or GAIA?
You may still need to grant SOAR admin and Chronicle API, the permissions and Roles can be set on the SOAR side so that they can have limited access to SOAR while still retaining the access to SIEM.
If you use default GCP IAM permissions, you can then create a new role in SOAR and choose the permissions for SOAR in SecOps: https://cloud.google.com/chronicle/docs/soar/admin-tasks/advanced/control-access-to-platform
Are you using BYOID or GAIA?
You may still need to grant SOAR admin and Chronicle API, the permissions and Roles can be set on the SOAR side so that they can have limited access to SOAR while still retaining the access to SIEM.
If you use default GCP IAM permissions, you can then create a new role in SOAR and choose the permissions for SOAR in SecOps: https://cloud.google.com/chronicle/docs/soar/admin-tasks/advanced/control-access-to-platform
Hi @ajohnson11
I'm trying to use the GCP IAM permissions and users groups, created within Google Admin.
I did the following:
1. I created a role (limiting that role to a single environment) in SOAR Settings >> Advanced >> IAM Role Mapping
2. I created a role with the same name in the IAM Roles of Google Cloud and gave that role the permissions that I shared above.
3. I created a group of users in Google Admin and added users to it.
4. I assigned this role name to the users group in the Google Cloud IAM page.
Without the 2 following permissions, I can't access the system with any user of that group and with these permissions enabled, the users get full access to all the environments:
chronicle.instances.generateSoarAuthJwt
chronicle.instances.soarAdmin
I'm trying to find a way to limit the access to the single environment that I assigned to that role.
Thanks
Hi @ajohnson11
I'm trying to use the GCP IAM permissions and users groups, created within Google Admin.
I did the following:
1. I created a role (limiting that role to a single environment) in SOAR Settings >> Advanced >> IAM Role Mapping
2. I created a role with the same name in the IAM Roles of Google Cloud and gave that role the permissions that I shared above.
3. I created a group of users in Google Admin and added users to it.
4. I assigned this role name to the users group in the Google Cloud IAM page.
Without the 2 following permissions, I can't access the system with any user of that group and with these permissions enabled, the users get full access to all the environments:
chronicle.instances.generateSoarAuthJwt
chronicle.instances.soarAdmin
I'm trying to find a way to limit the access to the single environment that I assigned to that role.
Thanks
Yea i believe those are required for access, you can grant those permissions in GCP IAM then use SOAR permission groups to limit access on the SOAR side: https://cloud.google.com/chronicle/docs/soar/admin-tasks/permissions/working-with-permission-groups
you can set the default landing page for this group to SIEM Search so that they start there and remove all SOAR related permissions:
Yea i believe those are required for access, you can grant those permissions in GCP IAM then use SOAR permission groups to limit access on the SOAR side: https://cloud.google.com/chronicle/docs/soar/admin-tasks/permissions/working-with-permission-groups
you can set the default landing page for this group to SIEM Search so that they start there and remove all SOAR related permissions:
Hi @ajohnson11
Following your advice, I created a new Permission Group under SOAR Settings >> Permissions, called "SIEM Only" and only enabled the "Homepage" permission, as I wasn't allowed to save that group without any permissions.
I then assigned this permission group to the IAM role of the team in SOAR Settings >> Advanced >> IAM Role Mapping.
I later added the 2 SOAR permissions to the IAM role in the associated Google Cloud IAM Role, so now I have these permissions for that role (having the same name as the one in the SOAR settings):
chronicle.dataAccessScopes.get
chronicle.dataAccessScopes.list
chronicle.instances.generateSoarAuthJwt
chronicle.instances.get
chronicle.instances.report
chronicle.instances.soarAdmin
chronicle.operations.get
chronicle.operations.list
resourcemanager.projects.get
The problem is again that once I login with one of this group's users, I have admin rights in the SOAR and I can see cases that I shouldn't be able to see. Without including these 2 permissions, I still can't access the platform with those users
Hi @ajohnson11
Following your advice, I created a new Permission Group under SOAR Settings >> Permissions, called "SIEM Only" and only enabled the "Homepage" permission, as I wasn't allowed to save that group without any permissions.
I then assigned this permission group to the IAM role of the team in SOAR Settings >> Advanced >> IAM Role Mapping.
I later added the 2 SOAR permissions to the IAM role in the associated Google Cloud IAM Role, so now I have these permissions for that role (having the same name as the one in the SOAR settings):
chronicle.dataAccessScopes.get
chronicle.dataAccessScopes.list
chronicle.instances.generateSoarAuthJwt
chronicle.instances.get
chronicle.instances.report
chronicle.instances.soarAdmin
chronicle.operations.get
chronicle.operations.list
resourcemanager.projects.get
The problem is again that once I login with one of this group's users, I have admin rights in the SOAR and I can see cases that I shouldn't be able to see. Without including these 2 permissions, I still can't access the platform with those users
Adding that I compared my platform with a partner and under SOAR Settings >>Advanced, they have "IDP GROUP Mapping", while we have "IAM Role Mapping". Theirs works and ours doesn't. I suspect now that this is the cause of the issue
Adding that I compared my platform with a partner and under SOAR Settings >>Advanced, they have "IDP GROUP Mapping", while we have "IAM Role Mapping". Theirs works and ours doesn't. I suspect now that this is the cause of the issue
"The problem is again that once I login with one of this group's users, I have admin rights in the SOAR and I can see cases that I shouldn't be able to see."
- Does the Role assigned for SIEM only have any additional roles?
Another good thing to check on this screen is the default role, and what role the case they should not have access to is assigned. If the SIEM only group inherits another role's permissions then they will see those cases too.
https://cloud.google.com/chronicle/docs/soar/admin-tasks/advanced/control-access-to-platform
The IDP Group vs IAM Role Mapping, as far as i know, only indicates if you are using Google Cloud Identity (IAM) vs an External Authentication Provider (IDP), I don't believe that would cause issues but I could be wrong. If everything checks out in the roles and permissions, i would recommend gathering a HAR file or using SAML tracer to see if you can identify what group is being passed during authentication and maybe submit a Support Case.
"The problem is again that once I login with one of this group's users, I have admin rights in the SOAR and I can see cases that I shouldn't be able to see."
- Does the Role assigned for SIEM only have any additional roles?
Another good thing to check on this screen is the default role, and what role the case they should not have access to is assigned. If the SIEM only group inherits another role's permissions then they will see those cases too.
https://cloud.google.com/chronicle/docs/soar/admin-tasks/advanced/control-access-to-platform
The IDP Group vs IAM Role Mapping, as far as i know, only indicates if you are using Google Cloud Identity (IAM) vs an External Authentication Provider (IDP), I don't believe that would cause issues but I could be wrong. If everything checks out in the roles and permissions, i would recommend gathering a HAR file or using SAML tracer to see if you can identify what group is being passed during authentication and maybe submit a Support Case.
Hi @ajohnson11
Thanks for your guidance on this.
To address your comments:
1. The SIEM only role doesn't have any additional roles accesses
2. I sent to the support the HAR (I have a case open for more than a month). No actual assistance from them.
I'm thinking now that I should probably switch to "Workforce Identify Federation", rather than IAM. Seems to me that there's a bug in the IAM method that is fairly new and maybe not really fully tested and validated
Hi @ajohnson11
Thanks for your guidance on this.
To address your comments:
1. The SIEM only role doesn't have any additional roles accesses
2. I sent to the support the HAR (I have a case open for more than a month). No actual assistance from them.
I'm thinking now that I should probably switch to "Workforce Identify Federation", rather than IAM. Seems to me that there's a bug in the IAM method that is fairly new and maybe not really fully tested and validated
Without access to the console that all sounds like it should be working. Sorry to hear support isn't being of much assistance, do you have a customer engineer that you can reach out to and see if they can escalate internally?
make sure you follow the documentation correctly when setting up an external provider so you don't risk getting locked out of your secops instance: https://cloud.google.com/chronicle/docs/onboard/configure-authentication
Adding that I compared my platform with a partner and under SOAR Settings >>Advanced, they have "IDP GROUP Mapping", while we have "IAM Role Mapping". Theirs works and ours doesn't. I suspect now that this is the cause of the issue
I think "IAM Role Mapping" in place of "IdP Group Mapping" means you are using Gaia instead of BYOID. Can you confirm that you have Google Cloud Identity in this setting?
I think "IAM Role Mapping" in place of "IdP Group Mapping" means you are using Gaia instead of BYOID. Can you confirm that you have Google Cloud Identity in this setting?
Yes. You are right, @DanDye
Should I switch to "Workforce Identity Federation"?
Seems the "Google Cloud Identity" isn't mature enough and is full of bugs
Yes. You are right, @DanDye
Should I switch to "Workforce Identity Federation"?
Seems the "Google Cloud Identity" isn't mature enough and is full of bugs
I'm using Google Cloud Identity (aka Gaia) in SecOps and have the IAM Role Mapping working. It is a bit different from Workforce Identity Federation. Firstly, the only groups that are available with Gaia listed in:
Rather than use those groups, I add my group members to a Google Group and then my IAM entry is for the email address of the Google Group.
The second part is the IAM Role Mapping. This sentence at that previous link is what unlocked that feature for me:
> Alternatively, add an email address instead of an IAM role.
So, in my IAM Role Mapping to assign the Environment, Permission, and Role, I use the user's email address rather than the Google Group email address. Once this is done, all of the access controls that have been previously mentioned work: you can disable SOAR access through the Permissions or you can limit access to a single Environment to limit what cases the user can view.
I'm using Google Cloud Identity (aka Gaia) in SecOps and have the IAM Role Mapping working. It is a bit different from Workforce Identity Federation. Firstly, the only groups that are available with Gaia listed in:
Rather than use those groups, I add my group members to a Google Group and then my IAM entry is for the email address of the Google Group.
The second part is the IAM Role Mapping. This sentence at that previous link is what unlocked that feature for me:
> Alternatively, add an email address instead of an IAM role.
So, in my IAM Role Mapping to assign the Environment, Permission, and Role, I use the user's email address rather than the Google Group email address. Once this is done, all of the access controls that have been previously mentioned work: you can disable SOAR access through the Permissions or you can limit access to a single Environment to limit what cases the user can view.
Hi @DanDye
Following your comments, I reviewed the "IAM Role Mapping" page in the SOAR settings, and found 2 things that seemed to affect the unwanted behaviour:
1. There was a role called "ChronicleSOAR Admin" that was assigned to Administrators and all the environments.
2. Default Access was also set similarly (initially).
When I started playing around with these, at some point, I saw that users were getting limited access (for example, a single environment and/or lesser or no permissions in the SOAR), mostly getting their access credentials from the new "DefaultAccess" settings, even if they belonged to groups that had specific rules, but at some point, those limitations affected all my users, including the admin and I lost complete access to the entire platform.
I tried playing around with the role assignments (Chronicle API Admin, Chronicle SOAR Admin...) directly to the different users in the project's GCP IAM page, but nothing helps. I'm completely locked out.
Any suggestion on how to regain access?
Thanks
Hi @DanDye
Following your comments, I reviewed the "IAM Role Mapping" page in the SOAR settings, and found 2 things that seemed to affect the unwanted behaviour:
1. There was a role called "ChronicleSOAR Admin" that was assigned to Administrators and all the environments.
2. Default Access was also set similarly (initially).
When I started playing around with these, at some point, I saw that users were getting limited access (for example, a single environment and/or lesser or no permissions in the SOAR), mostly getting their access credentials from the new "DefaultAccess" settings, even if they belonged to groups that had specific rules, but at some point, those limitations affected all my users, including the admin and I lost complete access to the entire platform.
I tried playing around with the role assignments (Chronicle API Admin, Chronicle SOAR Admin...) directly to the different users in the project's GCP IAM page, but nothing helps. I'm completely locked out.
Any suggestion on how to regain access?
Thanks
I think you will need to work with the support team.They will be able to help you regain admin access to SOAR settings. Be sure to tell them that you made those changes while using Google Cloud Identity/Gaia auth. It sounds like you had previously been using Workforce Identity Federation auth, so tell them about that too.
