Merge "Nit: occurrences of barbican in small letter."

changes/25/290025/1
Jenkins 7 years ago committed by Gerrit Code Review
commit 032da9612a
  1. 8
      doc/source/api/userguide/acls.rst
  2. 6
      doc/source/api/userguide/cas.rst
  3. 12
      doc/source/api/userguide/certificates.rst
  4. 2
      doc/source/api/userguide/consumers.rst
  5. 14
      doc/source/api/userguide/dogtag_setup.rst
  6. 12
      doc/source/api/userguide/orders.rst
  7. 2
      doc/source/api/userguide/pkcs11keygeneration.rst
  8. 16
      doc/source/api/userguide/quotas.rst
  9. 2
      doc/source/api/userguide/secrets.rst

@ -2,15 +2,15 @@
ACL API User Guide
******************
By default Barbican manages access to its resources (secrets, containers) on a per project
By default barbican manages access to its resources (secrets, containers) on a per project
level, whereby a user is allowed access to project resources based on the roles a user has
in that project.
Some Barbican use cases prefer a more fine-grained access control for secrets and containers,
Some barbican use cases prefer a more fine-grained access control for secrets and containers,
such as at the user level. The Access Control List (ACL) feature supports this more restrictive
access.
This guide will assume you will be using a local running development environment of Barbican.
This guide will assume you will be using a local running development environment of barbican.
If you need assistance with getting set up, please reference the :doc:`development guide </setup/dev>`.
.. warning::
@ -51,7 +51,7 @@ Following ACL rules are defined and used as `OR` in resource access policy:
.. note::
Currently Barbican default policy just makes use of `read` ACL data only. So only **GET**
Currently barbican default policy just makes use of `read` ACL data only. So only **GET**
calls for a secret and a container resource will make use of ACL data. Other request methods on
secret and container resource still uses project level RBAC checks in policy.

@ -4,7 +4,7 @@ Certificate Authorities API - User Guide
Barbican is used as an interface to interact with Certificate Authorities (both
public and private) to issue, renew and revoke certificates. In PKI parlance,
Barbican acts as a Registration Authority for these CAs.
barbican acts as a Registration Authority for these CAs.
This interaction is done through certificate plugins, which in turn, can talk
to one of more CAs. Details about the CA each plugin communicates with are
@ -16,13 +16,13 @@ These are CAs which are generated on request by a client, which have signing
certificates which have been signed by another CA maintained by that plugin
(the parent CA). More details will be provided below.
The CAs made available to Barbican by the plugins are exposed to the client
The CAs made available to barbican by the plugins are exposed to the client
through the /cas REST API, which is detailed in the
:doc:`Certificate Authorities API reference <../reference/cas>`.
This guide will provide some examples on how to use each of the supported
operations. It assumes that you will be using a local running development
environment of Barbican. If you need assistance with getting set up, please
environment of barbican. If you need assistance with getting set up, please
reference the :doc:`development guide </setup/dev>`.
.. _listing_the_cas:

@ -8,7 +8,7 @@ certificate renewal and certificate revocation. At present, only the issuance o
certificates is implemented.
This guide will provide some examples on how to use each of the supported operations.
It assumes that you will be using a local running development environment of Barbican.
It assumes that you will be using a local running development environment of barbican.
If you need assistance with getting set up, please reference the :doc:`development guide </setup/dev>`.
Barbican can be used to request certificate issuance from a number of private and
@ -63,7 +63,7 @@ as shown below:
Getting the container provides references to secrets for the certificate,
any intermediate certificate chain in PKCS7 format, and potentially references
to the private and any passphrase used to encrypt the private key (if it is stored in
Barbican).
barbican).
.. code-block:: bash
@ -159,7 +159,7 @@ The output shows the status of the CA and the plugin used to communicate with it
"expiration": "2015-05-10T05:55:37.740211"
}
A snake-oil CA plugin is included with the Barbican source code for basic testing.
A snake-oil CA plugin is included with the barbican source code for basic testing.
In addition, a robust, enterprise-ready CA plugin is provided for the Dogtag CA.
Instructions for setting up the CA are provided at :doc:`Dogtag Setup Instructions <./dogtag_setup>`.
@ -231,10 +231,10 @@ This type has not yet been implemented.
Stored Key Certificate Order
****************************
Stored Key certificate orders take advantage of the fact that Barbican is also
Stored Key certificate orders take advantage of the fact that barbican is also
a repository for secrets. RSA private keys can be either generated on the client
and stored in Barbican beforehand using the secrets interface, or generated in
Barbican directly using the orders interface.
and stored in barbican beforehand using the secrets interface, or generated in
barbican directly using the orders interface.
All that is required for the certificate order is the reference to the secret container
for the RSA key pair and any parameters needed to generate a CSR. Barbican will

