That must've been such an exciting moment to have someone say hello.
Chilling too.
Chilling too.
If SRE can write a file to the filesystem, they can totally copy the database files out too.
I completely support SRE being able to log into instances for debugging, but them being able to do that without leaving an audit trail visible to me, the data owner, isn't up to modern standards IMO.
This seems much more likely than OP's exploration being detected in realtime, then someone SSHing into the container manually to put a message.
Disclaimer: I work at Google, not on Cloud SQL, and don't know anything specific about that greetings.txt.
I interpreted the "new" as meaning that it wasn't there before
In rare cases SRE's reach out to ISE's who contact us on their behalf. In this case a file was added. I personally don't see any reason why this would be a bad thing, it's a managed service and we tried to attack it after all. No data was removed, nor is there any indication that there are no audit trails. I hold both the ISE's and SRE's in extremely high regard. (If you try to Hunt for bugs in GCP you will find out why)
That button should create for them a fully logged SSH connection to the VM, and the data owner should be notified that SRE has connected. The data owner should then be able to see the commands executed via the SSH connection, and also request an explanation of what the SRE was doing.
The vast majority of instances are going to be things like "your instance hit a SIGSEGV, we logged in to grab the crash dump" or "your instance had a much higher than usage than all other users. We logged in to run tools to find where is was going".
To be more serious, it would be unacceptable for me that an employee can, for whatever reason, access my instance without my express permission and oversight. Even crash dumps could contain very sensitive information.
But it should be possible for a client to audit all accesses, and the audit logging system be robust enough to catch evil employees.
If your threat model is a single rogue employee, auditing systems address the issues. If your threat model is "the whole company works against you", you probably shouldn't be using any company to host your infra, so host it yourself, because there's no way to be secure in that situation.