Automatically disable publicly exposed Service Account

[Bitdoctor]

[UPDATE] Rephrasing my question

Automatically disable publicly exposed Service Account <--

Got the above notice. I have an Org, but original owner of the space never moved apps there. For me, there are no major policies in the Org side, aside from whatever default policies and now this new thing that has just now become a default - the one we're discussing. 

Thanks @DamianS , not the answer I'm looking for, so I've updated my question.

I am rephrasing my question: Will my apps move with all their existing settings and config, generally speaking, if I select "migrate" and then move them under my bare Org that has nothing but default policies? I believe this is true, so then I could set an actual policy, such as aforementioned "WAIT_FOR_ABUSE" key.

[DamianS]

Hello @Bitdoctor  ,Welcome on Google Cloud Community.

When you move projects from " No Organization" into Organization, all Organization policies configured at Organization level, will affect your projects. So you can assume, that "ORGANIZATION" have policies like Service Account Key Creation or Automatically disable publicly exposed Service Account enforced for ENTIRE organization.  Will app break? According to documentation depends how this policy will be configured: 

• DISABLE_KEY: If Google Cloud detects an exposed key, it will automatically disable the key. It also creates a Cloud Audit Logs event and sends a notification about the exposed key to project owners and security contacts.

  Note: Starting on June 16, 2024, if you don't set a value for this constraint, Google Cloud will default to the behavior described for DISABLE_KEY. <- Yes, it might make app break.

• WAIT_FOR_ABUSE: Google Cloud won't proactively disable exposed keys. However, Google Cloud might still disable exposed keys if they're used in ways that adversely affect the platform. Regardless of whether the exposed key is disabled, Google Cloud creates a Cloud Audit Logs event and sends a notification about the exposed key to project owners and security contacts. <- No, it will notify you about key leak. 

--
cheers,
DamianS
LinkedIn medium.com Cloudskillsboost

[Bitdoctor]

Thanks. For me, there are no major policies in the Org side, aside from whatever default policies and now this new thing that has just now become a default - the one we're discussing. 

I should have rephrased my question:

Will my apps move with all same settings and config, generally speaking, if I select "migrate" and then move them under my bare Org that has nothing but default policies?

[patilshubham007]

Hello,

I tried to use the WAIT_FOR_ABUSE option which is IAM-> Organization policies -> Service account key exposure response -> Manage policy -> Allow -> Override parent's policy -> Replace -> Add a Rule -> Custom -> Allow -> WAIT_FOR_ABUSE [ Value ] -> Set Policy --

Says -> Failed to save the policy 

Has someone already implemented above?

[Bitdoctor]

I have not yet tried to set it.

It should give a reason, such as "Not part of an Org?" But if you have pop-up blocking, you may not be seeing that message. Is all your stuff under an Organization?

If not, and it's like mine, all under "No Organization," then yes, it will fail.

In that case, you'd have to fill out the Google form and create an organization, then, for each app, choose the three-dot to the far right of the app, choose "Migrate," then move your apps under the created Organization. [UPDATE] AFTER you have the apps under an Org, then you can apply the mentioned WAIT_FOR_ABUSE setting or other Org policies as desired.

[DamianS · Accepted solution]

@Bitdoctor ,

My understanding in this matter is :
If you have organization, where for example Disable Service Account Key Upload is enforced, you will be not allowed to upload SA keys for existing and newly created projects. I'm assuming the same for moving project from "No Org" to "Org", especially because of this message:

damian_sztankowski@cloudshell:~ (test-425218)$ gcloud beta projects move test-425218 --organization ORG_ID 
Your project will be moved. This may alter the policies enforced on your Project, either exposing your Project to more security risk through looser polices or cause an outage through stricter polices. See these public notes on 
policy implications for more information: https://cloud.google.com/resource-manager/docs/creating-managing-folders#moving-folders-policy-considerations and 
https://cloud.google.com/resource-manager/docs/migrating-projects-billing#note_on_policy_implications. Once moved, you can move the Project again so long as you have the appropriate permissions. See our public documentation for
 more information: https://cloud.google.com/resource-manager/docs/creating-managing-folders#moving_a_project_into_a_folder

So I believe, that your app can have an outage due to more restricted Organization Policies. Highly recommend to assess MIgration Plan, to avoid surprises after migration.
https://cloud.google.com/resource-manager/docs/handle-special-cases#migrating_projects_no_org

--
cheers,
DamianS
LinkedIn medium.com Cloudskillsboost

[Bitdoctor]

UPDATE: I will accept Damian's answer, since it does cover many aspects of the question, in a broad sense. My main concern is less about policies, but more about: If I move an app, do the app's own settings get fully cleared (wiped out), for example, if I have storage settings and certificates in my app config, will those get cleared if I move the app? I think the "outage" possibility you mentioned is a valid point, but the "general app config and settings" will be preserved if I move the app, except that any differences in policies may impact the app. Thanks!

Thanks Damian. Again, there are no policies on either "No Org" or on the Org itself. So, due to that fact, there is no such setting in place such as "disable SA key upload." The only policy that will be in place in both places will be the one discussed earlier, which would only disable any key discovered to be exposed in public repos. I don't really have a way to test the changes, unless I move the app during a low use period, test it, and then move it back (if necessary) to No Org. I possibly could clone the app and test it that way. I will give you a Like, since you gave some quality info, but you haven't yet answered the updated question: When moving an app from No Org to an Org, does the app retain it's existing config and settings? I am already aware that some policies may be affected, but that is not part of my revised question. Thank you very much, I have enjoyed your informative replies!