@ -2,7 +2,7 @@
Consumers API - User Guide
*************************
This guide assumes you will be using a local development environment of Barbican.
This guide assumes you will be using a local development environment of barbican.
If you need assistance with getting set up, please reference the :doc:`development guide </setup/dev>`.

@ -7,16 +7,16 @@ System, an enterprise certificate management system that has been deployed in so
of the largest PKI deployments worldwide. RHCS is FIPS 140-2 and Common Criteria certified.
The Dogtag Certificate Authority (CA) subsystem issues, renews and revokes many different
kinds of certificates. It can be used as a private CA back-end to Barbican, and interacts
with Barbican through the Dogtag CA plugin.
kinds of certificates. It can be used as a private CA back-end to barbican, and interacts
with barbican through the Dogtag CA plugin.
The Dogtag KRA subsystem is used to securely store secrets after being encrypted by
storage keys that are stored either in a software NSS database or in an HSM. It
can serve as a secret store for Barbican, and interacts with Barbican core through
can serve as a secret store for barbican, and interacts with barbican core through
the Dogtag KRA plugin.
In this guide, we will provide instructions on how to set up a basic Dogtag instance
containing a CA and a KRA, and how to configure Barbican to use this instance for a
containing a CA and a KRA, and how to configure barbican to use this instance for a
secret store and a certificate plugin. Much more detail about Dogtag, its deployment
options and its administration are available in the `RHCS documentation
<https://access.redhat.com/documentation/en-US/Red_Hat_Certificate_System>`_.
@ -153,7 +153,7 @@ server certificate for the KRA.
Configuring Barbican to Communicate with the Dogtag CA and KRA
**************************************************************
In order for Barbican to interact with the Dogtag CA and KRA, a PEM file must be
In order for barbican to interact with the Dogtag CA and KRA, a PEM file must be
created with trusted agent credentials.
.. code-block:: bash
@ -165,9 +165,9 @@ created with trusted agent credentials.
-out $BARBICAN_CONF_DIR/kra_admin_cert.pem -nodes
chown $USER $BARBICAN_CONF_DIR/kra_admin_cert.pem
The Barbican config file (/etc/barbican/barbican.conf) needs to be modified.
The barbican config file (/etc/barbican/barbican.conf) needs to be modified.
The modifications below set the Dogtag plugins as the only enabled secret store and
certificate plugins. Be sure to restart Barbican once these changes are made.
certificate plugins. Be sure to restart barbican once these changes are made.
Note that the actual hostname of the machine should be used in the script (rather
than localhost) because the hostname is used in the subject name for the SSL

