glassechidna / lastkeypair Goto Github PK

• Use NLB for HA across three AZs
• Route 53 domain
• Host-key signed
• Port-forwarding only
• Generate example authoriser that emits bastion info

manifoldco/promptui#33

j and k work, but the user is unlikely to know this.

Maybe switch to https://github.com/AlecAivazis/survey

• Could be a restricted subset of base64 that is double-clickable
• Don't need to base32 encode something that is already base64-encoded

• kms:Encrypt
• kms:DescribeKey
• lambda:InvokeFunction

e.g. why we validate kms key ID is what we expect

Avoiding cross-region dependencies is generally preferable - LKP should support a use-case with the Lambda deployed to multiple regions.

Considerations:

• KMS key will probably also be deployed to each corresponding region
• LKP client needs to know which regional APIs and KMS and Lambda ARNs to use
• Custom authoriser could say "hey, wrong region - use this one instead" and client retries with other deployment? Not sure
• Maybe the Lambda could be invoked twice - first time simply tells client KMS key ARN it should use, second time works as per usual. Think about security implications

Admins will probably want to disable SSH shell login on SSH jumphosts, so a cert without user-pty would be nice. But right now one cert is shared for both the target instance and the intermediate jumphosts. Fix that

• CLI mode
• Web UI
• Store data into DynamoDB
• Maybe have scheduled/manually-triggered reconciliation with CloudTrail (using Athena?)
• Show "active" sessions

While the custom authoriser is able to accept/reject a connection to (e.g.) a prod box based on its EC2 tags, it would be nice for this to be logged in CloudTrail. So we should support passing in arbitrary key=val pairs which

• get logged to CloudTrail by means of inclusion in the encryption context
• get passed to the custom authoriser
• don't collide with the existing encryption context (maybe prefix user-submitted keys)
• demonstrate how an admin can mandate the presence of a key=val pair using conditions in the KMS key policy

We can deduce the account ID from GetCallerIdentity and the region from the user's config. If region not set, let the user know how to fix it.

Include CLI, Lambda version numbers in req/resp

Probably not the domain of this project, but could build upon this. A Lambda that does something like:

https://github.com/sourcelair/xterm.js
https://github.com/stuicey/SSHy

Don't make the user type in the IP address when we can figure it out based on the instance ARN. Considerations:

• The instance might not have a public IP address, or a routable private IP address. Maybe we can either have the LKP lambda provide a ProxyCommand (or jump host or whatevs) to use or the user can provide their own in their ~/.lkp/config.yml file. Advantage of the Lambda doing it is that the administrator could specify different jump hosts for different instance regions, accounts, etc.

• Undocumented golang LkpUserCertAuthorizationRequest.Principals property should be removed.
• If LkpUserCertAuthorizationResponse.Principals is absent, LKP should populate with RemoteInstanceArn
• Document the above behaviour

Specifically this one: https://www.microsoft.com/en-us/wdsi/threats/malware-encyclopedia-description?Name=PUA:Win32/Puwaders.C!ml&ThreatID=242877

Might have to stop using UPX for the Windows binary

When using jumpboxes the authoriser should have a way to return different CertificateOptions for each connection in the chain. E.g. the JumpBox will require permit-port-forwarding to work, but maybe it isn't needed for the final connection

The duplication here could/will lead to bugs. Maybe we could serialise to JSON and use that to avoid missing fields that get added in the future.

Lambda got this, but user not told of any error:

Decryption error: AccessDeniedException: The ciphertext refers to a customer master key that does not exist, does not exist in this region, or you are not allowed to access.

This should add the ssh CA to the user's known_hosts

Subcommand would allow user to interactively do MFA authentication before doing an ssh [email protected] command.

• Build app and lambda package
• Upload zip and update cfn
• SSH into an instance that just says "success!" and terminates the session
• Have travis match the output to expected output, like we do for ecs-run-task

Look into whether ProxyCommand, ssh-agent or something can let us transparently do ssh user@ip or even ssh user@instance-id instead of the current lkp ssh exec -- dance

Right now it's just "user" (and soon to add "host") but we also want to add some kind of "namespace" (e.g. AWS account id) to the encryption context

Windows powershell remoting allows authentication using SSL client certificates. We could add support for this

Should include the authoriser lambda function, but more importantly example IAM policies needed to ensure that users can't escalate their own access. See:

• https://aws.amazon.com/blogs/aws/new-tag-ec2-instances-ebs-volumes-on-creation/
• http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ExamplePolicies_EC2.html#iam-example-taggingresources
• http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-policy-structure.html#amazon-ec2-keys
• https://stackoverflow.com/questions/43121514/ec2-iam-policy-to-require-tags
• http://docs.aws.amazon.com/AWSEC2/latest/APIReference/ec2-api-permissions.html#ec2-api-unsupported-resource-permissions
• https://aws.amazon.com/premiumsupport/knowledge-center/iam-ec2-resource-tags/

Needed for SSH bastions, maybe for other things too?

Rather than silently swallowing {"stackTrace": [["runtime/proxy.py", 44, "_handle", null]], "errorType": "fundamental", "errorMessage": "authorisation denied by auth lambda"}

Maybe something like JS in (a file on S3|parameter store|an environment variable).

JS would have access to (at least) info about the user and maybe info about the target instance. Could fetch target instance's tags (preferably on-demand)

E.g. We know that KMS keys should begin with aws:arn:kms:<region>:<accountid> where regions alway follow a certain format and account IDs are always numeric. Return a nice error message rather than:

2018/09/11 10:35:48 Encryption error: RequestError: send request failed
caused by: Post https://kms.us-east-1a.amazonaws.com/: dial tcp: lookup kms.us-east-1a.amazonaws.com on 10.224.50.10:53: no such host

Which is caused by an accidental us-east-1a as the region.

When instances do an lkp host setup, it could install both the "active" CA pubkey and an "inactive" one (or more) ready for rotation when the time comes.

Maybe we want to use a different keypair per account, or per region, or per whatever. Maybe authoriser lambda could instruct the LKP lambda which keypair CA to use. Related-ish to #29

Right now the code assumes that the jumpboxes have host certs with principals that match the addresses returned by the authoriser lambda