If you are responsible for administering Cloud SQL instances, securing your databases is one of your top priorities. However, as the number of users using your Cloud SQL instances grows, you may find yourself challenged to keep access locked down. More Cloud SQL users means more work ensuring that the right users have the appropriate access to the proper database instances. In the past, you may have addressed this challenge by separating Cloud SQL instances into distinct projects, isolating access along project boundaries. However, this approach can lead to a sprawling number of projects that can be burdensome to manage. Moreover, separating instances by project doesn’t work when access privileges must vary within groups of instances that should stay in the same project, such as replication groups.
We’re happy to announce that Cloud SQL support for IAM Conditions is now generally available. IAM Conditions are part of Cloud Identity and Access Management (IAM), the service that Cloud SQL and other Google Cloud services rely on for determining access to cloud resources. You can now add a condition as a property of an IAM policy binding, describing the circumstances in which a principal should have access to a Cloud SQL role. IAM Conditions lets you authorize actions based on a variety of attributes. For example, you can restrict user access to certain dates and times or limit user actions to only Cloud SQL resources with certain names.
From our partners:
In addition, Cloud SQL support for Tags is now generally available. Tags are resources in the form of key-value pairs that can be used to organize and govern access to other Google Cloud resources. You can administer Tags through Resource Manager and can reference Tags in IAM policy bindings to grant conditional access to resources with those tag bindings. Cloud SQL instances can either inherit a tag through the project or folder they are located in or be assigned a tag directly.
You can use IAM Conditions and Tags together to more securely and easily govern administrative and connection access to Cloud SQL.
Attach a Tag to a Cloud SQL Instance
To illustrate with an example, let’s say that you’re a database administrator at BuyLots, an ecommerce company. You have a primary database instance called us-payments that collects and stores payment information for the BuyLots’ ecommerce application. You’ve set up a read replica called us-payments-replica to enable your new data scientist Su to perform data analysis. You want Su to be able to log in to the read replica using IAM database authentication, which uses IAM to authenticate database users. However, you don’t want Su to be able to log in to the primary instance, since you want to protect that instance from reporting use.
First, you decide to use Tags to demarcate operations and reporting databases. You go to the Console and select the BuyLots organization scope and then head to IAM & Admin and click on the Tags page.
There, you click the ‘+ Create Tag’ button to define a new tag. The tag is named databaseType. For tag values, you add operations and reporting.
You go back to the Tags page, click on the databaseType tag. You click into each of the two Tag values and jot down the namespaced names for later use. You have just created your first tag!
Next, you fire up the gcloud command line tool to attach your new tags to your Cloud SQL instances. You use Google Cloud Resource Manager to attach the operations tag to us-payments and the reporting tag to us-payments-replica. In your command, you use the namespaced names for the tag value parameter, as well as the Cloud SQL instances’ full resource names for the parent parameter.
gcloud alpha resource-manager tags bindings create \--tag-value=274544955910/databaseType/operations \--parent=//sqladmin.googleapis.com/projects/buylots/instances/us-payments \--location=us-central1
gcloud alpha resource-manager tags bindings create \--tag-value=274544955910/databaseType/reporting \--parent=//sqladmin.googleapis.com/projects/buylots/instances/us-payments-replica \--location=us-central1
You have now finished attaching tags to your Cloud SQL instances.
Grant Conditional IAM Access
It is time for you to grant Su access to just the us-payments-replica database instance and other reporting databases. You head to the IAM page in the Console and add a new binding to the BuyLots project’s IAM policy. After clicking the “Edit member” icon for Su’s member account, you select the role ‘Cloud SQL Instance User’ for Su, which contains the necessary permissions for Su to log in using IAM database authentication.
Importantly, you add a condition to the Policy binding in order to ensure Su may only access reporting instances like us-payments-replica. You select the ‘Tag’ resource attribute for the Condition type, pick ‘matches’ for the operator, and insert the reporting tag value namespaced name you jotted down earlier.
Now, when Su is ready to analyze payments data in the BuyLots project, she’ll only be able to use IAM database authentication to connect to us-payments-replica. Su won’t have access to us-payments. You can rest easy knowing you have secured your Cloud SQL instances!
Learn More
With IAM Conditions and Tags, you have powerful new tools to institute finer-grained administrative and connection access control for your Cloud SQL instances. To learn more about IAM Conditions, see the IAM Conditions documentation. To learn more about Tags, see the Tags documentation.
By: Akhil Jariwala (Product Manager)
Source: Google Cloud Blog
For enquiries, product placements, sponsorships, and collaborations, connect with us at [email protected]. We'd love to hear from you!
Our humans need coffee too! Your support is highly appreciated, thank you!
