netflix/bless

Repository for BLESS, an SSH Certificate Authority that runs as a AWS Lambda function

bless's Issues

Permission Denied Error

Followed the steps as described in readme except renaming the generated rsa private key from myca to myca.pem

Getting the below message, when invoking lambda (as seen in cloudwatch)

[Errno 13] Permission denied: '/var/task/myca.pem': IOError
Traceback (most recent call last):
File "/var/task/bless_lambda.py", line 60, in lambda_handler
with open(os.path.join(os.path.dirname(file), ca_private_key_file), 'r') as f:
IOError: [Errno 13] Permission denied: '/var/task/myca.pem'

Any thoughts, what i may be doing wrong or workaround this problem ?

make test fails on deprecated warnings [linting]

(venv) ubuntu@hostname$ make test
--> Linting Python files
PYFLAKES_NODOCTEST=1 flake8 bless
bless/config/bless_config.py:188:10: W605 invalid escape sequence '\W'
bless/config/bless_config.py:188:10: W605 invalid escape sequence '\W'
bless/request/bless_request.py:19:23: W605 invalid escape sequence '\Z'
bless/request/bless_request.py:27:2: W605 invalid escape sequence '\A'
bless/request/bless_request.py:27:14: W605 invalid escape sequence '\s'
bless/request/bless_request.py:27:18: W605 invalid escape sequence '\Z'
make: *** [lint] Error 1
(venv) ubuntu@hostname$ vim Makefile
(venv) ubuntu@hostname$ make test
--> Linting Python files

How to reproduce:

docker run -it ubuntu:18.04 /bin/bash
apt update
apt install git make python3.6 python3-venv
git clone https://@github.com/Netflix/bless.git
cd bless
python3.6 -m venv venv
source venv/bin/activate
make develop
make test

Is this project still under development

After AWS released instance connect, I have to ask are you still working on this or should we switch over?

Authorization with BLESS?

Reading through the validity constraints docs for SSH certificates, it doesn't look like there's the ability to specify which hosts a SSH user certificate is able to be used with. How are you solving authorization issues (allowing a user access to some hosts, but not all in a larger environment) with BLESS, or are you?

It looks like this would mean the holder of a valid SSH certificate would have access to any host configured to trust that CA certificate (plus or minus networking) without the ability to make access decisions by the type of host. Is that accurate or am I grossly misunderstanding something?

Source: OpenSSH ssh-keygen options docs

[SECURITY] Fix kmsauth token validation to include all requested remote_usernames

Introduced at:
909d955

Reported by:
@Stype

If using the unreleased master, and using kmsauth, a user could request multiple remote_usernames, and would only need to have a valid kmsauth token for the first user.

How has to be the kmsauth token created?

Hi Guys,

I have implemented bless and is working as expected.

The only problem happens when i'm trying to implement kmsauth and i'm not sure how to generate the token.

I tried to use as well the lyft client (unsuccessfully).

This is my config:

1 - script that returns a token (probably this is not the right format, here is where i need your help)

import kmsauth

generator = kmsauth.KMSTokenGenerator(
    'alias/bless',

    {

        'to':'bless-prod',

        'from':'home',

        'user_type': 'service'
    },

    'eu-west-2'
)
username = generator.get_username()
token = generator.get_token()


#print(username)
print(token)

2 - how i run the client:

./bless_client.py eu-west-2 bless-prod myusername my.ip.address myusername my.ip.address test /home/user/.ssh/id_rsa.pub id_rsa-cert.pub token_returned_by_the_script

3 - and here is my kms auth config on the bless_deploy.cfg file

[KMS Auth]

use_kmsauth = True


kmsauth_key_id = arn:aws:kms:eu-west-2:xxxxx:key/xxxxx-xxxx-xxxx-xxxx-xxxx #alias: bless

kmsauth_serviceid = bless-prod
kmsauth_remote_usernames_allowed = ubuntu,root,ec2-user,centos,user1,user2,user3, myusername

Cheers!

add coveralls reporting to project

having overall test coverage reporting for repo and PRs would be useful

Support additional CA Private Key Types

Currently only RSA CA Private Keys are supported.

Unable to login with the cert got from lambda function

I am getting "Authentication tried for user with valid certificate but not from a permitted host (ip=x.x.x.x)." in /var/log/auth.log on the bastion server and unable to login what can be the problem?

Issues with environment variable configuration options

