Merge "Nit: occurrences of barbican in small letter."
This commit is contained in:
commit
032da9612a
|
@ -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
|
||||
|
||||
|
|
|
@ -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…
Reference in New Issue