Your GCP IAM is valuable, take care of it!

Source

In a shared responsibility model, as a customer, your Cloud Provider is responsible for the security OF the Cloud, when you are responsible for security IN the Cloud. This means you are in charge of the IAM (standing for Identity and Access management) configuration on your Cloud accounts. With great power comes great responsibility. With a powerful IAM binding, users will be able to perform actions they are not supposed to. Attackers are also looking for any Cloud misconfigurations, such as: an instance widely open on the Internet, a bucket shared publicly or an authentication key pushed on a public Git repository.

In this article, I will focus on 3 IAM topics: principle of least privilege, keys management and users management. I will try to answer the questions: “what could happen if you don’t take enough care of your IAM?” and “what can you do to prevent security issues / breaches?”. My advice will focus on GCP IAM but can be adapted to other Cloud Providers.

#01: principle of least privilege

What can happen if you don’t take care of it?

Users perform actions they are not supposed to do, like the deletion of resources for instance. Best case scenario at the project level: the deletion of an instance. Worst case scenario: the deletion of a GCP project (keep in mind that there is no guarantee that your project will be entirely restored if you need to perform this action). A service configuration error and you can face an incident on your production. Imagine if it happens at your organization level, you will face a major incident.

What can you do to prevent security issues / breaches?

• Restrict the permissions applied at the organization or top-folder levels to a limited number of users. And give them only the roles they need. The usage of the Organization Administrator role should be very restricted. Give to your network team only the privilege to manage network configurations. Same for your teams in charge of backup, FinOps, and so on. Build a permission matrix to identify all permissions needed (need-to-know principle).
• Never use the primitive roles, especially the owner and editor ones. Do you really know someone who is using all GCP services?
• Even if GCP has been providing an IAM Deny feature for a few weeks now, it will not cover 100% of your use cases yet (you can only deny a limited list of permissions in the current version). I strongly recommend detecting (and why not auto remediating) the usage of roles you want to control. Many tools are available to do that. Maybe you already operate a CSPM tool, which will allow you to create a policy to detect the usage of roles you want to monitor. Alternatively, you can use a combination of GCP services, such as: Log sink looking for the “setIamPolicy” action + Pub/Sub notification + Cloud Functions to alert your team and why not remediate automatically. This example of combination enables one to detect a misconfiguration and act in a few seconds for auto remediation. If you are not confident with an auto remediation solution, set up an alert to start, and act upon it.
• Another nice GCP feature, free to use by the way, is IAM recommender. Based on an observation period of 90 days, this feature will recommend the removal of unused permissions. It is available at all levels of your GCP organization. You can also export the recommendations to BigQuery and provide a DataStudio report to your GCP users.
• Keep in mind that the service accounts created by default when you activate the Compute Engine or the App Engine APIs have the Editor role. You can disable this configuration by using a GCP organization policy:

Source

• Apply permissions at the resource level when it’s possible. If you need to give access for users to a specific bucket, don’t give them the permissions at the project level, but only at the required bucket. Maybe you have another bucket hosted on the GCP project that users are not supposed to access!
• GCP also offers a cool feature called Policy analyzer. It allows you to find out which users have access to your GCP organization like: determine which users can access a resource or which users have some permissions / roles. This feature is very useful and can help you to make a deep-dive analysis of all levels of your GCP organization.

#02: keys management

What can happen if you don’t take care of it?

The major risk you face here is the key leakage. A key can leak in many different ways, the most common one is a key pushed on a public Git repository. Attackers are using bots to detect this, and once they get the key, they try to exploit it. If unfortunately, you don’t apply the principle of least privilege on your key, imagine the damages: creation of resources to mine bitcoin, data leakage or even ransomware, compromission of your GCP organization or deletion of your resources.

What can you do to prevent security issues / breaches?

• Avoid creating a Service Account key for everything. You don’t need one to authorize a Service Account of project A to access a GCS located on project B. You just need to give the right permissions to your Service Account. Same if you need to authenticate from AWS or Github. You can use Workload Identity Federation service to avoid the creation of a service account key.
• If you can do it, forbid the creation of Service Account keys. An organization policy “constraints/iam.disableServiceAccountKeyCreation” allows to forbid this action

Source

Another organization policy allows to disable the Service Account key upload.

Source

Of course, the application of these 2 organization policies will depend on your company organization and it will not always be so easy to implement.

• Use a secret management tool, whatever the kind: Vault, GCP Secret Manager, etc. Credentials are probably shared every day in your company, a secret management tool will allow you to avoid key leakage.
• Be ready to face a key leakage! GCP is able to detect a key leak on a public Git repository. I already wrote a medium article explaining how we exploit this alert at Decathlon. Of course, a leak can be done in another way. This is why it’s important to prepare your security incident response team.
• My last advice is to control the age of your key. Define a lifetime for your Service Account key and control it regularly, whatever the tool: CSPM, home-made development, etc. If you are comfortable with this, you can even imagine to automatically delete a key older than a number of days.

#03: users management

What can happen if you don’t take care of it?

A lack of user control will lead to security issues / breaches. There is nothing worse than an account shared between several people. Passwords will probably be stored in plain-text and never be changed. One disgruntled ex-employee may try to cause damages to your organization, steal data or sell the access to a group of attackers. Consequences for your organization can be huge. Another issue can be the discovery of this user / password by someone else. It can be an employee who will try to perform actions by himself to go faster and cause damages to your organization unintentionally.

What can you do to prevent security issues / breaches?

• Avoid using local accounts. Link your GCP organization to your Identity Provider (IdP) if you have one. If not, make Cloud Identity as your IdP.
• If you can do it, use an account dedicated to administration tasks.
• Avoid using human generic accounts. One account = one user. You have to be able to identify who does what and when (principle of traceability). If several users are sharing the same account, how are you supposed to do it? If your application is managed by a 3rd party company, create one account for every teammate of this company.
• Implement strong password policies. If you are using your own IdP, you probably already have one. If you choose to use Cloud Identity as your IdP:

1. Set the lengths of password (GCP supports between 8 to 100 characters, choose the length which makes sense for you).
2. Choose if users can reuse the same password.
3. Select a period of time after which the password expires.
4. Force users to change their passwords.

• Whatever the type of users, implement a MFA solution (Multi Factor Authentication). A various set of MFA exists: email / sms code, physical key, authenticator application, biometric verification. Maybe you already have one linked to your Identity Provider. If you choose to use Cloud Identity as your IdP, Google is supporting several MFA solutions.
• Keep control of which organization / user has permissions to your GCP organization. Don’t authorize users provided from an external organization (or worse a free gmail account). You don’t know if the 3rd party company will have the same requirements in terms of user management (generic user, password policy, MFA, log management, user deletion process).
• If you can do it, restrict the adding of users not linked to your organization to your IAM policies. An organization policy allows this. Be careful with it, there is a list of known issues mostly related to the usage of some specific Google services. It’s not always so easy to implement it!

Source

• Control the IAM bindings applied on users not linked to your organization. Some tools allow it (like a CSPM for example). If you don’t have a one and you are comfortable with development, you can catch all logs type “setIamPolicy” and create a routine to check if the permission has been applied to a user linked or not to your organization. And you can imagine to go further by implementing an automatic remediation. Don’t forget to take in consideration permissions applied to Google Service Accounts.

Conclusion

I tried to be as exhaustive as possible. Maybe you will have another idea to protect your GCP IAM configuration. And maybe some points mentioned in this article will not be applicable to your organization.

Keep in mind that a secure cloud implies a strong cloud IAM configuration. Attackers are looking for misconfigurations to compromise your information system and IAM can be one of them!