--- title: Cloud Infrastructure Security: Risks and Best Practices description: Cloud infrastructure security covers the compute, network, identity, storage, and control-plane layers that customers configure beneath their applications,... canonical: https://daily.dev/posts/cloud-infrastructure-security-risks-and-best-practices-ryokyqq1x twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Cloud Infrastructure Security: Risks and Best Practices | daily.dev og:description: Cloud infrastructure security covers the compute, network, identity, storage, and control-plane layers that customers configure beneath their applications,... og:url: https://daily.dev/posts/cloud-infrastructure-security-risks-and-best-practices-ryokyqq1x og:image: https://api.daily.dev/og/posts/RyokYQQ1X.png og:image:alt: Cloud Infrastructure Security: Risks and Best Practices og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Cloud Infrastructure Security: Risks and Best Practices **[Orca Security Blog](https://daily.dev/sources/orca-security-blog)** · 16 min read · 1 upvotes · 0 comments ## Summary Cloud infrastructure security covers the compute, network, identity, storage, and control-plane layers that customers configure beneath their applications, with the boundary set by the shared responsibility model. Four controls dominate risk: workload identity, network exposure, image and patch state, and control-plane logging, and every major provider ships permissive defaults for each — AWS security groups allow all outbound traffic, Azure network security groups allow all internal traffic, and Google Cloud's default Compute Engine service account can hold the Editor role. Five infrastructure-specific threats are outlined: default-driven exposure, unreviewed machine identity permissions, metadata service abuse (IMDSv2 hop limits, Azure/GCP metadata headers), stale golden images, and shadow resources created outside infrastructure as code. Best practices include inventorying workload identity, closing egress, enforcing IMDSv2, treating images as the unit of patching, applying organization-wide guardrails, mandating infrastructure as code, and enabling audit logging. A comparison table maps these controls across AWS, Azure, and Google Cloud, and the piece closes with an FAQ and a pitch for Orca's Unified Data Model and agentless SideScanning platform. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### What are the default outbound network rules for a new AWS security group versus Azure and Google Cloud? A newly created AWS security group has no inbound rules but one outbound rule allowing all traffic. Azure network security groups ship with default rules allowing all traffic within the virtual network and all outbound traffic to the internet. Google Cloud's implied VPC firewall rules deny all ingress but allow all egress, meaning outbound is open by default on all three providers. _Comparing cloud network defaults across providers is easier when relevant guides surface together on daily.dev._ ### Does Google Cloud's default Compute Engine service account get the Editor role on the project? It may, depending on organization policy, since older or default-configured Google Cloud organizations grant the default Compute Engine service account the Editor role on the project; newer organizations disable that automatic grant by default. This over-permissioned default means compromising a workload using that service account can grant broad lateral access across the project. _Anyone auditing service account permissions across cloud providers can track these defaults on daily.dev._ ### How do AWS, Azure, and Google Cloud protect their instance metadata endpoints from SSRF-based credential theft? Azure requires a Metadata: true header and Google Cloud requires a Metadata-Flavor: Google header on metadata requests, while AWS instances accept either IMDSv1 or IMDSv2 by default unless the AMI sets ImdsSupport to v2.0. IMDSv2 adds session tokens and a default response hop limit of 1, which blocks a compromised container from reaching the endpoint through an SSRF flaw. _Developers hardening cloud workloads against SSRF can follow provider-specific metadata guidance on daily.dev._ ## Similar posts on daily.dev - [Cloud Application Security Best Practices for DevSecOps](https://daily.dev/posts/cloud-application-security-best-practices-for-devsecops-xzkxk76fn) · Orca Security Blog · 0 upvotes · 0 comments - [The Hidden Risks Lurking in Your Cloud Infrastructure](https://daily.dev/posts/the-hidden-risks-lurking-in-your-cloud-infrastructure-jc51bs8el) · freeCodeCamp · 0 upvotes · 0 comments - [How Google Cloud detects, contains, and protects against emerging threats](https://daily.dev/posts/how-google-cloud-detects-contains-and-protects-against-emerging-threats-znvhdqka4) · Google Cloud · 1 upvotes · 0 comments - [Guide to Cloud Application Security: Must-Knows and No-No’s](https://daily.dev/posts/guide-to-cloud-application-security-must-knows-and-no-no-s-4rjvrqgud) · Huntress Blog · 0 upvotes · 0 comments - [What is Multi-Cloud Security? Challenges & Best Practices](https://daily.dev/posts/what-is-multi-cloud-security-challenges-best-practices-0vfddgu0v) · Spacelift · 0 upvotes · 0 comments --- Tags: [#security](https://daily.dev/tags/security), [#aws](https://daily.dev/tags/aws), [#azure](https://daily.dev/tags/azure), [#gcp](https://daily.dev/tags/gcp) [View this post on daily.dev](https://daily.dev/posts/cloud-infrastructure-security-risks-and-best-practices-ryokyqq1x) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Cloud Infrastructure Security: Risks and Best Practices","url":"https://daily.dev/posts/cloud-infrastructure-security-risks-and-best-practices-ryokyqq1x","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/cloud-infrastructure-security-risks-and-best-practices-ryokyqq1x"},"datePublished":"2026-08-13T11:41:53.235Z","dateModified":"2026-09-14T06:05:09.426Z","description":"Cloud infrastructure security covers the compute, network, identity, storage, and control-plane layers that customers configure beneath their applications,...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/5fd13cdbb79c75650e4b7755e3cdf47f?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/5fd13cdbb79c75650e4b7755e3cdf47f?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Orca Security Blog","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Orca Security Blog","logo":"https://media.daily.dev/image/upload/s--kkQFNboJ--/f_auto,q_auto/v1780213281/logos/orca-security-blog?_a=BAMAMiWQ0","url":"https://daily.dev/sources/orca-security-blog"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/cloud-infrastructure-security-risks-and-best-practices-ryokyqq1x","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":1},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"security,aws,azure,gcp","timeRequired":"PT16M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Orca Security Blog","item":"https://daily.dev/sources/orca-security-blog"},{"@type":"ListItem","position":3,"name":"Cloud Infrastructure Security: Risks and Best Practices"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/cloud-infrastructure-security-risks-and-best-practices-ryokyqq1x#faq","mainEntity":[{"@type":"Question","name":"What are the default outbound network rules for a new AWS security group versus Azure and Google Cloud?","acceptedAnswer":{"@type":"Answer","text":"A newly created AWS security group has no inbound rules but one outbound rule allowing all traffic. Azure network security groups ship with default rules allowing all traffic within the virtual network and all outbound traffic to the internet. Google Cloud's implied VPC firewall rules deny all ingress but allow all egress, meaning outbound is open by default on all three providers. Comparing cloud network defaults across providers is easier when relevant guides surface together on daily.dev."}},{"@type":"Question","name":"Does Google Cloud's default Compute Engine service account get the Editor role on the project?","acceptedAnswer":{"@type":"Answer","text":"It may, depending on organization policy, since older or default-configured Google Cloud organizations grant the default Compute Engine service account the Editor role on the project; newer organizations disable that automatic grant by default. This over-permissioned default means compromising a workload using that service account can grant broad lateral access across the project. Anyone auditing service account permissions across cloud providers can track these defaults on daily.dev."}},{"@type":"Question","name":"How do AWS, Azure, and Google Cloud protect their instance metadata endpoints from SSRF-based credential theft?","acceptedAnswer":{"@type":"Answer","text":"Azure requires a Metadata: true header and Google Cloud requires a Metadata-Flavor: Google header on metadata requests, while AWS instances accept either IMDSv1 or IMDSv2 by default unless the AMI sets ImdsSupport to v2.0. IMDSv2 adds session tokens and a default response hop limit of 1, which blocks a compromised container from reaching the endpoint through an SSRF flaw. Developers hardening cloud workloads against SSRF can follow provider-specific metadata guidance on daily.dev."}}]} ```