Merge pull request #118 from rpicard/master
Fix a handful of typos in documentation
This commit is contained in:
kevgliss
commit
90636a5329
|
|
@ -72,7 +72,7 @@ Basic Configuration
|
|||
.. data:: LEMUR_TOKEN_SECRET
|
||||
:noindex:
|
||||
|
||||
The TOKEN_SECRET is the secret used to create JWT tokens that are given out to users. This should be securely generated and be kept private.
|
||||
The TOKEN_SECRET is the secret used to create JWT tokens that are given out to users. This should be securely generated and kept private.
|
||||
|
||||
::
|
||||
|
||||
|
|
@ -210,13 +210,13 @@ Authority Options
|
|||
-----------------
|
||||
|
||||
Authorities will each have their own configuration options. There is currently just one plugin bundled with Lemur,
|
||||
Verisign/Symantec. Additional plugins may define additional options. Refer to the plugins own documentation
|
||||
Verisign/Symantec. Additional plugins may define additional options. Refer to the plugin's own documentation
|
||||
for those plugins.
|
||||
|
||||
.. data:: VERISIGN_URL
|
||||
:noindex:
|
||||
|
||||
This is the url for the verisign API
|
||||
This is the url for the Verisign API
|
||||
|
||||
|
||||
.. data:: VERISIGN_PEM_PATH
|
||||
|
|
@ -256,7 +256,7 @@ for those plugins.
|
|||
|
||||
Authentication
|
||||
--------------
|
||||
Lemur currently supports Basic Authentication and Ping OAuth2 out of the box, additional flows can be added relatively easily.
|
||||
Lemur currently supports Basic Authentication and Ping OAuth2 out of the box. Additional flows can be added relatively easily.
|
||||
If you are not using Ping you do not need to configure any of these options.
|
||||
|
||||
For more information about how to use social logins, see: `Satellizer <https://github.com/sahat/satellizer>`_
|
||||
|
|
@ -295,7 +295,7 @@ For more information about how to use social logins, see: `Satellizer <https://g
|
|||
AWS Plugin Configuration
|
||||
========================
|
||||
|
||||
In order for Lemur to manage it's own account and other accounts we must ensure it has the correct AWS permissions.
|
||||
In order for Lemur to manage its own account and other accounts we must ensure it has the correct AWS permissions.
|
||||
|
||||
.. note:: AWS usage is completely optional. Lemur can upload, find and manage TLS certificates in AWS. But is not required to do so.
|
||||
|
||||
|
|
@ -348,9 +348,9 @@ STS-AssumeRole
|
|||
|
||||
|
||||
|
||||
Next we will create the the Lemur IAM role. Lemur
|
||||
Next we will create the the Lemur IAM role.
|
||||
|
||||
..note::
|
||||
.. note::
|
||||
|
||||
The default IAM role that Lemur assumes into is called `Lemur`, if you need to change this ensure you set `LEMUR_INSTANCE_PROFILE` to your role name in the configuration.
|
||||
|
||||
|
|
@ -470,7 +470,7 @@ The configuration::
|
|||
|
||||
LEMUR_MAIL = 'lemur.example.com'
|
||||
|
||||
Will be sender of all notifications, so ensure that it is verified with AWS.
|
||||
Will be the sender of all notifications, so ensure that it is verified with AWS.
|
||||
|
||||
SES if the default notification gateway and will be used unless SMTP settings are configured in the application configuration
|
||||
settings.
|
||||
|
|
@ -554,9 +554,9 @@ All commands default to `~/.lemur/lemur.conf.py` if a configuration is not speci
|
|||
|
||||
.. data:: check_revoked
|
||||
|
||||
Traverses every certificate that Lemur is aware of and attempts to understand it's validity.
|
||||
Traverses every certificate that Lemur is aware of and attempts to understand its validity.
|
||||
It utilizes both OCSP and CRL. If Lemur is unable to come to a conclusion about a certificates
|
||||
validity it's status is marked 'unknown'
|
||||
validity its status is marked 'unknown'
|
||||
|
||||
|
||||
.. data:: sync
|
||||
|
|
@ -607,10 +607,10 @@ meaning.
|
|||
Within Lemur there are three main permissions: AdminPermission, CreatorPermission, OwnerPermission. Sub-permissions such
|
||||
as ViewPrivateKeyPermission are compositions of these three main Permissions.
|
||||
|
||||
Lets take a look at how these permissions used:
|
||||
Lets take a look at how these permissions are used:
|
||||
|
||||
Each `Authority` has a set of roles associated with it. If a user is also associated with the same roles
|
||||
that the `Authority` is associated with it Lemur allows that user to user/view/update that `Authority`.
|
||||
that the `Authority` is associated with, Lemur allows that user to user/view/update that `Authority`.
|
||||
|
||||
This RBAC is also used when determining which users can access which certificate private key. Lemur's current permission
|
||||
structure is setup such that if the user is a `Creator` or `Owner` of a given certificate they are allow to view that
|
||||
|
|
|
|||
|
|
@ -37,7 +37,7 @@ Create a New Certificate
|
|||
|
||||
.. figure:: create_certificate.png
|
||||
|
||||
Enter a owner, short description and the authority you wish to issue this certificate.
|
||||
Enter an owner, short description and the authority you wish to issue this certificate.
|
||||
Enter a common name into the certificate, if no validity range is selected two years is
|
||||
the default.
|
||||
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ Credential Management
|
|||
Lemur often contains credentials such as mutual TLS keys or API tokens that are used to communicate with third party resources and for encrypting stored secrets. Lemur comes with the ability
|
||||
to automatically encrypt these keys such that your keys not be in clear text.
|
||||
|
||||
The keys are located within lemur/keys and broken down by environment
|
||||
The keys are located within lemur/keys and broken down by environment.
|
||||
|
||||
To utilize this ability use the following commands:
|
||||
|
||||
|
|
@ -72,7 +72,7 @@ Nginx is a very popular choice to serve a Python project:
|
|||
Nginx doesn't run any Python process, it only serves requests from outside to
|
||||
the Python server.
|
||||
|
||||
Therefor there are two steps:
|
||||
Therefore there are two steps:
|
||||
|
||||
- Run the Python process.
|
||||
- Run Nginx.
|
||||
|
|
@ -90,7 +90,7 @@ You must create a Nginx configuration file for Lemur. On GNU/Linux, they usually
|
|||
go into /etc/nginx/conf.d/. Name it lemur.conf.
|
||||
|
||||
`proxy_pass` just passes the external request to the Python process.
|
||||
The port much match the one used by the 0bin process of course.
|
||||
The port must match the one used by the Lemur process of course.
|
||||
|
||||
You can make some adjustments to get a better user experience::
|
||||
|
||||
|
|
@ -271,7 +271,7 @@ Create a configuration file named supervisor.ini::
|
|||
The 4 first entries are just boiler plate to get you started, you can copy
|
||||
them verbatim.
|
||||
|
||||
The last one define one (you can have many) process supervisor should manage.
|
||||
The last one defines one (you can have many) process supervisor should manage.
|
||||
|
||||
It means it will run the command::
|
||||
|
||||
|
|
@ -293,6 +293,6 @@ Then you can manage the process by running::
|
|||
|
||||
supervisorctl -c /path/to/supervisor.ini
|
||||
|
||||
It will start a shell from were you can start/stop/restart the service
|
||||
It will start a shell from which you can start/stop/restart the service.
|
||||
|
||||
You can read all errors that might occurs from /tmp/lemur.log.
|
||||
You can read all errors that might occur from /tmp/lemur.log.
|
||||
|
|
|
|||
|
|
@ -101,7 +101,7 @@ Update your configuration
|
|||
-------------------------
|
||||
|
||||
Once created you will need to update the configuration file with information about your environment,
|
||||
such as which database to talk to, where keys are stores etc..
|
||||
such as which database to talk to, where keys are stored etc..
|
||||
|
||||
.. Note:: If you are unfamiliar with with the SQLALCHEMY_DATABASE_URI string it can be broken up like so:
|
||||
postgresql://userame:password@databasefqdn:databaseport/databasename
|
||||
|
|
@ -121,7 +121,7 @@ First, set a password for the postgres user. For this guide, we will use **lemu
|
|||
|
||||
Type CTRL-D to exit psql once you have changed the password.
|
||||
|
||||
Next, we will create our a new database::
|
||||
Next, we will create our new database::
|
||||
|
||||
$ sudo -u postgres createdb lemur
|
||||
|
||||
|
|
@ -135,8 +135,8 @@ used by Lemur to help associate certificates that do not currently have an owner
|
|||
Lemur has discovered certificates from a third party source. This is also a default user that can be used to
|
||||
administer Lemur.
|
||||
|
||||
In addition to create a new User, Lemur also creates a few default email notifications. These notifications are based
|
||||
on a few configuration options such as `LEMUR_SECURITY_TEAM_EMAIL` they basically garentee that every cerificate within
|
||||
In addition to creating a new user, Lemur also creates a few default email notifications. These notifications are based
|
||||
on a few configuration options such as `LEMUR_SECURITY_TEAM_EMAIL`. They basically guarantee that every cerificate within
|
||||
Lemur will send one expiration notification to the security team.
|
||||
|
||||
Additional notifications can be created through the UI or API.
|
||||
|
|
@ -238,7 +238,7 @@ See :ref:`Using Supervisor <UsingSupervisor>` for more details on using Supervis
|
|||
Syncing
|
||||
-------
|
||||
|
||||
Lemur uses periodic sync tasks to make sure it is up-to-date with it's environment. As always things can change outside
|
||||
Lemur uses periodic sync tasks to make sure it is up-to-date with its environment. As always things can change outside
|
||||
of Lemur, but we do our best to reconcile those changes.
|
||||
|
||||
.. code-block:: bash
|
||||
|
|
@ -254,7 +254,7 @@ If you're familiar with Python you'll quickly find yourself at home, and even mo
|
|||
``lemur`` command is just a simple wrapper around Flask's ``manage.py``, which means you get all of the
|
||||
power and flexibility that goes with it.
|
||||
|
||||
Some of those which you'll likely find useful are:
|
||||
Some of the features which you'll likely find useful are:
|
||||
|
||||
lock
|
||||
~~~~
|
||||
|
|
@ -273,6 +273,6 @@ What's Next?
|
|||
Get familiar with how Lemur works by reviewing the :doc:`../guide/index`. When you're ready
|
||||
see :doc:`../production/index` for more details on how to configure Lemur for production.
|
||||
|
||||
Remember the above just gets you going, but for production there are several different security considerations to take into account,
|
||||
remember Lemur is handling sensitive data and security is imperative.
|
||||
The above just gets you going, but for production there are several different security considerations to take into account.
|
||||
Remember, Lemur is handling sensitive data and security is imperative.
|
||||
|
||||
|
|
|
|||
|
|
@ -35,7 +35,7 @@ class Login(Resource):
|
|||
|
||||
Authorization:Bearer <token>
|
||||
|
||||
Tokens have a set expiration date. You can inspect the token expiration be base64 decoding the token and inspecting
|
||||
Tokens have a set expiration date. You can inspect the token expiration by base64 decoding the token and inspecting
|
||||
it's contents.
|
||||
|
||||
.. note:: It is recommended that the token expiration is fairly short lived (hours not days). This will largely depend \
|
||||
|
|
|
|||
Loading…
Reference in New Issue