@ -2,7 +2,7 @@
Orders API - User Guide
***********************
The orders resource allows the user to request Barbican to generate a secret.
The orders resource allows the user to request barbican to generate a secret.
This is also very helpful for requesting the creation of certificates and
public/private key pairs.
@ -12,7 +12,7 @@ The orders resource supports the following types:
* certificates
This user guide provides high level examples of the orders resource.
It will assume you will be using a local running development environment of Barbican.
It will assume you will be using a local running development environment of barbican.
If you need assistance with getting set up, please reference the :doc:`development guide </setup/dev>`.
For a more in depth explanation on how to order a certificate, reference
@ -23,7 +23,7 @@ the :ref:`How to Order a Certificate <order_certificate>` documentation.
Creating an Order
#################
When you want Barbican to generate a secret you need to create an order.
When you want barbican to generate a secret you need to create an order.
For an order to be processed correctly the parameters mode,
bit_length, and algorithm must be valid. Otherwise the order will fail and
the secret will not be generated. The example below shows a valid order for
@ -37,7 +37,7 @@ the parameters in the :doc:`Orders API <../reference/orders>` documentation.
"bit_length": 256, "mode": "cbc", "payload_content_type": "application/octet-stream"}
}' http://localhost:9311/v1/orders
You should receive an order reference after placing your order with Barbican.
You should receive an order reference after placing your order with barbican.
.. code-block:: bash
@ -155,7 +155,7 @@ refine your search among orders.
Deleting an Order
#################
It is also possible to delete an order from Barbican.
It is also possible to delete an order from barbican.
.. code-block:: bash
@ -163,4 +163,4 @@ It is also possible to delete an order from Barbican.
Nothing will be returned when you delete an order.
If something was returned there was most likely an error while deleting
the order.
the order.

@ -12,7 +12,7 @@ Setup
Initially, the deployer will need to examine the settings in their
`barbican.conf` file under the "Crypto plugin" settings section. Set these
values to whichever defaults you need. This will be used for both the script
and your usage of Barbican.
and your usage of barbican.
The following items are required to use the PKCS11 plugin:

@ -2,8 +2,8 @@
Quotas API - User Guide
************************
Running with default settings, the Barbican REST API doesn't impose an upper
limit on the number of resources that are allowed to be created. Barbican's
Running with default settings, the barbican REST API doesn't impose an upper
limit on the number of resources that are allowed to be created. barbican's
backend depends on limited resources. These limited resources include database,
plugin, and Hardware Security Module (HSM) storage space. This
can be an issue in a multi-project or multi-user environment when one project
@ -15,7 +15,7 @@ This user guide will show you how a user can lookup his current effective
quotas and how a service admin can create, update, read, and delete project quota
configuration for all projects in his cloud.
This guide will assume you will be using a local running development environment of Barbican.
This guide will assume you will be using a local running development environment of barbican.
If you need assistance with getting set up, please reference the :doc:`development guide </setup/dev>`.
.. _user_project_quotas_overview:
@ -23,16 +23,16 @@ If you need assistance with getting set up, please reference the :doc:`developme
Project Quotas Overview
#######################
All users authenticated with Barbican are able to read the effective quota values
All users authenticated with barbican are able to read the effective quota values
that apply to their project. Barbican can derive the project that a user belongs
to by reading the project scope from the authentication token.
Service administrators can read, set, and delete quota configurations for each
project known to Barbican. The service administrator is recognized by his authenticated
role. The service administrator's role is defined in Barbican's policy.json file.
project known to barbican. The service administrator is recognized by his authenticated
role. The service administrator's role is defined in barbican's policy.json file.
The default role for a service admin is "key-manager:service-admin".
Quotas can be enforced for the following Barbican resources: secrets, containers,
Quotas can be enforced for the following barbican resources: secrets, containers,
orders, consumers, and CAs. The configured quota value can be None (use the default),
-1 (unlimited), 0 (disabled), or a positive integer defining the maximum number
allowed for a project.
@ -44,7 +44,7 @@ Default Quotas
When no project quotas have been set for a project, the default
project quotas are enforced for that project. Default quotas are specified
in the Barbican configuration file (barbican.conf). The defaults provided
in the barbican configuration file (barbican.conf). The defaults provided
in the standard configuration file are as follows.
.. code-block:: none

@ -40,7 +40,7 @@ Single Step Secret Creation
***************************
The first secret we will create is a single step secret. Using a single step,
Barbican expects the user to provide the payload to be stored within the secret
barbican expects the user to provide the payload to be stored within the secret
itself. Once the secret has been created with a payload it cannot be updated. In
this example we will provide a plain text secret. For more information on creating
secrets you can view the :ref:`POST /v1/secrets <post_secrets>` section.

Loading…
Cancel
Save