> ## Documentation Index
> Fetch the complete documentation index at: https://docs.codeant.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Terraform

<AccordionGroup>
  <Accordion title="Excluding users or groups activities from audit logs is security-sensitive">
    <div class="paragraph">
      <p>logs service records administrative activities and accesses to Google Cloud resources of the project. It is important to enable audit logs to be able to investigate malicious activities in the event of a security incident.</p>
    </div>

    <div class="paragraph">
      <p>Some project members may be exempted from having their activities recorded in the Google Cloud audit log service, creating a blind spot and reducing the capacity to investigate future security events.</p>
    </div>

    <CodeGroup>
      ```terraform Bad theme={null}
      resource "google_project_iam_audit_config" "example" {
      project = data.google_project.project.id
      service = "allServices"
      audit_log_config {
      log_type = "ADMIN_READ"
      exempted_members = [ # Sensitive
        "user:rogue.administrator@gmail.com",
      ]
      }
      }
      ```

      ```terraform Fix theme={null}
      resource "google_project_iam_audit_config" "example" {
      project = data.google_project.project.id
      service = "allServices"
      audit_log_config {
      log_type = "ADMIN_READ"
      }
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Assigning high privileges Azure Active Directory built-in roles is security-sensitive">
    <div class="paragraph">
      <p>offers built-in roles that can be assigned to users, groups, or service principals.
      Some of these roles should be carefully assigned as they grant sensitive permissions like the ability to reset passwords for all users.</p>
    </div>

    <div class="paragraph">
      <p>An Azure account that fails to limit the use of such roles has a higher risk of being breached by a compromised owner.</p>
    </div>

    <div class="paragraph">
      <p>This rule raises an issue when one of the following roles is assigned:</p>
    </div>

    <div class="ulist">
      <ul>
        <li>
          <p>Application Administrator</p>
        </li>

        <li>
          <p>Authentication Administrator</p>
        </li>

        <li>
          <p>Cloud Application Administrator</p>
        </li>

        <li>
          <p>Global Administrator</p>
        </li>

        <li>
          <p>Groups Administrator</p>
        </li>

        <li>
          <p>Helpdesk Administrator</p>
        </li>

        <li>
          <p>Password Administrator</p>
        </li>

        <li>
          <p>Privileged Authentication Administrator</p>
        </li>

        <li>
          <p>Privileged Role Administrator</p>
        </li>

        <li>
          <p>User Administrator</p>
        </li>
      </ul>
    </div>

    <CodeGroup>
      ```terraform Bad theme={null}
      resource "azuread_directory_role" "example" {
      display_name = "Privileged Role Administrator" # Sensitive
      }

      resource "azuread_directory_role_member" "example" {
      role_object_id   = azuread_directory_role.example.object_id
      member_object_id = data.azuread_user.example.object_id
      }
      ```

      ```terraform Fix theme={null}
      resource "azuread_directory_role" "example" {
      display_name = "Usage Summary Reports Reader"
      }

      resource "azuread_directory_role_member" "example" {
      role_object_id   = azuread_directory_role.example.object_id
      member_object_id = data.azuread_user.example.object_id
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Creating GCP SQL instances without requiring TLS is security-sensitive">
    <div class="paragraph">
      <p>tances offer encryption in transit, with support for TLS, but insecure connections are still accepted. On an unsecured network, such as a public network, the risk of traffic being intercepted is high. When the data isn’t encrypted, an attacker can intercept it and read confidential information.</p>
    </div>

    <div class="paragraph">
      <p>When creating a GCP SQL instance, a public IP address is automatically assigned to it and connections to the SQL instance from public networks can be authorized.</p>
    </div>

    <div class="paragraph">
      <p>TLS is automatically used when connecting to SQL instances through:</p>
    </div>

    <div class="ulist">
      <ul>
        <li>
          <p>The <a href="https://cloud.google.com/sql/docs/mysql/connect-admin-proxy">Cloud SQL Auth proxy</a>.</p>
        </li>

        <li>
          <p>The <a href="https://cloud.google.com/sql/docs/mysql/connect-overview#languages">Java Socket Library</a>.</p>
        </li>

        <li>
          <p>The built-in mechanisms in the <a href="https://cloud.google.com/appengine/docs">App Engine</a> environments.</p>
        </li>
      </ul>
    </div>

    <CodeGroup>
      ```terraform Bad theme={null}
      resource "google_sql_database_instance" "example" { # Sensitive: tls is not required
      name             = "noncompliant-master-instance"
      database_version = "POSTGRES_11"
      region           = "us-central1"

      settings {
      tier = "db-f1-micro"
      }
      }
      ```

      ```terraform Fix theme={null}
      resource "google_sql_database_instance" "example" {
      name             = "compliant-master-instance"
      database_version = "POSTGRES_11"
      region           = "us-central1"

      settings {
      tier = "db-f1-micro"
      ip_configuration {
        require_ssl = true
        ipv4_enabled = true
      }
      }
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Granting highly privileged GCP resource rights is security-sensitive">
    <div class="paragraph">
      <p>ged resource rights to users or groups can reduce an
      organization’s ability to protect against account or service theft. It prevents
      proper segregation of duties and creates potentially critical attack vectors on
      affected resources.</p>
    </div>

    <div class="paragraph">
      <p>If elevated access rights are abused or compromised, both the data that the
      affected resources work with and their access tracking are at risk.</p>
    </div>

    <CodeGroup>
      ```terraform Bad theme={null}
      data "google_iam_policy" "admin" {
      binding {
      role = "roles/run.admin" # Sensitive
      members = [
        "user:name@example.com",
      ]
      }
      }

      resource "google_cloud_run_service_iam_policy" "policy" {
      location = google_cloud_run_service.default.location
      project = google_cloud_run_service.default.project
      service = google_cloud_run_service.default.name
      policy_data = data.google_iam_policy.admin.policy_data
      }
      ```

      ```terraform Fix theme={null}
      resource "google_cloud_run_service_iam_binding" "example" {
      location = google_cloud_run_service.default.location
      project = google_cloud_run_service.default.project
      service = google_cloud_run_service.default.name
      role = "roles/run.admin" # Sensitive
      members = [
      "user:name@example.com",
      ]
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Excessive granting of GCP IAM permissions is security-sensitive">
    <div class="paragraph">
      <p>CP IAM permissions can allow attackers to exploit an
      organization’s cloud resources with malicious intent.</p>
    </div>

    <div class="paragraph">
      <p>To prevent improper creation or deletion of resources after an account is
      compromised, proactive measures include both following GCP Security Insights
      and ensuring custom roles contain as few privileges as possible.</p>
    </div>

    <div class="paragraph">
      <p>After gaining a foothold in the target infrastructure, sophisticated attacks
      typically consist of two major parts.
      First, attackers must deploy new resources to carry out their malicious intent.
      To guard against this, operations teams must control what unexpectedly appears
      in the infrastructure, such as what is:</p>
    </div>

    <div class="ulist">
      <ul>
        <li>
          <p>added</p>
        </li>

        <li>
          <p>written down</p>
        </li>

        <li>
          <p>updated</p>
        </li>

        <li>
          <p>started</p>
        </li>

        <li>
          <p>appended</p>
        </li>

        <li>
          <p>applied</p>
        </li>

        <li>
          <p>accessed.</p>
        </li>
      </ul>
    </div>

    <div class="paragraph">
      <p>Once the malicious intent is executed, attackers must avoid detection at all
      costs.
      To counter attackers' attempts to remove their fingerprints, operations teams
      must control what unexpectedly disappears from the infrastructure, such as what
      is:</p>
    </div>

    <div class="ulist">
      <ul>
        <li>
          <p>stopped</p>
        </li>

        <li>
          <p>disabled</p>
        </li>

        <li>
          <p>canceled</p>
        </li>

        <li>
          <p>deleted</p>
        </li>

        <li>
          <p>destroyed</p>
        </li>

        <li>
          <p>detached</p>
        </li>

        <li>
          <p>disconnected</p>
        </li>

        <li>
          <p>suspended</p>
        </li>

        <li>
          <p>rejected</p>
        </li>

        <li>
          <p>removed.</p>
        </li>
      </ul>
    </div>

    <div class="paragraph">
      <p>For operations teams to be resilient in this scenario, their organization must
      apply both:</p>
    </div>

    <div class="ulist">
      <ul>
        <li>
          <p>Detection security: log these actions to better detect malicious actions.</p>
        </li>

        <li>
          <p>Preventive security: review and limit granted permissions.</p>
        </li>
      </ul>
    </div>

    <div class="paragraph">
      <p>This rule raises an issue when a custom role grants a number of sensitive permissions
      (read-write or destructive permission) that is greater than a given parameter.</p>
    </div>

    <CodeGroup>
      ```terraform Bad theme={null}
      resource "google_project_iam_custom_role" "example" {
      permissions = [ # Sensitive
      "resourcemanager.projects.create", # Sensitive permission
      "resourcemanager.projects.delete", # Sensitive permission
      "resourcemanager.projects.get",
      "resourcemanager.projects.list",
      "run.services.create", # Sensitive permission
      "run.services.delete", # Sensitive permission
      "run.services.get",
      "run.services.getIamPolicy",
      "run.services.setIamPolicy",  # Sensitive permission
      "run.services.list",
      "run.services.update",  # Sensitive permission
      ]
      }
      ```

      ```terraform Fix theme={null}
      resource "google_project_iam_custom_role" "example" {
      permissions = [
      "resourcemanager.projects.get",
      "resourcemanager.projects.list",
      "run.services.create",
      "run.services.delete",
      "run.services.get",
      "run.services.getIamPolicy",
      "run.services.list",
      "run.services.update",
      ]
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Google Cloud load balancers SSL policies should not offer weak cipher suites">
    <div class="paragraph">
      <p>There are three managed profiles to choose from: \`COMPATIBLE (default), MODERN and RESTRICTED:</p>
    </div>

    <div class="ulist">
      <ul>
        <li>
          <p>The RESTRICTED profile supports a reduced set of cryptographic algorithms, intended to meet stricter compliance requirements.</p>
        </li>

        <li>
          <p>The MODERN profile supports a wider set of cryptographic algorithms, allowing most modern clients to negotiate TLS.</p>
        </li>

        <li>
          <p>The COMPATIBLE profile supports the widest set of cryptographic algorithms, allowing connections from older client applications.</p>
        </li>
      </ul>
    </div>

    <div class="paragraph">
      <p>The MODERN and COMPATIBLE\` profiles allow the use of older cryptographic algorithms that are no longer considered secure and are susceptible to attack.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```terraform Bad theme={null}
      resource "google_compute_ssl_policy" "example" {
      name            = "example"
      min_tls_version = "TLS_1_2" 
      profile         = "COMPATIBLE" # Noncompliant
      }
      ```

      ```terraform Fix theme={null}
      resource "google_compute_ssl_policy" "example" {
      name            = "example"
      min_tls_version = "TLS_1_2" 
      profile         = "RESTRICTED"
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Enabling Attribute-Based Access Control for Kubernetes is security-sensitive">
    <div class="paragraph">
      <p>zation, Attribute-Based Access Control (ABAC), on Google Kubernetes Engine resources can reduce an
      organization’s ability to protect itself against access controls being compromised.</p>
    </div>

    <div class="paragraph">
      <p>For Kubernetes, Attribute-Based Access Control has been superseded by Role-Based Access Control.
      ABAC is not under active development anymore and thus should be avoided.</p>
    </div>

    <CodeGroup>
      ```terraform Bad theme={null}
      resource "google_container_cluster" "example" {
      enable_legacy_abac = true # Sensitive
      }
      ```

      ```terraform Fix theme={null}
      resource "google_container_cluster" "example" {
      enable_legacy_abac = false
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Disabling S3 bucket MFA delete is security-sensitive">
    <div class="paragraph">
      <p>ing is enabled it’s possible to add an additional authentication factor before being allowed to delete versions of an object or changing the versioning state of a bucket. It prevents accidental object deletion by forcing the user sending the delete request to prove that he has a valid MFA device and a corresponding valid token.</p>
    </div>

    <CodeGroup>
      ```terraform Bad theme={null}
      resource "aws_s3_bucket" "example" { # Sensitive
      bucket = "example"

      versioning {
      enabled = true
      }
      }
      ```

      ```terraform Fix theme={null}
      resource "aws_s3_bucket" "example" {
      bucket = "example"
      }

      resource "aws_s3_bucket_versioning" "example" { # Sensitive
      bucket = aws_s3_bucket.example.id
      versioning_configuration {
      status = "Enabled"
      }
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Creating DNS zones without DNSSEC enabled is security-sensitive">
    <div class="paragraph">
      <p>S) are vulnerable by default to various types of attacks.</p>
    </div>

    <div class="paragraph">
      <p>One of the biggest risks is DNS cache poisoning, which occurs when a DNS accepts spoofed DNS data, caches the malicious records, and potentially sends them later in response to legitimate DNS request lookups. This attack typically relies on the attacker’s <a href="https://en.wikipedia.org/wiki/Man-in-the-middle_attack">MITM</a> ability on the network and can be used to redirect users from an intended website to a malicious website.</p>
    </div>

    <div class="paragraph">
      <p>To prevent these vulnerabilities, Domain Name System Security Extensions (DNSSEC) ensure the integrity and authenticity of DNS data by digitally signing DNS zones.</p>
    </div>

    <div class="paragraph">
      <p>The public key of a DNS zone used to validate signatures can be trusted as DNSSEC is based on the following chain of trust:</p>
    </div>

    <div class="ulist">
      <ul>
        <li>
          <p>The parent DNS zone adds a "fingerprint" of the public key of the child zone in a "DS record".</p>
        </li>

        <li>
          <p>The parent DNS zone signs it with its own private key.</p>
        </li>

        <li>
          <p>And this process continues until the root zone.</p>
        </li>
      </ul>
    </div>

    <CodeGroup>
      ```terraform Bad theme={null}
      resource "google_dns_managed_zone" "example" { # Sensitive: dnssec_config is missing
      name     = "foobar"
      dns_name = "foo.bar."
      }
      ```

      ```terraform Fix theme={null}
      resource "google_dns_managed_zone" "example" {
      name     = "foobar"
      dns_name = "foo.bar."

      dnssec_config {
      default_key_specs {
        algorithm = "rsasha256"
      }
      }
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Creating custom roles allowing privilege escalation is security-sensitive">
    <div class="paragraph">
      <p>hat allow privilege escalation can allow attackers to
      maliciously exploit an organization’s cloud resources.</p>
    </div>

    <div class="paragraph">
      <p>Certain GCP permissions allow impersonation of one or more privileged principals
      within a GCP infrastructure.
      To prevent privilege escalation after an account has been compromised,
      proactively follow GCP Security Insights and ensure that custom roles contain
      as few privileges as possible that allow direct or indirect impersonation.</p>
    </div>

    <div class="paragraph">
      <p>For example, privileges like deploymentmanager.deployments.create allow
      impersonation of service accounts, even if the name does not sound like it.
      Other privileges like setIamPolicy, which are more explicit, directly allow
      their holder to extend their privileges.</p>
    </div>

    <div class="paragraph">
      <p>After gaining a foothold in the target infrastructure, sophisticated attackers
      typically map their newfound roles to understand what is exploitable.</p>
    </div>

    <div class="paragraph">
      <p>The riskiest privileges are either:</p>
    </div>

    <div class="ulist">
      <ul>
        <li>
          <p>At the infrastructure level: privileges to perform project, folder, or
          organization-wide administrative tasks.</p>
        </li>

        <li>
          <p>At the resource level: privileges to perform resource-wide administrative tasks.</p>
        </li>
      </ul>
    </div>

    <div class="paragraph">
      <p>In either case, the following privileges should be avoided or granted only with
      caution:</p>
    </div>

    <div class="ulist">
      <ul>
        <li>
          <p>*.*.setIamPolicy</p>
        </li>

        <li>
          <p>cloudbuilds.builds.create</p>
        </li>

        <li>
          <p>cloudfunctions.functions.create</p>
        </li>

        <li>
          <p>cloudfunctions.functions.update</p>
        </li>

        <li>
          <p>cloudscheduler.jobs.create</p>
        </li>

        <li>
          <p>composer.environments.create</p>
        </li>

        <li>
          <p>compute.instances.create</p>
        </li>

        <li>
          <p>dataflow\.jobs.create</p>
        </li>

        <li>
          <p>dataproc.clusters.create</p>
        </li>

        <li>
          <p>deploymentmanager.deployments.create</p>
        </li>

        <li>
          <p>iam.roles.update</p>
        </li>

        <li>
          <p>iam.serviceAccountKeys.create</p>
        </li>

        <li>
          <p>iam.serviceAccounts.actAs</p>
        </li>

        <li>
          <p>iam.serviceAccounts.getAccessToken</p>
        </li>

        <li>
          <p>iam.serviceAccounts.getOpenIdToken</p>
        </li>

        <li>
          <p>iam.serviceAccounts.implicitDelegation</p>
        </li>

        <li>
          <p>iam.serviceAccounts.signBlob</p>
        </li>

        <li>
          <p>iam.serviceAccounts.signJwt</p>
        </li>

        <li>
          <p>orgpolicy.policy.set</p>
        </li>

        <li>
          <p>run.services.create</p>
        </li>

        <li>
          <p>serviceusage.apiKeys.create</p>
        </li>

        <li>
          <p>serviceusage.apiKeys.list</p>
        </li>

        <li>
          <p>storage.hmacKeys.create</p>
        </li>
      </ul>
    </div>

    <CodeGroup>
      ```terraform Bad theme={null}
      resource "google_organization_iam_custom_role" "example" {
      permissions = [
      "iam.serviceAccounts.getAccessToken",     # Sensitive
      "iam.serviceAccounts.getOpenIdToken",     # Sensitive
      "iam.serviceAccounts.actAs",              # Sensitive
      "iam.serviceAccounts.implicitDelegation", # Sensitive
      "resourcemanager.projects.get",
      "resourcemanager.projects.list",
      "run.services.create",
      "run.services.delete",
      "run.services.get",
      "run.services.getIamPolicy",
      "run.services.list",
      "run.services.update",
      ]
      }
      ```

      ```terraform Fix theme={null}
      resource "google_project_iam_custom_role" "example" {
      permissions = [
      "iam.serviceAccountKeys.create",        # Sensitive
      "iam.serviceAccountKeys.get",           # Sensitive
      "deploymentmanager.deployments.create", # Sensitive
      "cloudbuild.builds.create",             # Sensitive
      "resourcemanager.projects.get",
      "resourcemanager.projects.list",
      "run.services.get",
      "run.services.getIamPolicy",
      "run.services.list",
      ]
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Creating keys without a rotation period is security-sensitive">
    <div class="paragraph">
      <p>ity incidents increases when cryptographic keys are used for a long time. Thus, to strengthen the data protection it’s recommended to rotate the symmetric keys created with the Google Cloud Key Management Service (KMS) automatically and periodically. Note that it’s not possible in GCP KMS to rotate asymmetric keys automatically.</p>
    </div>

    <CodeGroup>
      ```terraform Bad theme={null}
      resource "google_kms_crypto_key" "noncompliant-key" { # Sensitive: no rotation period is defined
      name            = "example"
      key_ring        = google_kms_key_ring.keyring.id
      }
      ```

      ```terraform Fix theme={null}
      resource "google_kms_crypto_key" "compliant-key" {
      name            = "example"
      key_ring        = google_kms_key_ring.keyring.id
      rotation_period = "7776000s" # 90 days
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Unversioned Google Cloud Storage buckets are security-sensitive">
    <div class="paragraph">
      <p>for Google Cloud Storage (GCS) buckets is enabled, different versions of an object are stored in the bucket, preventing accidental deletion. A specific version can always be deleted when the generation number of an object version is specified in the request.</p>
    </div>

    <div class="paragraph">
      <p>Object versioning cannot be enabled on a bucket with a retention policy. A retention policy ensures that an object is retained for a specific period of time even if a request is made to delete or replace it. Thus, a retention policy locks the single current version of an object in the bucket, which differs from object versioning where different versions of an object are retained.</p>
    </div>

    <CodeGroup>
      ```terraform Bad theme={null}
      resource "google_storage_bucket" "example" { # Sensitive
      name          = "example"
      location      = "US"
      }
      ```

      ```terraform Fix theme={null}
      resource "google_storage_bucket" "example" {
      name          = "example"
      location      = "US"

      versioning {
      enabled = "true"
      }
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Granting public access to GCP resources is security-sensitive">
    <div class="paragraph">
      <p>to GCP resources may reduce an organization’s ability to
      protect itself against attacks or theft of its GCP resources.
      Security incidents associated with misuse of public access include disruption
      of critical functions, data theft, and additional costs due to resource
      overload.</p>
    </div>

    <div class="paragraph">
      <p>To be as prepared as possible in the event of a security incident,
      authentication combined with fine-grained permissions helps maintain the
      principle of defense in depth and trace incidents back to the perpetrators.</p>
    </div>

    <div class="paragraph">
      <p>GCP also provides the ability to grant access to a large group of people:</p>
    </div>

    <div class="ulist">
      <ul>
        <li>
          <p>If public access is granted to all Google users, the impact of a data theft
          is the same as if public access is granted to all Internet users.</p>
        </li>

        <li>
          <p>If access is granted to a large Google group, the impact of a data theft is
          limited based on the size of the group.</p>
        </li>
      </ul>
    </div>

    <div class="paragraph">
      <p>The only thing that changes in these cases is the ability to track user access
      in the event of an incident.</p>
    </div>

    <CodeGroup>
      ```terraform Bad theme={null}
      resource "google_cloudfunctions_function_iam_binding" "example" {
      members = [
      "allUsers",              # Sensitive
      "allAuthenticatedUsers", # Sensitive
      ]
      }

      resource "google_cloudfunctions_function_iam_member" "example" {
      member = "allAuthenticatedUsers" # Sensitive
      }
      ```

      ```terraform Fix theme={null}
      resource "google_storage_bucket_access_control" "example" {
      entity = "allUsers" # Sensitive
      }

      resource "google_storage_bucket_acl" "example" {
      role_entity = [
      "READER:allUsers",              # Sensitive
      "READER:allAuthenticatedUsers", # Sensitive
      ]
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Enabling project-wide SSH keys to access VM instances is security-sensitive">
    <div class="paragraph">
      <p>aged in a project’s metadata can be used to access GCP VM instances. By default, GCP automatically deploys project-level SSH keys to VM instances.</p>
    </div>

    <div class="paragraph">
      <p>Project-level SSH keys can lead to unauthorized access because:</p>
    </div>

    <div class="ulist">
      <ul>
        <li>
          <p>Their use prevents fine-grained VM-level access control and makes it difficult to follow <a href="https://en.wikipedia.org/wiki/Principle_of_least_privilege">the principle of least privilege</a>.</p>
        </li>

        <li>
          <p>Unlike managed access control with <a href="https://cloud.google.com/compute/docs/instances/managing-instance-access">OS Login</a>, manual cryptographic key management is error-prone and requires careful attention. For example, if a user leaves a project, their SSH keys should be removed from the metadata to prevent unwanted access.</p>
        </li>

        <li>
          <p>If a project-level SSH key is compromised, all VM instances may be compromised.</p>
        </li>
      </ul>
    </div>

    <CodeGroup>
      ```terraform Bad theme={null}
      resource "google_compute_instance" "example" { # Sensitive, because metadata.block-project-ssh-keys is not set to true
      name         = "example"
      machine_type = "e2-micro"
      zone         = "us-central1-a"

      network_interface {
      network = "default"

      access_config {
      }
      }
      }
      ```

      ```terraform Fix theme={null}
      resource "google_compute_instance" "example" {
      name         = "example"
      machine_type = "e2-micro"
      zone         = "us-central1-a"

      metadata = {
      block-project-ssh-keys = true
      }

      network_interface {
      network = "default"

      access_config {
      }
      }
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Creating App Engine handlers without requiring TLS is security-sensitive">
    <div class="paragraph">
      <p>ryption in transit through TLS. As soon as the app is deployed, it can be requested using appspot.com domains or custom domains. By default, endpoints accept both clear-text and encrypted traffic. When communication isn’t encrypted, there is a risk that an attacker could intercept it and read confidential information.</p>
    </div>

    <div class="paragraph">
      <p>When creating an App Engine, request handlers can be set with different security level for encryption:</p>
    </div>

    <div class="ulist">
      <ul>
        <li>
          <p>SECURE\_NEVER: only HTTP requests are allowed (HTTPS requests are redirected to HTTP).</p>
        </li>

        <li>
          <p>SECURE\_OPTIONAL and SECURE\_DEFAULT: both HTTP and HTTPS requests are allowed.</p>
        </li>

        <li>
          <p>SECURE\_ALWAYS:  only HTTPS requests are allowed (HTTP requests are redirected to HTTPS).</p>
        </li>
      </ul>
    </div>

    <CodeGroup>
      ```terraform Bad theme={null}
      resource "google_app_engine_standard_app_version" "example" {
      version_id = "v1"
      service    = "default"
      runtime    = "nodejs"

      handlers {
      url_regex                   = ".*"
      redirect_http_response_code = "REDIRECT_HTTP_RESPONSE_CODE_301"
      security_level              = "SECURE_OPTIONAL" # Sensitive
      script {
        script_path = "auto"
      }
      }
      }
      ```

      ```terraform Fix theme={null}
      resource "google_app_engine_standard_app_version" "example" {
      version_id = "v1"
      service    = "default"
      runtime    = "nodejs"

      handlers {
      url_regex                   = ".*"
      redirect_http_response_code = "REDIRECT_HTTP_RESPONSE_CODE_301"
      security_level              = "SECURE_ALWAYS" 
      script {
        script_path = "auto"
      }
      }
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Authorizing anonymous access to Azure resources is security-sensitive">
    <div class="paragraph">
      <p>Allowing anonymous access can reduce an organization’s ability to protect itself against attacks on its Azure resources.</p>
    </div>

    <div class="paragraph">
      <p>Security incidents may include disrupting critical functions, data theft, and additional Azure subscription costs due to resource overload.</p>
    </div>

    <div class="paragraph">
      <p>Using authentication coupled with fine-grained authorizations helps bring defense-in-depth and bring traceability to investigators of security incidents.</p>
    </div>

    <div class="paragraph">
      <p>Depending on the affected Azure resource, multiple authentication choices are possible: Active Directory Authentication, OpenID implementations (Google, Microsoft, etc.) or native Azure mechanisms.</p>
    </div>

    <CodeGroup>
      ```terraform Bad theme={null}
      resource "azurerm_function_app" "example" {
      name = "example"

      auth_settings {
      enabled = false # Sensitive
      }

      auth_settings {
      enabled = true
      unauthenticated_client_action = "AllowAnonymous" # Sensitive
      }
      }
      ```

      ```terraform Fix theme={null}
      resource "azurerm_api_management_api" "example" { # Sensitive, the openid_authentication block is missing
      name = "example-api"
      }

      resource "azurerm_api_management" "example" {
      sign_in {
      enabled = false # Sensitive
      }
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Policies authorizing public access to resources are security-sensitive">
    <div class="paragraph">
      <p>Resource-based policies granting access to all users can lead to information leakage.</p>
    </div>

    <CodeGroup>
      ```terraform Bad theme={null}
      resource "aws_s3_bucket_policy" "mycompliantpolicy" {
      bucket = aws_s3_bucket.mybucket.id
      policy = jsonencode({
      Id = "mycompliantpolicy"
      Version = "2012-10-17"
      Statement = [{
              Effect = "Allow"
              Principal = {
                  AWS = [
                      "arn:aws:iam::${data.aws_caller_identity.current.account_id}:root"
                  ]
              }
              Action = [
                  "s3:PutObject"
              ]
              Resource = "${aws_s3_bucket.mybucket.arn}/*"
          }
      ]
      })
      }
      ```

      ```terraform Fix theme={null}
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Authorizing HTTP communications with S3 buckets is security-sensitive">
    <div class="paragraph">
      <p>By default, S3 buckets can be accessed through HTTP and HTTPs protocols.</p>
    </div>

    <div class="paragraph">
      <p>As HTTP is a clear-text protocol, it lacks the encryption of transported data, as well as the capability to build an authenticated connection. It means that a malicious actor who is able to intercept traffic from the network can read, modify or corrupt the transported content.</p>
    </div>

    <CodeGroup>
      ```terraform Bad theme={null}
      resource "aws_s3_bucket" "mycompliantbucket" {
      bucket = "mycompliantbucketname"
      }

      resource "aws_s3_bucket_policy" "mycompliantpolicy" {
      bucket = "mycompliantbucketname"

      policy = jsonencode({
      Version = "2012-10-17"
      Id      = "mycompliantpolicy"
      Statement = [
        {
          Sid       = "HTTPSOnly"
          Effect    = "Deny"
          Principal = "*"
          Action    = "s3:*"
          Resource = [
            aws_s3_bucket.mycompliantbucket.arn,
            "${aws_s3_bucket.mycompliantbucket.arn}/*",
          ]
          Condition = {
            Bool = {
              "aws:SecureTransport" = "false"
            }
          }
        },
      ]
      })
      }
      ```

      ```terraform Fix theme={null}
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="AWS tag keys should comply with a naming convention">
    <div class="paragraph">
      <p>A well-structured tagging strategy is essential when working with AWS resources.
      Inadequate tagging practices can lead to several potential issues and make it challenging to manage your AWS environment effectively:</p>
    </div>

    <div class="paragraph">
      <p>When resources lack proper tags or have inconsistent tagging, it becomes difficult to identify their purpose, owner, or role within the infrastructure.
      This ambiguity can lead to confusion and errors during resource management and allocation.
      Without clear and consistent tags, teams may struggle to understand the resource’s function, hindering collaboration and efficiency.</p>
    </div>

    <div class="paragraph">
      <p>Effective tagging is crucial for monitoring and managing costs in AWS.
      Resources without appropriate tags may not be adequately categorized, making tracking their usage and associated expenses hard.
      As a result, it becomes challenging to allocate costs to specific projects, departments, or teams accurately.
      Poor cost visibility can lead to overspending, budgeting issues, and difficulty in optimizing resource allocation.</p>
    </div>

    <div class="paragraph">
      <p>Tags play a significant role in resource security and compliance.
      Inadequate tagging can result in incorrectly classified resources, leading to potential security vulnerabilities and compliance risks.
      It becomes challenging to apply consistent security policies, control access, and track changes without proper tagging.
      This can leave the AWS environment more susceptible to unauthorized access and compliance violations.</p>
    </div>

    <div class="paragraph">
      <p>Automation and governance rely on well-defined tags to enforce policies and ensure consistent resource management.
      Inadequate tagging practices can hinder automation efforts, making it challenging to automate resource provisioning, scaling, and deprovisioning.
      Additionally, insufficient tags can lead to governance challenges, making it harder to enforce standardized policies and configurations across resources.</p>
    </div>

    <div class="paragraph">
      <p>Tags enable efficient resource search and filtering in the AWS Management Console and API.
      When tags are missing, inconsistent, or irrelevant, locating specific resources becomes cumbersome.
      Teams may need to resort to manual searches or resort to resource-naming conventions, defeating the purpose of tags.
      The lack of well-organized tags can increase the time and effort required for resource discovery and impact productivity.</p>
    </div>

    <div class="paragraph">
      <p>Inadequate tagging practices can also impede resource lifecycle management.
      It becomes harder to track when resources were created, their purpose, and whether they are still in use.
      Without this vital information, it becomes challenging to identify and delete unused or deprecated resources, leading to resource sprawl and increased costs.</p>
    </div>

    <div class="paragraph">
      <p>In summary, an inadequate tagging strategy in AWS resources can lead to difficulties in resource identification, cost management, security, automation, and resource lifecycle management.
      It is crucial to establish a well-organized tagging approach to mitigate these potential issues and efficiently manage your AWS environment.
      In the following section, we will explore how to fix this code smell by adopting best practices for tagging AWS resources.</p>
    </div>

    <CodeGroup>
      ```terraform Bad theme={null}
      resource "aws_s3_bucket" "mynoncompliantbucket" {
      bucket = "mybucketname"

      tags = {
      "anycompany:cost-center" = "Accounting"
      }
      }
      ```

      ```terraform Fix theme={null}
      resource "aws_s3_bucket" "mycompliantbucket" {
      bucket = "mybucketname"

      tags = {
      "AnyCompany:CostCenter" = "Accounting"
      }
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Allowing public network access to cloud resources is security-sensitive">
    <div class="paragraph">
      <p>Enabling public network access to cloud resources can affect an organization’s
      ability to protect its data or internal operations from data theft or
      disruption.</p>
    </div>

    <div class="paragraph">
      <p>Depending on the component, inbound access from the Internet can be enabled
      via:</p>
    </div>

    <div class="ulist">
      <ul>
        <li>
          <p>a boolean value that explicitly allows access to the public network.</p>
        </li>

        <li>
          <p>the assignment of a public IP address.</p>
        </li>

        <li>
          <p>database firewall rules that allow public IP ranges.</p>
        </li>
      </ul>
    </div>

    <div class="paragraph">
      <p>Deciding to allow public access may happen for various reasons such as for
      quick maintenance, time saving, or by accident.</p>
    </div>

    <div class="paragraph">
      <p>This decision increases the likelihood of attacks on the organization, such as:</p>
    </div>

    <div class="ulist">
      <ul>
        <li>
          <p>data breaches.</p>
        </li>

        <li>
          <p>intrusions into the infrastructure to permanently steal from it.</p>
        </li>

        <li>
          <p>and various malicious traffic, such as DDoS attacks.</p>
        </li>
      </ul>
    </div>

    <CodeGroup>
      ```terraform Bad theme={null}
      resource "aws_instance" "example" {
      associate_public_ip_address = true # Sensitive
      }
      ```

      ```terraform Fix theme={null}
      resource "aws_dms_replication_instance" "example" {
      publicly_accessible = true # Sensitive
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Using unencrypted RDS DB resources is security-sensitive">
    <div class="paragraph">
      <p>Using unencrypted RDS DB resources exposes data to unauthorized access.
      This includes database data, logs, automatic backups, read replicas, snapshots,
      and cluster metadata.</p>
    </div>

    <div class="paragraph">
      <p>This situation can occur in a variety of scenarios, such as:</p>
    </div>

    <div class="ulist">
      <ul>
        <li>
          <p>A malicious insider working at the cloud provider gains physical access to the storage device.</p>
        </li>

        <li>
          <p>Unknown attackers penetrate the cloud provider’s logical infrastructure and systems.</p>
        </li>
      </ul>
    </div>

    <div class="paragraph">
      <p>After a successful intrusion, the underlying applications are exposed to:</p>
    </div>

    <div class="ulist">
      <ul>
        <li>
          <p>theft of intellectual property and/or personal data</p>
        </li>

        <li>
          <p>extortion</p>
        </li>

        <li>
          <p>denial of services and security bypasses via data corruption or deletion</p>
        </li>
      </ul>
    </div>

    <div class="paragraph">
      <p>AWS-managed encryption at rest reduces this risk with a simple switch.</p>
    </div>

    <CodeGroup>
      ```terraform Bad theme={null}
      resource "aws_db_instance" "example" {
      storage_encrypted = true
      }

      resource "aws_rds_cluster" "example" {
      storage_encrypted = true
      }
      ```

      ```terraform Fix theme={null}
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Disabling logging is security-sensitive">
    <div class="paragraph">
      <p>Disabling logging of this component can lead to missing traceability in case of a security incident.</p>
    </div>

    <div class="paragraph">
      <p>Logging allows operational and security teams to get detailed and real-time feedback on an information system’s events. The logging coverage enables them to quickly react to events, ranging from the most benign bugs to the most impactful security incidents, such as intrusions.</p>
    </div>

    <div class="paragraph">
      <p>Apart from security detection, logging capabilities also directly influence future digital forensic analyses. For example, detailed logging will allow investigators to establish a timeline of the actions perpetrated by an attacker.</p>
    </div>

    <CodeGroup>
      ```terraform Bad theme={null}
      resource "aws_s3_bucket" "example" { # Sensitive
      bucket = "example"
      }
      ```

      ```terraform Fix theme={null}
      resource "aws_api_gateway_stage" "example" { # Sensitive
      xray_tracing_enabled = false # Sensitive
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Using unencrypted SageMaker notebook instances is security-sensitive">
    <div class="paragraph">
      <p>Amazon SageMaker is a managed machine learning service in a hosted production-ready environment. To train machine learning models, SageMaker instances can process potentially sensitive data, such as personal information that should not be stored unencrypted. In the event that adversaries physically access the storage media, they cannot decrypt encrypted data.</p>
    </div>

    <CodeGroup>
      ```terraform Bad theme={null}
      resource "aws_sagemaker_notebook_instance" "notebook" {  # Sensitive, encryption disabled by default
      }
      ```

      ```terraform Fix theme={null}
      resource "aws_sagemaker_notebook_instance" "notebook" {
      kms_key_id = aws_kms_key.enc_key.key_id
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Assigning high privileges Azure Resource Manager built-in roles is security-sensitive">
    <div class="paragraph">
      <p>Azure Resource Manager offers built-in roles that can be assigned to users, groups, or service principals.
      Some of these roles should be carefully assigned as they grant sensitive permissions like the ability to reset passwords for all users.</p>
    </div>

    <div class="paragraph">
      <p>An Azure account that fails to limit the use of such roles has a higher risk of being breached by a compromised owner.</p>
    </div>

    <div class="paragraph">
      <p>This rule raises an issue when one of the following roles is assigned:</p>
    </div>

    <div class="ulist">
      <ul>
        <li>
          <p>Contributor (b24988ac-6180-42a0-ab88-20f7382dd24c)</p>
        </li>

        <li>
          <p>Owner (8e3af657-a8ff-443c-a75c-2fe8c4bcb635)</p>
        </li>

        <li>
          <p>User Access Administrator (18d7d88d-d35e-4fb5-a5c3-7773c20a72d9)</p>
        </li>
      </ul>
    </div>

    <CodeGroup>
      ```terraform Bad theme={null}
      resource "azurerm_role_assignment" "example" {
      scope                = azurerm_resource_group.example.id
      role_definition_name = "Azure Maps Data Reader"
      principal_id         = data.azuread_user.example.id
      }
      ```

      ```terraform Fix theme={null}
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Policies granting all privileges are security-sensitive">
    <div class="paragraph">
      <p>A policy that grants all permissions may indicate an improper access control, which violates <a href="https://en.wikipedia.org/wiki/Principle_of_least_privilege">the principle of least privilege</a>. Suppose an identity is granted full permissions to a resource even though it only requires read permission to work as expected. In this case, an unintentional overwriting of resources may occur and therefore result in loss of information.</p>
    </div>

    <CodeGroup>
      ```terraform Bad theme={null}
      resource "aws_iam_policy" "example" {
      name = "noncompliantpolicy"

      policy = jsonencode({
      Version   = "2012-10-17"
      Statement = [
        {
          Action   = [
            "*" # Sensitive
          ]
          Effect   = "Allow"
          Resource = [
            aws_s3_bucket.mybucket.arn
          ]
        }
      ]
      })
      }
      ```

      ```terraform Fix theme={null}
      resource "google_project_iam_binding" "example" {
      project = "example"
      role    = "roles/owner" # Sensitive

      members = [
      "user:jane@example.com",
      ]
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Disabling versioning of S3 buckets is security-sensitive">
    <div class="paragraph">
      <p>S3 buckets can be in three states related to versioning:</p>
    </div>

    <div class="ulist">
      <ul>
        <li>
          <p>unversioned (default one)</p>
        </li>

        <li>
          <p>enabled</p>
        </li>

        <li>
          <p>suspended</p>
        </li>
      </ul>
    </div>

    <div class="paragraph">
      <p>When the S3 bucket is unversioned or has versioning suspended it means that a new version of an object overwrites an existing one in the S3 bucket.</p>
    </div>

    <div class="paragraph">
      <p>It can lead to unintentional or intentional information loss.</p>
    </div>

    <CodeGroup>
      ```terraform Bad theme={null}
      resource "aws_s3_bucket" "example" { # Sensitive
      bucket = "example"
      }
      ```

      ```terraform Fix theme={null}
      resource "aws_s3_bucket" "example" {
      bucket = "example"
      }

      resource "aws_s3_bucket_versioning" "example-versioning" {
      bucket = aws_s3_bucket.example.id
      versioning_configuration {
      status = "Enabled"
      }
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Using clear-text protocols is security-sensitive">
    <div class="paragraph">
      <p>Clear-text protocols such as \`ftp, telnet, or http lack
      encryption of transported data, as well as the capability to build an
      authenticated connection. It means that an attacker able to sniff traffic from
      the network can read, modify, or corrupt the transported content. These
      protocols are not secure as they expose applications to an extensive range of
      risks:</p>
    </div>

    <div class="ulist">
      <ul>
        <li>
          <p>sensitive data exposure</p>
        </li>

        <li>
          <p>traffic redirected  to a malicious endpoint</p>
        </li>

        <li>
          <p>malware-infected software update or installer</p>
        </li>

        <li>
          <p>execution of client-side code</p>
        </li>

        <li>
          <p>corruption of critical information</p>
        </li>
      </ul>
    </div>

    <div class="paragraph">
      <p>Even in the context of isolated networks like offline environments or segmented
      cloud environments, the insider threat exists. Thus, attacks involving
      communications being sniffed or tampered with can still happen.</p>
    </div>

    <div class="paragraph">
      <p>For example, attackers could successfully compromise prior security layers by:</p>
    </div>

    <div class="ulist">
      <ul>
        <li>
          <p>bypassing isolation mechanisms</p>
        </li>

        <li>
          <p>compromising a component of the network</p>
        </li>

        <li>
          <p>getting the credentials of an internal IAM account (either from a service
          account or an actual person)</p>
        </li>
      </ul>
    </div>

    <div class="paragraph">
      <p>In such cases, encrypting communications would decrease the chances of attackers
      to successfully leak data or steal credentials from other network components.
      By layering various security practices (segmentation and encryption, for
      example), the application will follow the <em>defense-in-depth</em> principle.</p>
    </div>

    <div class="paragraph">
      <p>Note that using the http\` protocol is being deprecated by
      <a href="https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http">major web browsers</a>.</p>
    </div>

    <div class="paragraph">
      <p>In the past, it has led to the following vulnerabilities:</p>
    </div>

    <div class="ulist">
      <ul>
        <li>
          <p><a href="https://nvd.nist.gov/vuln/detail/CVE-2019-6169">CVE-2019-6169</a></p>
        </li>

        <li>
          <p><a href="https://nvd.nist.gov/vuln/detail/CVE-2019-12327">CVE-2019-12327</a></p>
        </li>

        <li>
          <p><a href="https://nvd.nist.gov/vuln/detail/CVE-2019-11065">CVE-2019-11065</a></p>
        </li>
      </ul>
    </div>

    <CodeGroup>
      ```terraform Bad theme={null}
      resource "aws_kinesis_stream" "sensitive_stream" {
      encryption_type = "NONE" # Sensitive
      }
      ```

      ```terraform Fix theme={null}
      resource "aws_elasticache_replication_group" "example" {
      replication_group_id = "example"
      replication_group_description = "example"
      transit_encryption_enabled = false  # Sensitive
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Disabling server-side encryption of S3 buckets is security-sensitive">
    <div class="paragraph">
      <p>Server-side encryption (SSE) encrypts an object (not the metadata) as it is written to disk (where the S3 bucket resides) and decrypts it as it is read from disk. This doesn’t change the way the objects are accessed, as long as the user has the necessary permissions, objects are retrieved as if they were unencrypted. Thus, SSE only helps in the event of disk thefts, improper disposals of disks and other attacks on the AWS infrastructure itself.</p>
    </div>

    <div class="paragraph">
      <p>There are three SSE options:</p>
    </div>

    <div class="ulist">
      <ul>
        <li>
          <p>Server-Side Encryption with Amazon S3-Managed Keys (SSE-S3)</p>

          <div class="ulist">
            <ul>
              <li>
                <p>AWS manages encryption keys and the encryption itself (with AES-256) on its own.</p>
              </li>
            </ul>
          </div>
        </li>

        <li>
          <p>Server-Side Encryption with Customer Master Keys (CMKs) Stored in AWS Key Management Service (SSE-KMS)</p>

          <div class="ulist">
            <ul>
              <li>
                <p>AWS manages the encryption (AES-256) of objects and encryption keys provided by the AWS KMS service.</p>
              </li>
            </ul>
          </div>
        </li>

        <li>
          <p>Server-Side Encryption with Customer-Provided Keys (SSE-C)</p>

          <div class="ulist">
            <ul>
              <li>
                <p>AWS manages only the encryption (AES-256) of objects with encryption keys provided by the customer. AWS doesn’t store the customer’s encryption keys.</p>
              </li>
            </ul>
          </div>
        </li>
      </ul>
    </div>

    <CodeGroup>
      ```terraform Bad theme={null}
      resource "aws_s3_bucket" "example" { # Sensitive
      bucket = "example"
      }
      ```

      ```terraform Fix theme={null}
      resource "aws_s3_bucket" "example" {
      bucket = "example"

      server_side_encryption_configuration {
      rule {
        apply_server_side_encryption_by_default {
          sse_algorithm = "AES256"
        }
      }
      }
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Using unencrypted SNS topics is security-sensitive">
    <div class="paragraph">
      <p>Amazon Simple Notification Service (SNS) is a managed messaging service for application-to-application (A2A) and application-to-person (A2P) communication. SNS topics allows publisher systems to fanout messages to a large number of subscriber systems. Amazon SNS allows to encrypt messages when they are received. In the case that adversaries gain physical access to the storage medium or otherwise leak a message they are not able to access the data.</p>
    </div>

    <CodeGroup>
      ```terraform Bad theme={null}
      resource "aws_sns_topic" "topic" {  # Sensitive, encryption disabled by default
      name = "sns-unencrypted"
      }
      ```

      ```terraform Fix theme={null}
      resource "aws_sns_topic" "topic" {
      name = "sns-encrypted"
      kms_master_key_id = aws_kms_key.enc_key.key_id
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Using unencrypted EBS volumes is security-sensitive">
    <div class="paragraph">
      <p>Amazon Elastic Block Store (EBS) is a block-storage service for Amazon Elastic Compute Cloud (EC2). EBS volumes can be encrypted, ensuring the security of both data-at-rest and data-in-transit between an instance and its attached EBS storage. In the case that adversaries gain physical access to the storage medium they are not able to access the data. Encryption can be enabled for specific volumes or for <a href="https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html#encryption-by-default">all new volumes and snapshots</a>. Volumes created from snapshots inherit their encryption configuration. A volume created from an encrypted snapshot will also be encrypted by default.</p>
    </div>

    <CodeGroup>
      ```terraform Bad theme={null}
      resource "aws_ebs_volume" "ebs_volume" {  # Sensitive as encryption is disabled by default
      }
      ```

      ```terraform Fix theme={null}
      resource "aws_ebs_volume" "ebs_volume" {
      encrypted = false  # Sensitive
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Using unencrypted EFS file systems is security-sensitive">
    <div class="paragraph">
      <p>Amazon Elastic File System (EFS) is a serverless file system that does not require provisioning or managing storage. Stored files can be automatically encrypted by the service. In the case that adversaries gain physical access to the storage medium or otherwise leak a message they are not able to access the data.</p>
    </div>

    <CodeGroup>
      ```terraform Bad theme={null}
      resource "aws_efs_file_system" "fs" {  # Sensitive, encryption disabled by default
      }
      ```

      ```terraform Fix theme={null}
      resource "aws_efs_file_system" "fs" {
      encrypted = true
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Enabling Azure resource-specific admin accounts is security-sensitive">
    <div class="paragraph">
      <p>Enabling Azure resource-specific admin accounts can reduce an organization’s ability to protect itself against account or service account thefts.</p>
    </div>

    <div class="paragraph">
      <p>Full Administrator permissions fail to correctly separate duties and create potentially critical attack vectors on the impacted resources.</p>
    </div>

    <div class="paragraph">
      <p>In case of abuse of elevated permissions, both the data on which impacted resources operate and their access traceability are at risk.</p>
    </div>

    <CodeGroup>
      ```terraform Bad theme={null}
      resource "azurerm_batch_pool" "example" {
      name = "sensitive"

      start_task {
      user_identity {
        auto_user {
          elevation_level = "Admin" # Sensitive
          scope = "Task"
        }
      }
      }
      }
      ```

      ```terraform Fix theme={null}
      resource "azurerm_container_registry" "example" {
      name = "example"
      admin_enabled = true # Sensitive
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Using unencrypted cloud storages is security-sensitive">
    <div class="paragraph">
      <p>Using unencrypted cloud storages can lead to data exposure. In the case that adversaries gain physical access to the storage medium they are able to access unencrypted information.</p>
    </div>

    <CodeGroup>
      ```terraform Bad theme={null}
      resource "azurerm_data_lake_store" "store" {
      name             = "store"
      encryption_state = "Disabled"  # Sensitive
      }
      ```

      ```terraform Fix theme={null}
      resource "azurerm_data_lake_store" "store" {
      name             = "store"
      encryption_state = "Enabled"
      encryption_type  = "ServiceManaged"
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Creating public APIs is security-sensitive">
    <div class="paragraph">
      <p>Creating APIs without authentication unnecessarily increases the attack surface on
      the target infrastructure.</p>
    </div>

    <div class="paragraph">
      <p>Unless another authentication method is used, attackers have the
      opportunity to attempt attacks against the underlying API.
      This means attacks both on the functionality provided by the API and its
      infrastructure.</p>
    </div>

    <CodeGroup>
      ```terraform Bad theme={null}
      resource "aws_api_gateway_method" "noncompliantapi" {
      authorization = "NONE" # Sensitive
      http_method   = "GET"
      }
      ```

      ```terraform Fix theme={null}
      resource "aws_api_gateway_method" "compliantapi" {
      authorization = "AWS_IAM"
      http_method   = "GET"
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Defining a short backup retention duration is security-sensitive">
    <div class="paragraph">
      <p>Reducing the backup retention duration can reduce an organization’s ability to re-establish service in case of a security incident.</p>
    </div>

    <div class="paragraph">
      <p>Data backups allow to overcome corruption or unavailability of data by recovering as efficiently as possible from a security incident.</p>
    </div>

    <div class="paragraph">
      <p>Backup retention duration, coverage, and backup locations are essential criteria regarding functional continuity.</p>
    </div>

    <CodeGroup>
      ```terraform Bad theme={null}
      resource "aws_db_instance" "example" {
      backup_retention_period = 2 # Sensitive
      }
      ```

      ```terraform Fix theme={null}
      resource "azurerm_cosmosdb_account" "example" {
      backup {
      type = "Periodic"
      retention_in_hours = 8 # Sensitive
      }
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Granting access to S3 buckets to all or authenticated users is security-sensitive">
    <div class="paragraph">
      <p>Predefined permissions, also known as <a href="https://docs.aws.amazon.com/AmazonS3/latest/userguide/acl-overview.html#canned-acl">canned ACLs</a>, are an easy way to grant large privileges to predefined groups or users.</p>
    </div>

    <div class="paragraph">
      <p>The following canned ACLs are security-sensitive:</p>
    </div>

    <div class="ulist">
      <ul>
        <li>
          <p>\`PublicRead, PublicReadWrite grant respectively "read" and "read and write" privileges to everyone in the world (AllUsers group).</p>
        </li>

        <li>
          <p>AuthenticatedRead grants "read" privilege to all authenticated users (AuthenticatedUsers\` group).</p>
        </li>
      </ul>
    </div>

    <CodeGroup>
      ```terraform Bad theme={null}
      resource "aws_s3_bucket" "mycompliantbucket" { # Compliant
      bucket = "mycompliantbucketname"
      acl    = "private"
      }
      ```

      ```terraform Fix theme={null}
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Disabling Managed Identities for Azure resources is security-sensitive">
    <div class="paragraph">
      <p>Disabling Managed Identities can reduce an organization’s ability to protect itself against configuration faults and credential leaks.</p>
    </div>

    <div class="paragraph">
      <p>Authenticating via managed identities to an Azure resource solely relies on an API call with a non-secret token. The process is inner to Azure: secrets used by Azure are not even accessible to end-users.</p>
    </div>

    <div class="paragraph">
      <p>In typical scenarios without managed identities, the use of credentials can lead to mistakenly leaving them in code bases. In addition, configuration faults may also happen when storing these values or assigning them permissions.</p>
    </div>

    <div class="paragraph">
      <p>By transparently taking care of the Azure Active Directory authentication, Managed Identities allow getting rid of day-to-day credentials management.</p>
    </div>

    <CodeGroup>
      ```terraform Bad theme={null}
      resource "azurerm_api_management" "example" { # Sensitive, the identity block is missing
      name           = "example"
      publisher_name = "company"     
      }
      ```

      ```terraform Fix theme={null}
      resource "azurerm_data_factory_linked_service_kusto" "example" {
      name                 = "example"
      use_managed_identity = false # Sensitive
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Defining a short log retention duration is security-sensitive">
    <div class="paragraph">
      <p>Defining a short log retention duration can reduce an organization’s ability to backtrace the actions of malicious actors in case of a security incident.</p>
    </div>

    <div class="paragraph">
      <p>Logging allows operational and security teams to get detailed and real-time feedback on an information system’s events. The logging coverage enables them to quickly react to events, ranging from the most benign bugs to the most impactful security incidents, such as intrusions.</p>
    </div>

    <div class="paragraph">
      <p>Apart from security detection, logging capabilities also directly influence future digital forensic analyses. For example, detailed logging will allow investigators to establish a timeline of the actions perpetrated by an attacker.</p>
    </div>

    <CodeGroup>
      ```terraform Bad theme={null}
      resource "aws_cloudwatch_log_group" "example" {
      name = "example"
      retention_in_days = 3 # Sensitive
      }
      ```

      ```terraform Fix theme={null}
      resource "azurerm_firewall_policy" "example" {
      insights {
      enabled = true
      retention_in_days = 7 # Sensitive
      }
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Track uses of TODO tags">
    <div class="paragraph">
      <p>Developers often use TODO tags to mark areas in the code where additional work or improvements are needed but are not implemented immediately.
      However, these TODO tags sometimes get overlooked or forgotten, leading to incomplete or unfinished code.
      This rule aims to identify and address unattended TODO tags to ensure a clean and maintainable codebase.
      This description explores why this is a problem and how it can be fixed to improve the overall code quality.</p>
    </div>

    <CodeGroup>
      ```terraform Bad theme={null}
      resource "foo" "bar" {
      # TODO
      }
      ```

      ```terraform Fix theme={null}
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Policies granting access to all resources of an account are security-sensitive">
    <div class="paragraph">
      <p>A policy that allows identities to access all resources in an AWS account may violate <a href="https://en.wikipedia.org/wiki/Principle_of_least_privilege">the principle of least privilege</a>. Suppose an identity has permission to access all resources even though it only requires access to some non-sensitive ones. In this case, unauthorized access and disclosure of sensitive information will occur.</p>
    </div>

    <CodeGroup>
      ```terraform Bad theme={null}
      resource "aws_iam_policy" "noncompliantpolicy" {
      name        = "noncompliantpolicy"

      policy = jsonencode({
      Version = "2012-10-17"
      Statement = [
        {
          Action = [
            "iam:CreatePolicyVersion"
          ]
          Effect   = "Allow"
          Resource = [
            "*" # Sensitive
          ]
        }
      ]
      })
      }
      ```

      ```terraform Fix theme={null}
      resource "aws_iam_policy" "compliantpolicy" {
      name        = "compliantpolicy"

      policy = jsonencode({
      Version = "2012-10-17"
      Statement = [
        {
          Action = [
            "iam:CreatePolicyVersion"
          ]
          Effect   = "Allow"
          Resource = [ 
            "arn:aws:iam::${data.aws_caller_identity.current.account_id}:policy/team1/*"
          ]
        }
      ]
      })
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Disabling Role-Based Access Control on Azure resources is security-sensitive">
    <div class="paragraph">
      <p>Disabling Role-Based Access Control (RBAC) on Azure resources can reduce an
      organization’s ability to protect itself against access controls being compromised.</p>
    </div>

    <div class="paragraph">
      <p>To be considered safe, access controls must follow the principle of
      least privilege and correctly segregate duties amongst users.
      RBAC helps enforce these practices by adapting the organization’s access control
      needs into explicit role-based policies: It helps keeping access controls maintainable
      and sustainable.</p>
    </div>

    <div class="paragraph">
      <p>Furthermore, RBAC allows operations teams to work faster during a security
      incident. It helps to mitigate account theft or intrusions by quickly shutting down
      accesses.</p>
    </div>

    <CodeGroup>
      ```terraform Bad theme={null}
      resource "azurerm_kubernetes_cluster" "example" {
      role_based_access_control {
      enabled = false # Sensitive
      }
      }

      resource "azurerm_kubernetes_cluster" "example2" {
      role_based_access_control {
      enabled = true

      azure_active_directory {
        managed = true
        azure_rbac_enabled = false # Sensitive
      }
      }
      }
      ```

      ```terraform Fix theme={null}
      resource "azurerm_key_vault" "example" {
      enable_rbac_authorization = false # Sensitive
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Using unencrypted SQS queues is security-sensitive">
    <div class="paragraph">
      <p>Amazon Simple Queue Service (SQS) is a managed message queuing service for application-to-application (A2A) communication. Amazon SQS can store messages encrypted as soon as they are received. In the case that adversaries gain physical access to the storage medium or otherwise leak a message from the file system, for example through a vulnerability in the service, they are not able to access the data.</p>
    </div>

    <CodeGroup>
      ```terraform Bad theme={null}
      resource "aws_sqs_queue" "queue" {  # Sensitive, encryption disabled by default
      name = "sqs-unencrypted"
      }
      ```

      ```terraform Fix theme={null}
      resource "aws_sqs_queue" "queue" {
      name = "sqs-encrypted"
      kms_master_key_id = aws_kms_key.enc_key.key_id
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Allowing public ACLs or policies on a S3 bucket is security-sensitive">
    <div class="paragraph">
      <p>By default S3 buckets are private, it means that only the bucket owner can access it.</p>
    </div>

    <div class="paragraph">
      <p>This access control can be relaxed with ACLs or policies.</p>
    </div>

    <div class="paragraph">
      <p>To prevent permissive policies to be set on a S3 bucket the following settings can be configured:</p>
    </div>

    <div class="ulist">
      <ul>
        <li>
          <p>\`BlockPublicAcls: to block or not public ACLs to be set to the S3 bucket.</p>
        </li>

        <li>
          <p>IgnorePublicAcls: to consider or not existing public ACLs set to the S3 bucket.</p>
        </li>

        <li>
          <p>BlockPublicPolicy: to block or not public policies to be set to the S3 bucket.</p>
        </li>

        <li>
          <p>RestrictPublicBuckets\`: to restrict or not the access to the S3 endpoints of public policies to the principals within the bucket owner account.</p>
        </li>
      </ul>
    </div>

    <CodeGroup>
      ```terraform Bad theme={null}
      resource "aws_s3_bucket" "example" { # Sensitive: no Public Access Block defined for this bucket
      bucket = "example"
      }
      ```

      ```terraform Fix theme={null}
      resource "aws_s3_bucket" "example" {  # Sensitive
      bucket = "examplename"
      }

      resource "aws_s3_bucket_public_access_block" "example-public-access-block" {
      bucket = aws_s3_bucket.example.id

      block_public_acls       = false # should be true
      block_public_policy     = true
      ignore_public_acls      = true
      restrict_public_buckets = true
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Azure role assignments that grant access to all resources of a subscription are security-sensitive">
    <div class="paragraph">
      <p>Azure RBAC roles can be assigned to users, groups, or service principals. A role assignment grants permissions on a predefined set of resources called "scope".</p>
    </div>

    <div class="paragraph">
      <p>The widest scopes a role can be assigned to are:</p>
    </div>

    <div class="ulist">
      <ul>
        <li>
          <p>Subscription: a role assigned with this scope grants access to all resources of this Subscription.</p>
        </li>

        <li>
          <p>Management Group: a scope assigned with this scope grants access to all resources of all the Subscriptions in this Management Group.</p>
        </li>
      </ul>
    </div>

    <div class="paragraph">
      <p>In case of security incidents involving a compromised identity (user, group, or service principal), limiting its role assignment to the narrowest scope possible helps separate duties and limits what resources are at risk.</p>
    </div>

    <CodeGroup>
      ```terraform Bad theme={null}
      resource "azurerm_role_assignment" "example" {
      scope                = azurerm_resource_group.example.id
      role_definition_name = "Reader"
      principal_id         = data.azuread_user.user.object_id
      }
      ```

      ```terraform Fix theme={null}
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Administration services access should be restricted to specific IP addresses">
    <div class="paragraph">
      <p>Cloud platforms such as AWS, Azure, or GCP support virtual firewalls that can be used to restrict access to services by controlling inbound and outbound traffic.
      Any firewall rule allowing traffic from all IP addresses to standard network ports on which administration services traditionally listen, such as 22 for SSH, can expose these services to exploits and unauthorized access.</p>
    </div>

    <CodeGroup>
      ```terraform Bad theme={null}
      resource "aws_security_group" "noncompliant" {
      name        = "allow_ssh_noncompliant"
      description = "allow_ssh_noncompliant"
      vpc_id      = aws_vpc.main.id

      ingress {
      description      = "SSH rule"
      from_port        = 22
      to_port          = 22
      protocol         = "tcp"
      cidr_blocks      = ["0.0.0.0/0"]  # Noncompliant
      }
      }
      ```

      ```terraform Fix theme={null}
      resource "azurerm_network_security_rule" "noncompliant" {
      priority                    = 100
      direction                   = "Inbound"
      access                      = "Allow"
      protocol                    = "Tcp"
      source_port_range           = "*"
      destination_port_range      = "22"
      source_address_prefix       = "*"  # Noncompliant
      destination_address_prefix  = "*"
      }
      ```
    </CodeGroup>
  </Accordion>
</AccordionGroup>