AWS PowerShell Lambda Build Environment for Docker

If you’re deploying an AWS PowerShell Lambda (which is PowerShell Core 6.0) in a build pipeline, you’ll likely come across the fact that the older PowerShell docker images don’t have Dotnet Core installed.

The .NET Core 3.0 .NET Core 3.0 SDK Docker images now contain PowerShell Core, but since AWS still uses .NET Core 2.1 which is in Long Term Support, you’re out of luck.

Therefore if you’re deploying your lambda from your CI pipeline using docker, then you need a build environment which has:

• PowerShell Core 6
• .NET Core 2.1
• AWS Tools for PowerShell

You’ve come to the right place. Here is a DockerFile you can use to build your Lambda deployment environment. Make sure you choose the AWS PowerShell Tools module you need in the last line:

An example of how you can build and use this image in a pipeline is below. I use Buildkite, so YMMV:

Launch Windows Server 2016 Nano in AWS with Powershell

Amazon Web Services yesterday announced they now have Amazon Machine images available for Windows Server 2016. This includes Nano Server, a perfect solution for a roll your own IaaS server to host your .NET Core APIs.

Windows Server 2016 Nano Server -A cloud-native, minimal install that takes up a modest amount of disk space and boots more swiftly than the Datacenter version, while leaving more system resources (memory, storage, and CPU) available to run apps and services.

One of the interesting things about Nano for existing Windows server users, is you can only access it via PowerShell/WinRM for managment of the server. You can quickly spin up a new instance of nano in your PowerShell console (already configured for AWS):

Once the instance has started up, you can get the Admin credentials using your EC2 Key, and establish a remote PowerShell session:

This leaves you with an established PowerShell session to the remote server, which can be shown as follows:
C:\> $session
Id Name ComputerName ComputerType State ConfigurationName Availability
-- ---- ------------ ------------ ----- ----------------- ------------
2 Session2 172.19.1.67 RemoteMachine Opened Microsoft.PowerShell Available

You are now able to invoke remote commands on your Nano server:
C:\> Invoke-Command -Session $session -ScriptBlock { Get-Process | Select ProcessName, Id |ft }
ProcessName Id
----------- --
amazon-ssm-agent 1792
csrss 496
EMT 1088
Idle 0
LiteAgent 828
lsass 556
services 544
smss 360
svchost 648
svchost 692
svchost 768
System 4
wininit 520
WmiPrvSE 1236
wsmprovhost 1468

If you just want to jump onto the remote server, you can Enter the Session:
C:\> Enter-PSSession -Session $session
[172.19.1.67]: PS C:\Users\Administrator\Documents> $StartTime = (Get-Date) - (New-TimeSpan -Day 1)
[172.19.1.67]: PS C:\Users\Administrator\Documents> Get-WinEvent -FilterHashTable @{LogName='System'; Level=2; StartTime=$StartTime}
| select TimeCreated, Message
TimeCreated Message
----------- -------
10/21/2016 2:36:36 AM Task Scheduler service failed to start Task Compatibility module. Tasks m...
10/21/2016 2:36:15 AM The Virtualization Based Security enablement policy check at phase 6 fail...
10/21/2016 2:36:15 AM The Virtualization Based Security enablement policy check at phase 0 fail...
10/20/2016 4:18:55 AM Task Scheduler service failed to start Task Compatibility module. Tasks m...
10/20/2016 4:18:48 AM The Virtualization Based Security enablement policy check at phase 6 fail...
10/20/2016 4:18:48 AM The Virtualization Based Security enablement policy check at phase 0 fail...
10/20/2016 4:14:42 AM Task Scheduler service failed to start Task Compatibility module. Tasks m...
10/20/2016 4:14:11 AM The Virtualization Based Security enablement policy check at phase 6 fail...
10/20/2016 4:14:11 AM The Virtualization Based Security enablement policy check at phase 0 fail...
10/20/2016 11:12:05 AM The Virtualization Based Security enablement policy check at phase 6 fail...
10/20/2016 11:12:05 AM The Virtualization Based Security enablement policy check at phase 0 fail...

[172.19.1.67]: PS C:\Users\Administrator\Documents> Exit-PSSession

Don’t forget once you are finished to remove the session:
Remove-PSSession -Session $session
 

Given that this instance has no local console, you will have to maintain and access it fully using PowerShell. Time to skill up on your PowerShell skills. If you would like to read more on remotely managing the instance, Microsoft have documented how to manage Nano Server. It’s a good next step to read.

ADFS2 is not always SAML 2.0 standards compliant

Now the madness with ADFS2 SAML assertions via WS-Trust 1.3 – and how they are not valid for use with Amazon Web Services (AWS).

lexx:saml$ aws sts assume-role-with-saml --role-arn $role --principal-arn $principal --saml-assertion $assertion
A client error (InvalidIdentityToken) occurred when calling the AssumeRoleWithSAML operation: Responses must contain SubjectConfirmatonData with a Recipient and NotOnOrAfter

This failed due to a missing Recipient attribute on the SubjectConfirmationData element. Of course; I can’t modify the assertion to add the missing Recipient; as the SAML token is signed:

lexx:saml$ aws sts assume-role-with-saml --role-arn $role --principal-arn $principal --saml-assertion $assertion
A client error (InvalidIdentityToken) occurred when calling the AssumeRoleWithSAML operation: Response signature invalid

Second fail is because I’ve modified the assertion to add the missing attribute; but now the signature is invalid.

When you get an assertion from the ADFS Identity Provider via the IdP Web Landing Page, for AWS, the assertion includes a “recipient”:




When you ask for an assertion from the WS-Trust 1.3 endpoint; it is missing:




Seems to be a common problem with ADFS2 whereby ADFS1 did it correctly. It’s not just me…

In the original SAML 2.0 Core spec – Line 725 – Recipient is an optional attribute in the SubjectConfirmationData element. However in subsequent errata for the specification, Errata 02 in May 2007, made it mandatory. Errata 05 still includes this requirement.

At lease one bearer element MUST contain a element that itself MUST contain a Recipient attribute containing the service provider’s assertion consumer service URL

Of course; Amazon adhere to the Standard:

The value of the Recipient attribute inside the SubjectConfirmationData element must match the AWS endpoint (https://signin.aws.amazon.com/saml)

It seems that ADFS2 doesn’t provide valid SAML 2.0 assertions issued via the WS-Trust 1.3 endpoint. Since this has been a standard since for almost 8 years, how does ADFS2 even claim to be standards based.

SAML assertion from ADFS2 via SOAP endpoint

According to Wikipedia, Microsoft Active Directory Federation Services (ADFS) is:

… a software component developed by Microsoft that can be installed on Windows Server operating systems to provide users with single sign-on access to systems and applications located across organizational boundaries. It uses a claims-based access control authorization model to maintain application security and implement federated identity.

ADFS can provide Single sign as an identity provider to users, but what if a developer needs the same sign on outside of “browser land”? One option is to scrape webpage responses, but a better option is receiving a SAML Assertion using SOAP endpoints exposed via Microsoft ADFS, as long as they are enabled. You can use SOAP 1.2 with WS-A Addressing and mixed message security with the username/password in the SOAP headers secured over HTTPS, and get a valid SAML assertion.

There is Mex Endpoint (Anonymous by default) provided by ADFS2 or greater (if not disabled) at
https://youradfsserver.com.au/adfs/services/trust/mex
If you want to play with SOAP based claim requests, use a tool like SoapUI and consume the Mex endpoint as the WSDL. You can then construct Soap messages, and see if you get a valid response – which would contain an assertion.

The SOAP Endpoint for requesting a SAML token using WS-Trust 1.3 and mixed security would be
https://youradfsserver.com.au/adfs/services/trust/13/usernamemixed

The client credentials are included in the header of a SOAP message. Confidentiality is preserved at the transport layer (SSL/TLS); hence a usernamemixed endpoint.

Here is an example SOAP request for usernamemixed:

You can also use curl to post the soap request as shown:

Given all that; this actually won’t work for AWS; given ADFS2 actually breaks the SAML2.0 standards updated in 2012. Next post will detail this.