According to the new option to add configurations in environment variables to set a region password one would have to provide a key like bless_ca_us-east-1_password as shown in this test https://github.com/Netflix/bless/blob/master/tests/config/test_bless_config.py#L40
Unfortunately this is not a valid environment variable name for lambda.
One alternative to fix this would be to replace the "-" with "_" and so name the environment variable bless_ca_us_east_1_password. Would this be acceptable?

Another thing I noticed after deploying this is that there is a 4KB limit on the environment variables so when I tried creating just one key "bless_ca_ca_private_key" with the base64 encoded value of my certificate it already exceeds the 4kb limit making it impractical for the purpose of not having the key bundled with the zipfile. Am I missing anything? maybe @ikben could comment on this?

Restrict users from jumping to certain hosts

At what point would you recommend that you restrict or even better whitelist the hosts that a certain user is allowed to connect to?

In my opinion that would be the bastion itself right? But is a bastion per group of users the way to go or add some business logic to the script that will handle the signing of the SSH Certificate?

Thanks

Support certificates for additional SSH Public Key types

Currently only certificates for RSA Public Keys can be issued.

Consider using lambda-packages

https://github.com/miserlou/lambda-packages provides a precompiled Python C libraries. Using them in combination with BLESS might simplify deployments.

More thorough docs

Due to the security repercussions, of deploying this incorrectly, Are they any docs that go into more detail on a proper installation?

Amazonlinux make bug

--> Compiling lambda dependencies
docker run --rm -it -v /home/lin/Development/System_Administration/builds/bless:/src -w /src amazonlinux make compile
docker: Error response from daemon: OCI runtime create failed: container_linux.go:348: starting container process caused "exec: \"make\": executable file not found in $PATH": unknown.
Makefile:50: recipe for target 'lambda-deps' failed
make: *** [lambda-deps] Error 127

Add support for publishing PyPI package

BLESS should be easily downloadable and installbe from PyPI.

.travis.yml: The 'sudo' tag is now deprecated in Travis CI

Travis are now recommending removing the sudo tag.

"If you currently specify sudo: false in your .travis.yml, we recommend removing that configuration"

Question about existing user groups?

Is there a user group I can ask this question too? "Does BLESS provision both private and public keys, or does the user provide a public key/cert to be signed?"

Are you guys aware of anything similar to this for Google Cloud Platform?

Update the sample BLESS client to always write out certs with the required file permissions

Certs need to be only readable or writable by the user.

hope

---

Invalid Key length when using gpg-agent

I currently am experiencing issues when using ForwardAgent and ssh-add on PGP-Tools. After trying to ssh-add a key I get an "Invalid Key length" error. It is able to add the private key just fine but something breaks with the "blessed" public certificate.

Bastion host in same account as the Lambda Function

Is this setup aimed to have the bastion in the same account as the lambda function or do you only use the aws account for the KMS key and lambda function?

Potential dependency conflicts between bless and boto3

Hi, as shown in the following full dependency graph of bless, bless requires boto3 (the latest version)， while the installed version of kmsauth(0.3.0) requires boto3>=1.2.0,<2.0.0.

According to Pip's “first found wins” installation strategy, boto3 1.9.193 is the actually installed version.

Although the first found package version boto3 1.9.193 just satisfies the later dependency constraint （boto3>=1.2.0,<2.0.0), it will lead to a build failure once developers release a newer version of bleach.

Dependency tree--------

bless-master<version range:>
| +-boto3<version range:>
| +-cryptography<version range:>
| +-ipaddress<version range:>
| +-kmsauth<version range:>
| | +-boto3<version range:>=1.2.0,<2.0.0>
| +-marshmallow<version range:>

Suggestion

1. Fix your direct dependencies to be boto3==1.9.193 and kmsauth==0.3.0, to remove this conflict.
   I have checked this revision will not affect your downstream projects now.

2. Ask your upstream project kmsauth to loose the version range of boto3 to be >=1.2.0.

Thanks for your attention.
Best,
Neolith

Submit compiled lambda dependencies to lambda-packages

Hey team! Great project!

Rather than providing instructions on how to compile the necessary dependencies on EC2, it'd be much more useful for everybody if you could submit the compiled resources to lambda-packages. That way, other projects can all benefit from the work that you've done, and BLESS's users won't have to manually compile their own resources.

Thoughts?

document `-m PEM` option to ssh-keygen

New versions of openssh changed the default file format of the keys generated by ssh-keygen to their own special format. Bless only supports the PEM format, so documentation needs to specify the -m PEM option for versions of openssh newer than 7.8 (inclusive).

Support authentication with OpenID Connect

Hello,

I'm interested in authenticating users to the BLESS lambda using OpenID Connect identity tokens.

This would be an alternative to using KMS auth to prove the identity of the caller. Users could use AWS AssumeRoleWithWebIdentity API to get temporary credentials to invoke the lambda, and then pass their identity token in the payload to get a certificate signed for a username that matches a claim in the identity token.

I'm keen to implement this feature. Is there any interest and support for new features like this?

Changed expected location of ca.pem

When this commit got merged 62fe7fc the location of the ca.pem file is no longer being read from the root of the projects (where the publish command places it) but now it's expected to be inside /config directory.

I don't know if this behaviour is intended (so we should change the makefile publish) or just a side effect and should be fixed.

I could help with it and provide a fix but I'd like to know what do you think.

Add optional parameters

Our use case requires us to generate certificates of varying lifetimes. It would be nice to have optional parameters matching "certificate_validity_after_seconds" and "certificate_validity_before_seconds" configuration options.

Add the possibility to use encrypted private key with KMS

We would like to add another layer of protection to the root CA used for signing keys.

It would be nice to have the possibility to use an encrypted private key with KMS. This feature can be used in addition to the KMS encrypted password.
This will provide these two choices:

• Private key AND password encrypted with KMS.
• Only the password encrypted with KMS.

Do you agree with this proposal, and should I start working on it?

Make SSH certificate keyid field configurable

It would be nice if keyid format was configurable from config file.

Add support multiple valid principals and source ips in requested certificates.

Ability to sign SSH certificate with SHA2

Hello

I would like to add into Bless the support to sign the SSH certificates with a SHA2 algorithm , more specifically RSA-SHA2 512.
SSH certificate signed with SHA2 algorithm is supported and recommended by default since OpenSSH 8.2 release https://www.openssh.com/txt/release-8.2

I have created a POC using the Bless SSH sign code, successfully signing with RSA SHA2 512.
would love to contribute my work to Bless.

Thanks
Albert

Trying to test bless but can't seem to connect...

So i setup a bastion host and followed all the steps but when i run the following command on the bastion host:

./bless_client.py eu-west-1 SSHAccess ec2-user <IP OF THE BASTION> "nr18" <IP OF THE REQUESTER> "ls -lah" ../bless-ca-1.pub ~/tempcert.pem
ssh -i ~/tempcert.pem ec2-user@<Ip OF THE TARGET> -v

I get asked for a passphrase when i'm in the venv environment and a permission denied when not in the venv environment:

OpenSSH_6.6.1, OpenSSL 1.0.1k-fips 8 Jan 2015
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 56: Applying options for *
debug1: Connecting to 10.2.9.159 [10.2.9.159] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: ssh_rsa_verify: signature correct
debug1: identity file ./tempcert.pem type 5
debug1: identity file ./tempcert.pem-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1
debug1: match: OpenSSH_6.6.1 pat OpenSSH_6.6.1* compat 0x04000000
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr [email protected] none
debug1: kex: client->server aes128-ctr [email protected] none
debug1: kex: [email protected] need=16 dh_need=16
debug1: kex: [email protected] need=16 dh_need=16
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 24:e8:c4:cb:5c:09:f2:e9:78:b5:b7:6e:de:89:6e:73
debug1: Host '10.2.9.159' is known and matches the ECDSA host key.
debug1: Found key in /root/.ssh/known_hosts:1
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA-CERT public key: ./tempcert.pem
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
Permission denied (publickey).

Any hints on what i'm forgetting or doing wrong?

Thanks!

Username contains invalid characters

My user convention is first.last but the lambda function doesn't seem to accept it:

{'bastion_user': ['Username contains invalid characters']}: ValidationError
Traceback (most recent call last):
  File "/var/task/bless_lambda.py", line 88, in lambda_handler
    request = schema.load(event).data
  File "/var/task/marshmallow/schema.py", line 544, in load
    result, errors = self._do_load(data, many, partial=partial, postprocess=True)
  File "/var/task/marshmallow/schema.py", line 645, in _do_load
    raise exc
ValidationError: {'bastion_user': ['Username contains invalid characters']}

While first.last is accepted by AD and Linux distros

Optional parameter [kmsauth token] cannot be passed in

If passing in a 10th parameter [kmsauth token], there is ValueError displayed.

Traceback (most recent call last):
  File "./bless_client/bless_client.py", line 98, in <module>
    main(sys.argv[1:])
  File "./bless_client/bless_client.py", line 51, in main
    bastion_command, public_key_filename, certificate_filename = argv
ValueError: too many values to unpack

Is Marshmellow<3 required to function?

I've started messing around with spinning up BLESS internally, but after a few iterations I got stuck on the following error popping up when I ran the lambda:

{
  "errorMessage": "__init__() got an unexpected keyword argument 'strict'",
  "errorType": "TypeError",
  "stackTrace": [
    "  File \"/var/task/bless_lambda_user.py\", line 68, in lambda_handler_user\n    schema = BlessUserSchema(strict=True)\n"
  ]
}

Anyway after a bunch of random Google-fu and stumbling through code. I ran across this comment by Jeremy Stott:

So (like any trained security professional) I simply blindly followed suggestions from random internet comments to try and get what I hope to be a critical security control for my org to work. Low and behold it works! s/'marshmallow',/'marshmallow<3',/ got things back to a happy state. Here's my current setup.py

import os

from setuptools import setup, find_packages

ROOT = os.path.realpath(os.path.join(os.path.dirname(__file__)))

about = {}
with open(os.path.join(ROOT, "bless", "__about__.py")) as f:
    exec(f.read(), about)

setup(
    name=about["__title__"],
    version=about["__version__"],
    author=about["__author__"],
    author_email=about["__email__"],
    url=about["__uri__"],
    description=about["__summary__"],
    license=about["__license__"],
    packages=find_packages(exclude=["test*"]),
    install_requires=[
        'boto3',
        'cryptography',
        'ipaddress',
        'marshmallow<3',
        'kmsauth'
    ],
    extras_require={
        'tests': [
            'coverage',
            'flake8',
            'pyflakes',
            'pytest',
            'pytest-mock'
        ]
    }
)

I've just started to familiarize myself with Bless, so I feel like I'm pretty strongly lacking in context for the full implications of this change here. Is this workaround of pinning to an earlier version of marshmellow the correct way forward?

Nonstandard SSH port

My bastion uses a non-standard SSH port (2222), how would I go about connecting through that?

payload_json is: '{"bastion_ips": "public bastion ip", "public_key_to_sign": "ssh-rsa ...", "bastion_user": "marc", "command": "", "remote_usernames": "ec2-user", "bastion_user_ip": "my home ip"}'
{'RetryAttempts': 0, 'HTTPStatusCode': 200, 'RequestId': '-3651-11e7-9902-eb8febb6c898', 'HTTPHeaders': {'x-amzn-requestid': '-3651-11e7-9902-eb8febb6c898', 'content-length': '2555', 'x-amzn-trace-id': 'root=1--c4586e35580a7f0f9bf3b17a;sampled=0', 'x-amzn-remapped-content-length': '0', 'connection': 'keep-alive', 'date': 'Thu, 11 May 2017 13:57:26 GMT', 'content-type': 'application/json'}}

Wrote Certificate to: /tmp/tmp.PbljasFnhX-cert.pub

$ ssh -v -i  /tmp/tmp.PbljasFnhX [email protected] #10.0.3.19 only connectable through bastion
OpenSSH_7.5p1, OpenSSL 1.0.2k  26 Jan 2017
debug1: Reading configuration data /c/Users/myoung/.ssh/config
debug1: Connecting to 10.0.3.19 [10.0.3.19] port 22.
debug1: connect to address 10.0.3.19 port 22: Connection timed out
ssh: connect to host 10.0.3.19 port 22: Connection timed out

How to make the bastion transparent for users

Hello,
I am wondering how do you manage to make the Bastion process transparent for a user?

Currently, we use authorized_keys mechanism with a proxy jump, one key for the bastion and one key for the target.
Users have on their ssh config something like this:

Host 10.10.*
    ProxyJump bastion

Thanks to that they are able to use ssh 10.10.10.10 and the bastion is transparent for them.

With the Bless approach (https://qconnewyork.com/ny2017/system/files/presentation-slides/qconny_2017_bless_netflix_.pdf page 70 for example) you generate Keypair on the Bastion and use session credentials to request a certificate.

I tried this process but I'm not able to use this generated key (on the Bastion) to authenticate on the target. i.e I used this command ssh -J user@bastion user@target the only user credentials used are the one on the source.

Is there a way to make the Bless process transparent for the user when using ProxyJump or ProxyCommant mechanisms?

Thank you