-
Notifications
You must be signed in to change notification settings - Fork 724
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Remove "compute.disableGuestAttributesAccess" org policy #1019
feat: Remove "compute.disableGuestAttributesAccess" org policy #1019
Conversation
Can you please add some context as to why we are making this change so we can add that to the commit? |
Here is some context on the justification for the change, feel free to reuse from this below: This policy was originally enforced to help mitigate data exfiltration threats where software running on a VM publishes data from disk to the VM guest attributes, which could potentially be read by another service with IAM role access to read VM metadata. This exfiltration threat is relatively niche because it requires an attacker to both deploy malicious software on a VM, and have a privileged Compute IAM role. API-based data exfiltration risks can be better addressed by designing a VPC Service Controls perimeter around sensitive data. On the other hand, guest attributes enable various useful workflows for automation, and guest attributes can help mitigate MITM attacks during remote VM access by storing host keys by enabling guest attributes. Considering the balance of utility compared to risk, we no longer recommend this policy as a default setting for all customers who adopt the blueprint. However, we encourage customers to review the security controls and customize the blueprint as appropriate for their requirements. |
Hello folks.
This PR is to remove compute.disableGuestAttributesAccess org policy.
This policy was originally enforced to help mitigate data exfiltration threats where software running on a VM publishes data from disk to the VM guest attributes, which could potentially be read by another service with IAM role access to read VM metadata.
This exfiltration threat is relatively niche because it requires an attacker to both deploy malicious software on a VM,
and have a privileged Compute IAM role. API-based data exfiltration risks can be better addressed by designing a VPC Service Controls perimeter around sensitive data.
On the other hand, guest attributes enable various useful workflows for automation, and guest attributes can help mitigate MITM attacks during remote VM access by storing host keys by enabling guest attributes.
Considering the balance of utility compared to risk, we no longer recommend this policy as a default setting for all customers who adopt the blueprint.
However, we encourage customers to review the security controls and customize the blueprint as appropriate for their requirements.