savoirfairelinux / sflvault-server Goto Github PK

• Run django-admin startapp vaultsrv and django-admin startproject sflvault
• Creation of requirements.txt with Django>=1.11,<1.12, Django REST Framework, etc
• Make sure to use https://github.com/pypa/pipenv and Python 3 :)

There is a minor bug with coveralls seems that the Travis build doesn't give the correct informations to coveralls

https://github.com/savoirfairelinux/sflvault-server/blob/master/sflvault_server/model/__init__.py

• Account
  • user (ForeignKey to Django user)
  • groups (ManyToMany to AccountGroup, through GroupMembership)
  • department
  • pubkey
• AccountGroup
  • name
  • is_hidden
  • pubkey
• GroupMembership
  • account (ForeignKey to Account)
  • group (ForeignKey to AccountGroup)
  • is_admin
  • cryptgroupkey
• Customer
  • name
  • created
  • created_by (ForeignKey to user)
• ServiceGroup (ex-Machine)
  • customer (ForeignKey to customer)
  • name
  • created
  • fqdn
  • ip
  • location
  • notes
• Service
  • service_group (ForeignKey to ServiceGroup)
  • parent (Nullable ForeignKey to Service)
  • created
  • updated
  • url
  • metadata
  • notes
  • secret
• ServiceGroupMembership
  • group (ForeignKey to AccountGroup)
  • service (ForeignKey to Service)
  • cryptsymkey

• Multi-stage builds could allow us to build a container in different ways for different situations. For example, we could have a testing stage that builds the entire container in a first stage (primary) and then bundles in tox for testing (secondary). See https://docs.docker.com/develop/develop-images/multistage-build/
• Alternatively, we could use an external container for testing our code with tox, like https://hub.docker.com/r/themattrix/tox/. That way we don't need to download it or bundle it in with the rest of our container when it is only required in dev and testing.
• The Travis configuration currently runs the docker-compose file as a daemon and then executes commands in it from the outside using docker-compose exec. To better conserve system resources and handle potential failures I think it would be better to make use of docker-compose run instead. Thoughts?

From the sflvault v0.8 documentation

Each service has a secret associated with it, and each group has a keypair.

When the secret is first received, a random-generated SYMKEY is generated (32 random bytes), and that SYMKEY is used to encrypt the @secret@ with the AES-256 algorithm. This encrypted secret is stored and associated with the service. From now, to reveal the original secret that SYMKEY will be required.

Then, for each group, an ElGamal keypair is generated. The public key is stored with the group, and the group’s private key is encrypted with each member’s user public key. Now, the user’s private key will be required to reveal the group’s private key.

Now, the user’s private key will allow decryption of the group’s private key. The group’s private key will allow the decryption of the SYMKEY for a service, and the SYMKEY will give access to the secret, the actual password. This ensures no user has accidental access to a group, and no service has accidental membership to a group. Everything is cryptographically secured.

For version v2, we need to be able to this:

1. create a symkey for the secret, encrypt the secret and store the encrypted secret in the right Django field
2. Crypt the symkey using the groups public key
3. Store the crypt symkey in the right Django fields.

Including Dockerfile and docker-compose.yml that are at least sufficient for a development environment. We can take inspiration from the Django-Modèle project.

Once the core API is built out, a set of simple unit tests should be created to ensure that models can be correctly managed via the API.

GET individual records, GET all records, POST new records, PUT existing records, PATCH existing records, DELETE existing records

Set up a Travis CI configuration file with the following elements:

For commits and pull requests to all branches (except master)

• Build a Docker container
• Run tests

For commits on v2 branch:

• Build a Docker container
• Run tests
• Deploy container to Docker Hub on success (if v2 branch)

The Code Climate configuration should be updated to ignore the automatically generated migrations files.

The application will have a web interface, allowing for admin users to log in and manage available users, groups, clients/machines/services, etc.

This interface will use the Django multi-page app rendering system. We need to decide which frontend (HTML/CSS/JS) frameworks to use with this, and how they should be built and integrated into the application.

Authentication

This is from the documentation of sflvault v0.8 on how the authentication works:

First, the client issues a login call, with the presumed user he is.

The server then generates a random 32 bytes string and encrypts it with the user’s public key (which was stored in it’s database upon user setup). It stores it in temporary memory and sends the reply back to the client.

The client must then decrypt the challenge, and sends it back in an authenticate request, to prove he is really the one owning the private key associated with the public key.

The server validates the challenge token, and issues a new authtok: a quick-expiration token which is a bit like a cookie, over normal web applications.

The client uses that authtok to send the requests he desires (search, show, list-users, list-services, etc..) 

For v2:

1. We need to be able to authenticate the user by proving he had the correct private key
2. Store a auth token with expiration (15 or so minutes)
3. Client send this auth token each time he wants to send a command and revalidate private key if necessary

• Create a Code Climate configuration at .codeclimate.yml suitable for running duplication, radon, fixme and pep8 checks. Exclude settings and migrations files.
• Create a Coverage configuration at .coveragerc. Exclude settings, migrations, and admin/WSGI files (probably).
• Create a tox configuration at tox.ini. Add elements to test under Python 3.4, 3.5, 3.6 and 3.7a (the latter of which can fail).
• Create .flake8 configuration file if necessary
• Ensure that the projects are added and enabled at https://codeclimate.com/ and https://coveralls.io/

There is a minor isort error to correct before all tests are green!

DRF viewsets and serializers should be created for all the models that were set up in #6.

This task includes only minimal logic for GET, POST, PUT and DELETE requests. Logic behind model relationships, encryption, etc. will come later.

ModelAdmin registrations should be created for all the models that were set up in #6.