Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bypass 'Get-AzSKAzureServicesSecurityStatus' cmdlet's confirmation prompt for attestation #1184

Open
vinodsunkara opened this issue Aug 21, 2020 · 2 comments

Comments

@vinodsunkara
Copy link

Bypass 'Get-AzSKAzureServicesSecurityStatus' cmdlet's confirmation prompt for attestation

If possible can you guys please add the force/confirm feature to 'Get-AzSKAzureServicesSecurityStatus' cmdlet.

We are trying to automate the resources attestation using a PowerShell runbook, the attestation is successful. But, we don't see any attestations details in the security report. After further investigation, we found that we do not have a force/confirm switch to bypass the below prompt in automation.

image


Steps to reproduce

# Attestation
foreach ($inputItem in $inputContents) {
    
    $ControlID = $inputItem.ControlID
    $ResourceName = $inputItem.ResourceName
    $AttestationStatus = $inputItem.AttestationStatus
    $JustificationText = $inputItem.JustificationText

    try {
        Get-AzSKAzureServicesSecurityStatus -SubscriptionId $RunAsConnection.SubscriptionId `
            -ResourceNames $ResourceName `
            -ControlsToAttest NotAttested `
            -ControlId $ControlID `
            -AttestationStatus $AttestationStatus `
            -JustificationText $JustificationText

            Write-Host "INFO: Completed the attestation for $ResourceName"
    }
    catch {
        Write-Host "ERROR: Could not attest the resource $ResourceName due to error $_ "
        
    }

}
@IISResetMe
Copy link

The problem here is that the confirmation prompts aren't raised by the cmdlet, but by writing a warning message and calling Read-Host from a helper class.

To implement conforming confirmation prompts with the current model, the helper classes will need to be refactored for injection of a PSCmdlet object (advanced functions at runtime derive from PSCmdlet) and the functions need to set the SupportsShouldProcess flag in their [CmdletBinding()] attributes:

using namespace System.Management.Automation

class CmdletHelperWithShouldProcessSupport
{
  [PSCmdlet]$Command
  CmdletHelperWithShouldProcessSupport([PSCmdlet]$CommandInvocation)
  {
    $this.Command = $CommandInvocation
  }

  [void]MethodThatShouldPromptIfAppropriate()
  {
    # Ask the function/command to handle processing confirmation
    if($this.Command.ShouldProcess("Please confirm that you want to do this")){
      # go ahead and do stuff
    }
    else
    {
      # throw and/or return
    }
  }
}

And then in the function(s):

function Do-SomethingSlightlyDangerous
{
  [CmdletBinding(SupportsShouldProcess = $true, ConfirmImpact = 'Medium')]
  param()

  begin {
    # Pass $PSCmdlet to the helper
    $helper = [CmdletHelperWithShouldProcessSupport]::new($PSCmdlet)
  }

  end {
    $helper.MethodThatShouldPromptIfAppropriate()
  }
}

By default, Do-SomethingSlightlyDangerous will no longer prompt the caller for continuation (due to ConfirmImpact = 'Medium'), but it will start prompting if the caller sets $ConfirmPreference = 'Medium' (or 'Low').

The SupportsShouldProcess flag will also make PowerShell add the -Confirm common switch parameter to the function.

If anyone is interested in pursuing implementing this, feel free to ping me (there's also more detail about the ShouldProcess capability here)

@ganesh-msft
Copy link
Contributor

The behavior is actually intentional. Attestation is a very sensitive operation from security standpoint and intention has always been that anyone taking the accountability for the security gap that they are attesting to, should review it carefully instead of letting any automation attest it for them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants