Remote Desktop access now available for Windows instances.
Remote Desktop access is now available for Windows instances. This provides a way to upload alternate missions, mods, scripts etc. RDP is accesible on the instance ip on the standard RDP port (3389) as the Administrator user with the mission id as the password. A convenient connection file can be downloaded from the mission page.
This is possible because of the temporary nature of instances, and because I've done some work to remove all the hardcoded passwords I put there in the initial implementation. In short there is nothing to break and nothing sensitive to be exposed, so it's cool to have access. Thanks @Esquim for asking the question, and prompting me to consider what would be required to make instances accessible.
In addition to DCS, each instance runs a small web service to run commands and queries to facilitate startup and provide other services, such as proxied access to the DCS Server Dashbaord. Also during startup DCS assests are download from S3, and on termination mission artifacts are uploaded to S3. The web service orginally used a shared secret to authenticate requests, this has now been replaced by JWTs with asymmetric keys so that only the public key needs to be maintained on the instance. The requests to S3 originally used shared credentials, these have now been replaced by narrowly scoped time limited access tokens issued by AWS's STS service.
I picked JSON Web Tokens (JWT) for authenticating requests to the instance web service since it's an existing standard, accomodates asymmetric signing - which would be needed to avoid maintaining a secret on the instance, and isn't too different to shared secrect authentication as it's just a different value passed via the same http Authorization header. In order to prevent tokens being reused between instances I'm putting the AWS instance id into the JWT under the 'audience' claim so that instances can inspect this value ignore tokens not intended for them. https://jwt.io/introduction
The AWS Security Token Service STS is what I discovered when I started looking for a way to remove credentials from the instances. The credentials are still there, but narrowed in scope - i.e. can't write to other missions, can't read from other regions, and time limited - so even if they are exposed they can't continue to be used. The shared credentials are now only maintined in the kiosk service which uses the STS function 'GetFederationToken' in conjunction with serval policies specific to use cases (e.g. Sydney, read only) to produce a token that can then be passed to and used by the instance.