6 potential issues in IaC templates: unguarded conditional resource, plain-string secrets #15282

Where: Solutions/AWS Security Hub/CloudFormationTemplates/SecurityHubResourcesAndConfig.json, lines 84–86 (the conditional bucket), with unguarded references at lines 155–168, lines 208–229 and lines 247–252

        "S3Bucket": {
            "Type": "AWS::S3::Bucket",
            "Condition": "CreateNewBucketCondition",

One of the references, in SecurityHubDeliveryStream (lines 247–252):

                    "BucketARN": {
                        "Fn::GetAtt": [
                            "S3Bucket",
                            "Arn"
                        ]
                    },

What we found: S3Bucket has "Condition": "CreateNewBucketCondition" (line 86), so it is skipped when the parameter CreateNewBucket (lines 26–34) is false. Three resources have no condition but use {"Fn::GetAtt": ["S3Bucket", "Arn"]} without an Fn::If:

• S3BucketPolicy: the policy Resource, inside Fn::Join (lines 160–163);
• FirehoseDeliveryStreamRole: the policy Resource list (lines 210–213 and 220–223);
• SecurityHubDeliveryStream: ExtendedS3DestinationConfiguration.BucketARN (lines 247–252).

Why it matters: The parameter description says "Set to false to have Amazon S3 use an existing S3 Bucket", but with false the stack can fail to create, because S3Bucket is not part of it. Users who want to reuse an existing bucket cannot deploy this template, and Security Hub findings cannot be delivered to that bucket.

Suggested fix: Wrap each Fn::GetAtt on S3Bucket in Fn::If, and fall back to the ARN of the existing bucket named by BucketName:

{
  "Fn::If": [
    "CreateNewBucketCondition",
    { "Fn::GetAtt": ["S3Bucket", "Arn"] },
    { "Fn::Sub": "arn:${AWS::Partition}:s3:::${BucketName}" }
  ]
}

Use it in the four places listed above (lines 160–163, 210–213, 220–223 and 247–252). When a new bucket is created, the result is the same as today, so this is not a breaking change. Note that an existing bucket does not get the SQS NotificationConfiguration that S3Bucket sets, so that would have to be configured separately.

Where: DataConnectors/Duo Security/azuredeploy_DuoSecurity_API_FunctionApp.json, lines 23–26

        "SecretKey": {
            "type": "string",
            "defaultValue": "<sk***"
        },

What we found: SecretKey is declared with "type": "string" and a placeholder defaultValue. Users paste their Duo Admin API secret key into it, and the template passes it to the Function App as the app setting sKey (line 194), which the function reads as its Duo secret key. Nothing in the template marks the value as secret, and nothing rejects the placeholder. The parameter WorkspaceKey (lines 15–18), which holds the Log Analytics workspace key, has the same shape.

Why it matters: Azure stores plain string parameter values in the deployment history of the resource group, so the Duo secret key (and the workspace key) can be read there by anyone with read access to deployments, long after the deployment. If a user keeps the default in the "Deploy to Azure" form, the connector is deployed with an invalid secret key, and log collection can fail without any deployment error.

Suggested fix: Declare both secret parameters as securestring and drop the placeholder defaults, so the values must be supplied:

"WorkspaceKey": {
    "type": "securestring"
},
"SecretKey": {
    "type": "securestring"
},

Callers that pass a value are unaffected, and sKey in the appsettings resource keeps working unchanged. Without the defaults the parameters become required, so a deployment that leaves them out stops at validation instead of deploying a connector that cannot authenticate.

Where: DataConnectors/GitHub/azuredeploy.json, lines 17–22

    "PersonalAccessToken": {
      "type": "string",
      "metadata": {
        "description": "Enter the GitHub personal access token."
      }
    },

What we found: PersonalAccessToken has "type": "string". Its value is the GitHub PAT, which the template writes into a Key Vault secret at line 104 ("value": "[parameters('PersonalAccessToken')]"). Because the parameter is not a securestring, Azure Resource Manager does not mask it.

Why it matters: Plain string parameter values are saved in the resource group's deployment history and shown in the portal and in az deployment group show output. Anyone with read access to the deployments can recover the GitHub token, even though the template otherwise keeps it in Key Vault.

Suggested fix: Change the parameter type to securestring:

"PersonalAccessToken": {
  "type": "securestring",
  "metadata": {
    "description": "Enter the GitHub personal access token."
  }
}

This is not a breaking change: callers pass the same value, and the portal shows a masked input. The parameter workSpaceKey (the Log Analytics workspace key, lines 41–46) can be changed to securestring in the same way.

Where: DataConnectors/O365 Data/azuredeploy.json, lines 9–12

        "clientSecret": {
            "type": "string",
            "defaultValue": "AAD***"
        },

What we found: clientSecret is declared with "type": "string". It carries the Azure AD application's client secret: the template stores it in the Key Vault secret clientSecret (line 101), and the Function App reads it from there (line 252). The parameter itself is not marked secure, so the value entered at deployment is not hidden. The parameter workspaceKey (lines 37–40) has the same problem.

Why it matters: Azure Resource Manager keeps plain string parameter values in the deployment history, so anyone who can read the resource group's deployments can see the client secret, even though the template later moves it into Key Vault.

Suggested fix: Declare the parameter as securestring and drop the placeholder default (secure parameters should not have a default):

"clientSecret": {
    "type": "securestring"
},

Apply the same change to workspaceKey. Changing the type is not breaking: callers still pass a string, and [parameters('clientSecret')] works unchanged. Removing the default makes the parameter required.

Where: DataConnectors/Okta Single Sign-On/azuredeploy_OktaSingleSignOn_API_FunctionApp.json, lines 17–20

          "APIToken": {
              "type": "string",
              "defaultValue": "<ap***"
          },

What we found: APIToken is declared with "type": "string". Its value is the Okta API token, which is copied into the Function App setting apiToken on line 182 ("apiToken": "[parameters('APIToken')]"). No part of the template marks it as secure. The parameter WorkspaceKey (lines 13–16) is also a plain string.

Why it matters: Plain string parameter values are saved in the deployment history of the resource group, so the Okta API token can be read by anyone with read access to deployments. An Okta API token carries the permissions of the admin who created it, so a leak can expose more than the System Log.

Suggested fix: Declare the parameter as securestring and drop the placeholder default, so the token is never recorded in the deployment history:

"APIToken": {
    "type": "securestring",
    "metadata": { "description": "Okta API token used to read the System Log." }
},

Apply the same change to WorkspaceKey. Callers that already pass a value are unaffected; the placeholder default never worked as a real token anyway. For stronger protection, the app setting can hold a Key Vault reference (@Microsoft.KeyVault(SecretUri=...)), as the connector instructions already suggest.

Where: DataConnectors/Okta Single Sign-On/azuredeploy_OktaSingleSignOn_API_FunctionApp_V2.json, lines 19–22

          "APIToken": {
              "type": "string",
              "defaultValue": "<ap***"
          },

What we found: In the V2 template, APIToken also has "type": "string". It holds the Okta API token that the Function App uses to read the Okta System Log, and it is passed into the app setting apiToken (line 198). The copy of this template under Solutions/Okta Single Sign-On/Data Connectors/OktaSingleSign-On/ already declares APIToken as securestring, but this copy in DataConnectors/ does not.

Why it matters: With type string, the Okta token is shown in plain text in the Deploy-to-Azure form and is stored in the deployment history of the resource group, where it can be read by anyone with read access to deployments.

Suggested fix: Change the parameter type to securestring, as in the Solutions/ copy of this template, and drop the placeholder default as in #5. The parameter WorkspaceKey (lines 15–18) holds the workspace key and can be changed in the same way. Callers pass the same value, so this is not a breaking change; without the default, the parameter becomes required.