Merge pull request #2495 from hashicorp/sethvargo/api_split

Split out API
This commit is contained in:
Jeff Mitchell 2017-03-17 13:42:29 -04:00 committed by GitHub
commit 1ed884bf15
127 changed files with 8603 additions and 10044 deletions

View file

@ -1,3 +1,3 @@
source "https://rubygems.org"
gem "middleman-hashicorp", "0.3.13"
gem "middleman-hashicorp", "0.3.15"

View file

@ -6,7 +6,7 @@ GEM
minitest (~> 5.1)
thread_safe (~> 0.3, >= 0.3.4)
tzinfo (~> 1.1)
autoprefixer-rails (6.7.6)
autoprefixer-rails (6.7.7)
execjs
bootstrap-sass (3.3.7)
autoprefixer-rails (>= 5.2.1)
@ -77,7 +77,7 @@ GEM
rack (>= 1.4.5, < 2.0)
thor (>= 0.15.2, < 2.0)
tilt (~> 1.4.1, < 2.0)
middleman-hashicorp (0.3.13)
middleman-hashicorp (0.3.15)
bootstrap-sass (~> 3.3)
builder (~> 3.2)
middleman (~> 3.4)
@ -151,7 +151,7 @@ PLATFORMS
ruby
DEPENDENCIES
middleman-hashicorp (= 0.3.13)
middleman-hashicorp (= 0.3.15)
BUNDLED WITH
1.14.6

View file

@ -1,4 +1,4 @@
VERSION?="0.3.13"
VERSION?="0.3.15"
website:
@echo "==> Starting website in Docker..."

View file

@ -8,7 +8,7 @@
"builders": [
{
"type": "docker",
"image": "hashicorp/middleman-hashicorp:0.3.13",
"image": "hashicorp/middleman-hashicorp:0.3.15",
"discard": "true",
"run_command": ["-d", "-i", "-t", "{{ .Image }}", "/bin/sh"]
}

View file

@ -1,64 +0,0 @@
//
// announcement bnr
// --------------------------------------------------
#announcement-bnr {
height: 40px;
flex-shrink: 0;
background-color: $black;
a,p{
font-size: 14px;
color: $white;
line-height: 40px;
margin-bottom: 0;
}
.link-blue{
margin-left: 5px;
color: $blue;
font-weight: 600;
}
.enterprise-logo{
position: relative;
top: 4px;
&:hover{
text-decoration: none;
svg{
rect{
fill: $blue;
@include transition(all .1s ease-in);
}
}
}
svg{
width: 128px;
fill: $white;
margin-right: 4px;
margin-left: 1px;
rect{
@include transition(all .1s ease-in);
}
}
}
}
@media (max-width: 768px) {
#announcement-bnr {
.tagline{
display: none;
}
}
}
@media (max-width: 320px) {
#announcement-bnr {
a,p{
font-size: 12px;
}
}
}

View file

@ -2,6 +2,15 @@
// API
// --------------------------------------------------
body.layout-http {
// Extend bootstrap's table and table-striped classes on generic markdown
// tables. This enables GHFM tables instead of HTML.
table {
@extend .table;
@extend .table-striped;
}
}
.bs-api-section dl, dl.api {
margin-top: 30px;
line-height: 20px;

View file

@ -3,13 +3,13 @@
// --------------------------------------------------
.v-btn {
box-shadow: 2px 3px 2px rgba(0,0,0,0.08);
display: inline-block;
background-color: $white;
color: $black;
border: 1px solid $black;
text-decoration: none;
@include transition(color .3s ease-in-out);
@include btn-shadow();
&.lrg {
font-size: 18px;

View file

@ -7,6 +7,7 @@ $docs-font-size: 15px;
body.layout-docs,
body.layout-inner,
body.layout-downloads,
body.layout-http,
body.layout-intro {
>.container {
.col-md-8[role=main] {
@ -30,7 +31,7 @@ body.layout-intro {
h4 > code,
h5 > code
h6 > code,
li > code,
li code,
table code,
p code,
tt,
@ -54,13 +55,13 @@ body.layout-intro {
li {
a {
color: $sidebar-link-color;
font-size: 13px;
font-size: $sidebar-font-size;
padding: 10px 0 10px 15px;
&:before {
color: $dark-blue;
color: $sidebar-link-color-active;
content: '\203A';
font-size: $docs-font-size;
font-size: $font-size;
left: 0;
line-height: 100%;
opacity: 0.4;

View file

@ -1,75 +1,20 @@
body.page-sub {
#footer {
padding: 0 0 40px 0;
.col-md-10 {
padding-top: 40px;
border-top: 1px solid $faint-gray;
}
}
}
#footer {
flex-shrink:0;
padding: 64px 0;
ul.footer-links {
li {
a {
color: $footer-link-color;
font-size: $footer-font-size;
font-family: $font-family-open-sans;
text-decoration: none;
.hashicorp-project {
margin-top: 24px;
@include project-by-hashicorp-style();
&:hover, &:focus, &:active {
background-color: transparent;
color: $footer-link-color-hover;
outline: 0;
}
&:hover {
color: $black;
}
}
}
.edit-page-link {
position: absolute;
top: -50px;
right: 15px;
z-index: 10;
a {
text-transform: uppercase;
color: $black;
font-size: 13px;
}
}
@media (max-width: 992px) {
.footer-links {
display: block;
text-align: center;
ul {
display: inline-block;;
float: none !important;
}
.footer-hashi {
display: block;
float: none !important;
}
}
}
@media (max-width: 414px) {
#footer {
ul {
display: block;
li {
display: block;
float: none;
}
&.external-links {
li {
svg {
position: relative;
left: 0;
top: 2px;
margin-top: 0;
margin-right: 4px;
}
@media (max-width: 992px) {
text-align: center;
}
}
}

View file

@ -29,25 +29,6 @@ h1 {
margin-bottom: 24px;
}
//all below styles are overriding corrections for below (min-width: 992px)
//below (min-width: 992px) these styles change
.navbar-nav {
margin: 0;
}
.navbar-right {
float: right !important;
}
.navbar-nav > li {
float: left;
}
.navbar-nav > li > a {
padding-top: 15px;
padding-bottom: 15px;
}
.center {
text-align: center;
}

View file

@ -1,39 +1,79 @@
//
// Header
// - Project Specific
// - edits should be made here
// --------------------------------------------------
#header {
flex-shrink:0;
// Hamburger menu
.navbar-toggle {
height: $header-height;
margin: 0;
padding-right: 15px;
border-radius: 0;
.navbar-brand {
.logo {
width: $project-logo-width;
padding-left: 50px;
font-size: 0;
text-transform: uppercase;
background: image-url('logo-text.svg') 0 0 no-repeat;
background-position: 0 46%;
background-size: contain;
.icon-bar {
border: 1px solid $black;
border-radius: 0;
}
}
.by-hashicorp {
@include project-by-hashicorp-style();
}
// Logo
.navbar-brand {
display: block;
margin: 0;
padding: 0;
.buttons {
margin-top: 2px; //baseline everything
}
}
.logo {
color: $header-link-color;
display: inline-block;
font-family: $font-family-klavika;
font-weight: $font-weight-bold;
font-size: 0;
height: $header-height;
line-height: $header-height;
width: 200px;
padding-left: 64px;
background: image-url('logo-text.svg') 0 0 no-repeat;
background-position: left center;
@media (max-width: 414px) {
#header {
.navbar-brand {
.logo {
width: $project-logo-width * .8;
&:hover, &:focus, &:active {
outline: 0;
text-decoration: none;
}
}
}
// Nav
ul.nav {
li {
a {
color: $header-link-color;
font-size: $header-font-size;
font-family: $font-family-open-sans;
height: $header-height;
line-height: $header-height;
padding: 0 10px;
margin: 0;
text-decoration: none;
&:hover, &:focus, &:active {
background-color: transparent;
color: $header-link-color-hover;
outline: 0;
svg {
fill: $header-link-color-hover;
}
}
svg {
fill: $header-link-color;
position: relative;
top: 2px;
width: 14px;
height: 14px;
margin-right: 3px;
}
}
}
}
.buttons {
margin-top: 2px;
}
}

View file

@ -1,15 +1,106 @@
.sidebar {
.sidebar-nav {
li {
a {
color: $black;
.sidebar-overlay {
background: $white;
opacity: 0;
position: fixed;
visibility: hidden;
z-index: 9999;
svg{
path{
fill: $black;
top: 0;
left: 0;
right: 0;
bottom: 0;
&.active {
opacity: 0.3;
visibility: visible;
}
}
.sidebar {
background-color: $white;
border: none;
display: block;
position: relative;
min-height: 100%;
overflow-y: auto;
overflow-x: hidden;
@include transition(all 0.5s cubic-bezier(0.55, 0, 0.1, 1));
@include clearfix();
.sidebar-divider, .divider {
width: 80%;
height: 1px;
margin: 8px auto;
background-color: #D7D7D7;
}
.sidebar-header {
position: relative;
margin-bottom: 16px;
}
.sidebar-image {
background: image-url('logo-text.svg') 0 0 no-repeat;
display: block;
margin: 24px auto 14px auto;
height: 56px;
width: 153px;
}
.sidebar-nav {
margin: 0;
padding: 0;
text-align: center;
li {
position: relative;
list-style-type: none;
text-align: center;
a {
color: $sidebar-link-color;
position: relative;
cursor: pointer;
user-select: none;
font-family: $font-family-open-sans;
font-weight: $font-weight-reg;
font-size: $sidebar-font-size;
&:hover, &:focus, &:active {
background: transparent;
color: $sidebar-link-color-hover;
outline: 0;
text-decoration: none;
svg {
fill: $sidebar-link-color-hover;
}
}
svg {
fill: $sidebar-link-color;
top: 2px;
width: 14px;
height: 14px;
margin-bottom: -2px;
margin-right: 4px;
}
}
}
}
}
.sidebar {
box-shadow: 0px 2px 25px rgba(0, 0, 0, 0.15);
position: fixed;
width: 0;
z-index: 10000;
top: 0;
bottom: 0;
right: 0;
&.open {
width: 280px;
}
}

View file

@ -32,8 +32,20 @@ $font-weight-bold: 600;
// Body
$body-font-color: $gray-darker;
$body-link-color: $dark-blue;
// Sidebar
$sidebar-font-size: $font-size - 2;
$sidebar-link-color: $body-font-color;
$sidebar-link-color-hover: $black;
$sidebar-link-color-active: $dark-blue;
// Header
$header-font-size: $font-size - 2;
$header-link-color: $body-font-color;
$header-link-color-hover: $black;
// Footer
$footer-font-size: $font-size - 2;
$footer-link-color: $body-font-color;
$footer-link-color-hover: $black;

View file

@ -1,7 +1,7 @@
@import 'bootstrap-sprockets';
@import 'bootstrap';
@import url("//fonts.googleapis.com/css?family=Open+Sans:300,400,700|Open+Sans:300,600,400|Ubuntu+Mono");
@import url("//fonts.googleapis.com/css?family=Open+Sans:400,600");
// Core variables and mixins
@import '_variables';
@ -12,14 +12,10 @@
//Mega Nav
@import 'hashicorp/mega-nav';
// Hashicorp Shared Project Styles
@import 'hashicorp-shared/_hashicorp-utility';
@import 'hashicorp-shared/_project-utility';
@import 'hashicorp-shared/_hashicorp-header';
@import 'hashicorp-shared/_hashicorp-sidebar';
// Anchor links
@import 'hashicorp/anchor-links';
// Components
@import '_announcement-bnr';
@import '_header';
@import '_footer';
@import '_buttons';

View file

@ -1,338 +0,0 @@
//
// Hashicorp header
// - Shared throughout projects
// - Edits should not be made here
// --------------------------------------------------
#header{
position: relative;
margin-bottom: 0;
}
.navigation {
color: black;
text-rendering: optimizeLegibility;
transition: all 1s ease;
&.white{
.navbar-brand {
.logo {
color: white;
}
}
.main-links,
.external-links {
li > a {
&:hover{
opacity: 1;
}
}
}
}
.navbar-toggle{
height: $header-height;
margin: 0;
border-radius: 0;
.icon-bar{
border: 1px solid $black;
border-radius: 0;
}
}
.external-links {
&.white{
svg path{
fill: $white;
}
}
li {
position: relative;
svg path{
@include transition( all 300ms ease-in );
}
&:hover{
svg path{
@include transition( all 300ms ease-in );
}
}
@include project-svg-external-links-style();
&.download{
margin-right: 10px;
}
&.github{
a{
margin-right: 0;
}
}
> a {
padding-left: 12px !important;
svg{
position: absolute;
left: -8px;
top: 50%;
margin-top: -8px;
width: 14px;
height: 14px;
}
}
}
}
.main-links{
margin-right: $nav-margin-right;
}
.main-links,
.external-links {
&.white{
li > a {
color: white;
}
}
li > a {
@include hashi-a-style();
margin: 0 10px;
padding-top: 1px;
line-height: $header-height;
@include project-a-style();
}
}
.nav > li > a:hover, .nav > li > a:focus {
background-color: transparent;
@include transition( all 300ms ease-in );
}
}
.navbar-brand {
display: block;
height: $header-height;
padding: 0;
margin: 0 10px 0 0;
.logo{
display: inline-block;
height: $header-height;
vertical-align:top;
padding: 0;
line-height: $header-height;
padding-left: $project-logo-width + $project-logo-pad-left;
background-position: 0 center;
@include transition(all 300ms ease-in);
&:hover{
@include transition(all 300ms ease-in);
text-decoration: none;
}
}
}
.navbar-toggle{
&.white{
.icon-bar{
border: 1px solid white;
}
}
}
.by-hashicorp{
display: inline-block;
vertical-align:top;
height: $header-height;
margin-left: 3px;
padding-top: 2px;
color: black;
line-height: $header-height;
font-family: $header-font-family;
font-weight: 600;
font-size: 0;
text-decoration: none;
&.white{
color: white;
font-weight: 300;
svg{
path,
polygon{
fill: white;
}
}
&:focus,
&:hover{
text-decoration: none;
color: white;
}
}
&:focus,
&:hover{
text-decoration: none;
color: black;
}
.svg-wrap{
font-size: 13px;
}
svg{
&.svg-by{
width: $by-hashicorp-width;
height: $by-hashicorp-height;
margin-bottom: -4px;
margin-left: 4px;
}
&.svg-logo{
width: 16px;
height: 16px;
margin-bottom: -3px;
margin-left: 4px;
}
path,
polygon{
fill: black;
@include transition(all 300ms ease-in);
&:hover{
@include transition(all 300ms ease-in);
}
}
.svg-bg-line{
@include transition(all 300ms ease-in);
&:hover{
@include transition(all 300ms ease-in);
}
}
}
}
.hashicorp-project{
display: inline-block;
height: 30px;
line-height: 30px;
text-decoration: none;
font-size: 14px;
color: $black;
font-weight: 600;
&.white{
color: white;
svg{
path,
polygon{
fill: white;
}
line{
stroke: white;
}
}
}
&:focus{
text-decoration: none;
}
&:hover{
text-decoration: none;
svg{
&.svg-by{
line{
stroke: $purple;
}
}
}
}
span{
margin-right: 4px;
font-family: $header-font-family;
font-weight: 500;
}
span,
svg{
display: inline-block;
}
svg{
&.svg-by{
width: $by-hashicorp-width;
height: $by-hashicorp-height;
margin-bottom: -4px;
margin-left: -3px;
}
&.svg-logo{
width: 30px;
height: 30px;
margin-bottom: -10px;
margin-left: -1px;
}
path,
line{
fill: $black;
@include transition(all 300ms ease-in);
&:hover{
@include transition(all 300ms ease-in);
}
}
.svg-bg-line{
@include transition(all 300ms ease-in);
&:hover{
@include transition(all 300ms ease-in);
}
}
}
}
@media (max-width: 480px) {
.navigation {
.main-links{
margin-right: 0;
}
}
}
@media (max-width: 414px) {
#header {
.navbar-toggle{
padding-top: 10px;
height: $header-mobile-height;
}
.navbar-brand {
height: $header-mobile-height;
.logo{
height: $header-mobile-height;
line-height: $header-mobile-height;
}
.by-hashicorp{
height: $header-mobile-height;
line-height: $header-mobile-height;
padding-top: 0;
}
}
.main-links,
.external-links {
li > a {
line-height: $header-mobile-height;
}
}
}
}

View file

@ -1,284 +0,0 @@
//
// Hashicorp Sidebar
// - Shared throughout projects
// - Edits should not be made here
// --------------------------------------------------
// Base variables
// --------------------------------------------------
$screen-tablet: 768px;
$gray-darker: #212121; // #212121 - text
$gray-secondary: #757575; // #757575 - secondary text, icons
$gray: #bdbdbd; // #bdbdbd - hint text
$gray-light: #e0e0e0; // #e0e0e0 - divider
$gray-lighter: #f5f5f5; // #f5f5f5 - background
$link-color: $gray-darker;
$link-bg: transparent;
$link-hover-color: $gray-lighter;
$link-hover-bg: $gray-lighter;
$link-active-color: $gray-darker;
$link-active-bg: $gray-light;
$link-disabled-color: $gray-light;
$link-disabled-bg: transparent;
/* -- Sidebar style ------------------------------- */
// Sidebar variables
// --------------------------------------------------
$zindex-sidebar-fixed: 1035;
$sidebar-desktop-width: 280px;
$sidebar-width: 240px;
$sidebar-padding: 16px;
$sidebar-divider: $sidebar-padding/2;
$sidebar-icon-width: 40px;
$sidebar-icon-height: 20px;
@mixin sidebar-nav-base {
text-align: center;
&:last-child{
border-bottom: none;
}
li > a {
background-color: $link-bg;
}
li:hover > a {
background-color: $link-hover-bg;
}
li:focus > a, li > a:focus {
background-color: $link-bg;
}
> .open > a {
&,
&:hover,
&:focus {
background-color: $link-hover-bg;
}
}
> .active > a {
&,
&:hover,
&:focus {
background-color: $link-active-bg;
}
}
> .disabled > a {
&,
&:hover,
&:focus {
background-color: $link-disabled-bg;
}
}
// Dropdown menu items
> .dropdown {
// Remove background color from open dropdown
> .dropdown-menu {
background-color: $link-hover-bg;
> li > a {
&:focus {
background-color: $link-hover-bg;
}
&:hover {
background-color: $link-hover-bg;
}
}
> .active > a {
&,
&:hover,
&:focus {
color: $link-active-color;
background-color: $link-active-bg;
}
}
}
}
}
//
// Sidebar
// --------------------------------------------------
// Sidebar Elements
//
// Basic style of sidebar elements
.sidebar {
position: relative;
display: block;
min-height: 100%;
overflow-y: auto;
overflow-x: hidden;
border: none;
@include transition(all 0.5s cubic-bezier(0.55, 0, 0.1, 1));
@include clearfix();
background-color: $white;
ul{
padding-left: 0;
list-style-type: none;
}
.sidebar-divider, .divider {
width: 80%;
height: 1px;
margin: 8px auto;
background-color: lighten($gray, 20%);
}
// Sidebar heading
//----------------
.sidebar-header {
position: relative;
margin-bottom: $sidebar-padding;
@include transition(all .2s ease-in-out);
}
.sidebar-image {
background-image: image-url('logo-text.svg');
background-position: center center;
background-repeat: no-repeat;
height: 72px;
margin-top: 24px;
}
// Sidebar icons
//----------------
.sidebar-icon {
display: inline-block;
height: $sidebar-icon-height;
margin-right: $sidebar-divider;
text-align: left;
font-size: $sidebar-icon-height;
vertical-align: middle;
&:before, &:after {
vertical-align: middle;
}
}
.sidebar-nav {
margin: 0;
padding: 0;
@include sidebar-nav-base();
// Links
//----------------
li {
position: relative;
list-style-type: none;
text-align: center;
a {
position: relative;
cursor: pointer;
user-select: none;
@include hashi-a-style-core();
svg{
top: 2px;
width: 14px;
height: 14px;
margin-bottom: -2px;
margin-right: 4px;
}
}
}
}
}
// Sidebar toggling
//
// Hide sidebar
.sidebar {
width: 0;
@include translate3d(-$sidebar-desktop-width, 0, 0);
&.open {
min-width: $sidebar-desktop-width;
width: $sidebar-desktop-width;
@include translate3d(0, 0, 0);
}
}
// Sidebar positions: fix the left/right sidebars
.sidebar-fixed-left,
.sidebar-fixed-right,
.sidebar-stacked {
position: fixed;
top: 0;
bottom: 0;
z-index: $zindex-sidebar-fixed;
}
.sidebar-stacked {
left: 0;
}
.sidebar-fixed-left {
left: 0;
box-shadow: 2px 0px 25px rgba(0,0,0,0.15);
-webkit-box-shadow: 2px 0px 25px rgba(0,0,0,0.15);
}
.sidebar-fixed-right {
right: 0;
box-shadow: 0px 2px 25px rgba(0,0,0,0.15);
-webkit-box-shadow: 0px 2px 25px rgba(0,0,0,0.15);
@include translate3d($sidebar-desktop-width, 0, 0);
&.open {
@include translate3d(0, 0, 0);
}
.icon-material-sidebar-arrow:before {
content: "\e614"; // icon-material-arrow-forward
}
}
// Sidebar size
//
// Change size of sidebar and sidebar elements on small screens
@media (max-width: $screen-tablet) {
.sidebar.open {
min-width: $sidebar-width;
width: $sidebar-width;
}
}
.sidebar-overlay {
visibility: hidden;
position: fixed;
top: 0;
left: 0;
right: 0;
bottom: 0;
opacity: 0;
background: $white;
z-index: $zindex-sidebar-fixed - 1;
-webkit-transition: visibility 0 linear .4s,opacity .4s cubic-bezier(.4,0,.2,1);
-moz-transition: visibility 0 linear .4s,opacity .4s cubic-bezier(.4,0,.2,1);
transition: visibility 0 linear .4s,opacity .4s cubic-bezier(.4,0,.2,1);
-webkit-transform: translateZ(0);
-moz-transform: translateZ(0);
-ms-transform: translateZ(0);
-o-transform: translateZ(0);
transform: translateZ(0);
}
.sidebar-overlay.active {
opacity: 0.3;
visibility: visible;
-webkit-transition-delay: 0;
-moz-transition-delay: 0;
transition-delay: 0;
}

View file

@ -1,125 +0,0 @@
//
// Hashicorp Nav (header/footer) Utiliy Vars and Mixins
//
// Notes:
// - Include this in Application.scss before header and feature-footer
// - Open Sans Google (Semibold - 600) font needs to be included if not already
// --------------------------------------------------
// Variables
$font-family-open-sans: 'Open Sans', 'Helvetica Neue', Helvetica, Arial, sans-serif;
$header-font-family: $font-family-open-sans;
$header-font-weight: 600; // semi-bold
$header-height: 74px;
$header-mobile-height: 60px;
$by-hashicorp-width: 74px;
$by-hashicorp-height: 16px;
$nav-margin-right: 8px;
// Mixins
@mixin hashi-a-style-core{
font-family: $header-font-family;
font-weight: $header-font-weight;
font-size: 14px;
//letter-spacing: 0.0625em;
}
@mixin hashi-a-style{
margin: 0 15px;
padding: 0;
line-height: 22px;
@include hashi-a-style-core();
@include transition( all 0.3s ease );
&:hover{
@include transition( all 0.3s ease );
background-color: transparent;
}
}
@mixin v-nav-style{
margin: 0 15px;
padding: 0;
line-height: 26px;
color: #2E2E2E;
font-size: 14px;
font-weight: 400;
@include transition( color 0.3s ease );
&:hover{
color: $blue;
@include transition( color 0.3s ease );
background-color: transparent;
}
}
//general shared project mixins
@mixin img-retina($image1x, $image, $width, $height) {
background-image: image-url($image1x);
background-size: $width $height;
background-repeat: no-repeat;
@media (min--moz-device-pixel-ratio: 1.3),
(-o-min-device-pixel-ratio: 2.6/2),
(-webkit-min-device-pixel-ratio: 1.3),
(min-device-pixel-ratio: 1.3),
(min-resolution: 1.3dppx) {
/* on retina, use image that's scaled by 2 */
background-image: image-url($image);
background-size: $width $height;
}
}
//wrapper for img-retina when using pngs
@mixin img-ret-rails-jpg($img-name, $width, $height){
@include img-retina( asset_path('#{$imagePath}#{$img-name}.jpg'), asset_path('#{$imagePath}#{$img-name}@2x.jpg'), $width, $height);
}
@mixin img-ret-rails-png($img-name, $width, $height){
@include img-retina( asset_path('#{$imagePath}#{$img-name}.png'), asset_path('#{$imagePath}#{$img-name}@2x.png'), $width, $height);
}
@mixin skewY($skew) {
-webkit-transform: skewY($skew);
-moz-transform: skewY($skew);
-ms-transform: skewY($skew);
-o-transform: skewY($skew);
transform: skewY($skew);
}
//
// -------------------------
@mixin anti-alias() {
text-rendering: optimizeLegibility;
-webkit-font-smoothing: antialiased;
}
@mixin open-light() {
font-family: $font-family-open-sans;
font-weight: 300;
}
@mixin open() {
font-family: $font-family-open-sans;
font-weight: 400;
}
@mixin open-sb() {
font-family: $font-family-open-sans;
font-weight: 600;
}
@mixin open-bold() {
font-family: $font-family-open-sans;
font-weight: 700;
}
@mixin bez-1-transition{
@include transition( all 300ms ease-in-out );
}
@mixin btn-shadow{
box-shadow: 2px 3px 2px rgba(0,0,0,0.08);
}

View file

@ -1,56 +0,0 @@
//
// Mixins Specific to project
// - make edits to mixins here
// --------------------------------------------------
// Variables
$header-font-family: $font-family-open-sans;
$project-logo-width: 121px;
$project-logo-height: 42px;
$project-logo-pad-left: 0px;
$blue: darken($blue, 5%);
// Mixins
@mixin project-a-style{
font-size: 14px;
font-weight: 400;
color: $gray;
&:hover{
color: $blue;
}
}
@mixin project-footer-a-style{
&:hover{
}
}
@mixin project-svg-external-links-style{
svg path{
fill: $black;
}
&:hover{
svg path{
fill: $blue;
}
}
}
@mixin project-by-hashicorp-style{
@include transition(all 300ms ease-in);
&:hover{
@include transition(all 300ms ease-in);
svg{
.svg-bg-line{
fill: $black;
}
}
}
}

View file

@ -13,7 +13,7 @@ Name: `app-id`
## Deprecation Notice
As of Vault 0.6.1, App ID is deprecated in favor of
[AppRole](https://www.vaultproject.io/docs/auth/approle.html). AppRole can
[AppRole](/docs/auth/approle.html). AppRole can
accommodate the same workflow as App ID while enabling much more secure and
flexible management and other types of authentication workflows. No new
features or enhancements are planned for App ID, and new users should use

View file

@ -58,7 +58,7 @@ entry, even if these are then distributed via different paths. However, in Pull
mode, even though the RoleID must be known in order to distribute it to the
client, the SecretID can be kept confidential from all parties except for the
final authenticating client by using [Response
Wrapping](https://www.vaultproject.io/docs/concepts/response-wrapping.html).
Wrapping](/docs/concepts/response-wrapping.html).
Push mode is available for App-ID workflow compatibility, which in some
specific cases is preferable, but in most cases Pull mode is more secure and

View file

@ -145,7 +145,7 @@ not specify the policy component, the client will inherit the allowed policies s
on the role. If the role tag creation specifies the policy component but it contains
no policies, the token will contain only the `default` policy; by default, this policy
allows only manipulation (revocation, renewal, lookup) of the existing token, plus
access to its [cubbyhole](https://www.vaultproject.io/docs/secrets/cubbyhole/index.html).
access to its [cubbyhole](/docs/secrets/cubbyhole/index.html).
This can be useful to allow instances access to a secure "scratch space" for
storing data (via the token's cubbyhole) but without granting any access to
other resources provided by or resident in Vault.

View file

@ -46,7 +46,7 @@ The properties of the dev server:
The dev server should be used for experimentation with Vault features, such
as different authentication backends, secret backends, audit backends, etc.
If you're new to Vault, you may want to pick up with [Your First
Secret](https://www.vaultproject.io/intro/getting-started/first-secret.html) in
Secret](/intro/getting-started/first-secret.html) in
our getting started guide.
In addition to experimentation, the dev server is very easy to automate

View file

@ -143,7 +143,7 @@ values) that a user is allowed to specify when calling a path.
These parameters can be used to set minimums/maximums on TTLs set by clients
when requesting that a response be
[wrapped](https://www.vaultproject.io/docs/concepts/response-wrapping.html), with a granularity of a second. These can either be specified as a number of seconds or a string with a `s`, `m`, or `h` suffix indicating seconds, minutes, and hours respectively.
[wrapped](/docs/concepts/response-wrapping.html), with a granularity of a second. These can either be specified as a number of seconds or a string with a `s`, `m`, or `h` suffix indicating seconds, minutes, and hours respectively.
In practice, setting a minimum TTL of one second effectively makes response
wrapping mandatory for a particular path.

View file

@ -18,7 +18,7 @@ accidental disclosure, especially if the secret is being transmitted in
plaintext.
In Vault 0.3 the
[`cubbyhole`](https://www.vaultproject.io/docs/secrets/cubbyhole/index.html)
[`cubbyhole`](/docs/secrets/cubbyhole/index.html)
backend was introduced, providing storage scoped to a single token. The
[Cubbyhole Principles blog
post](https://www.hashicorp.com/blog/vault-cubbyhole-principles.html) described
@ -33,11 +33,11 @@ Starting in 0.6, this concept is taken to its logical conclusion: almost every
response that Vault generates can be automatically wrapped inside a single-use,
limited-time-to-live token's cubbyhole. Details can be found in the
[`cubbyhole` backend
documentation](https://www.vaultproject.io/docs/secrets/cubbyhole/index.html).
documentation](/docs/secrets/cubbyhole/index.html).
This capability should be carefully considered when planning your security
architecture. For instance, many Vault deployments use the
[`pki`](https://www.vaultproject.io/docs/secrets/pki/index.html) backend to
[`pki`](/docs/secrets/pki/index.html) backend to
generate TLS certificates and private keys for services. If you do not wish
these services to have access to the generation API, a trusted third party
could generate the certificates and private keys and pass the resulting

View file

@ -37,7 +37,7 @@ Read on for a deeper dive into token concepts.
Often in documentation or in help channels, the "token store" is referenced.
This is the same as the [`token` authentication
backend](https://www.vaultproject.io/docs/auth/token.html). This is a special
backend](/docs/auth/token.html). This is a special
backend in that it is responsible for creating and storing tokens, and cannot
be disabled. It is also the only authentication backend that has no login
capability -- all actions require existing authenticated tokens.
@ -63,7 +63,7 @@ used for just enough initial setup (usually, setting up authentication backends
and policies necessary to allow administrators to acquire more limited tokens)
or in emergencies, and are revoked immediately after they are no longer needed.
If a new root token is needed, the `generate-root` command and associated [API
endpoint](https://www.vaultproject.io/docs/http/sys-generate-root.html) can be
endpoint](/docs/http/sys-generate-root.html) can be
used to generate one on-the-fly.
It is also good security practice for there to be multiple eyes on a terminal
@ -149,7 +149,7 @@ token's information is looked up. It is based on a combination of factors:
1. The system max TTL, which is 32 days but can be changed in Vault's
configuration file
2. The max TTL set on a mount using [mount
tuning](https://www.vaultproject.io/docs/http/sys-mounts.html). This value
tuning](/docs/http/sys-mounts.html). This value
is allowed to override the system max TTL -- it can be longer or shorter,
and if set this value will be respected.
3. A value suggested by the authentication backend that issued the token. This

View file

@ -7,21 +7,15 @@ description: |-
---
If you're unfamiliar with Vault Replication concepts, please first look at the
[general information
page](https://www.vaultproject.io/docs/vault-enterprise/replication/index.html).
More details can be found in the [replication
internals](https://www.vaultproject.io/docs/internals/replication.html)
document.
[general information page](/docs/vault-enterprise/replication/index.html). More
details can be found in the
[replication internals](/docs/internals/replication.html) document.
Also, note that full details of the API are available the endpoints relevant to
the
[primary](https://www.vaultproject.io/docs/http/sys-replication-primary.html)
cluster, the
[secondary](https://www.vaultproject.io/docs/http/sys-replication-secondary.html)
cluster, and endpoints [relevant to
both](https://www.vaultproject.io/docs/http/sys-replication.html).
Vault replication also includes a complete API. For more information, please see
the [Vault Replication API documentation](/docs/http/system/replication.html)
## Activating Replication
## Activating Replication
### Activating the Primary
@ -47,7 +41,7 @@ To fetch a secondary bootstrap token, run:
The value for `id` is opaque to Vault and can be any identifying value you want;
this can be used later to revoke the secondary and will be listed when you read
replication status on the primary. You will get back a normal wrapped response,
except that the token will be a JWT instead of UUID-formatted random bytes.
except that the token will be a JWT instead of UUID-formatted random bytes.
### Activating a Secondary
@ -79,7 +73,7 @@ remove it from rotation (e.g. if using Consul for service discovery), but if a
standby does not attempt taking over it will throw errors. We hope to make this
workflow better in a future update.
### Dev-Mode Root Tokens
### Dev-Mode Root Tokens
To ease development and testing, when both the primary and secondary are
running in development mode, the initial root token created by the primary
@ -95,7 +89,7 @@ as policies and auth backend configuration are replicated.
The generate-root command can be also be used to generate a root token local to
the secondary cluster.
## Managing Vault Replication
## Managing Vault Replication
Vaults replication model is intended to allow horizontally scaling Vaults
functions rather than to act in a strict Disaster Recovery (DR) capacity. As a
@ -161,7 +155,7 @@ mounts would be unable to be read).
In normal Vault usage, if Vault has at least one audit backend configured and
is unable to successfully log to at least one backend, it will block further
requests.
requests.
Replicated audit mounts must be able to successfully log on all replicated
clusters. For example, if using the file backend, the configured path must be
@ -177,12 +171,10 @@ secondaries are ever reconnected.
### Disaster Recovery
At the moment, because leases and tokens are not replicated, if you need true
DR, you will need a DR solution per cluster (similar to non-replicated Vault).
DR, you will need a DR solution per cluster (similar to non-replicated Vault).
Local backend mounts are not replicated and their use will require existing DR
mechanisms if DR is necessary in your implementation.
mechanisms if DR is necessary in your implementation.
We may pursue a dedicated Disaster Recovery-focused Replication Mode at a
future time.
future time.

View file

@ -51,5 +51,5 @@ If using the Consul HA storage backend, Vault will now automatically register
itself as the `vault` service and perform its own health checks/lifecycle
status management. This behavior can be adjusted or turned off in Vault's
configuration; see the
[documentation](https://www.vaultproject.io/docs/config/index.html#check_timeout)
[documentation](/docs/config/index.html#check_timeout)
for details.

View file

@ -16,7 +16,7 @@ carefully.
Once an active node is running 0.6.1, only standby nodes running 0.6.1+ will be
able to form an HA cluster. If following our [general upgrade
instructions](https://www.vaultproject.io/docs/install/upgrade.html) this will
instructions](/docs/install/upgrade.html) this will
not be an issue.
## Health Endpoint Status Code Changes
@ -39,7 +39,7 @@ each status code (including `500`).
Root tokens (tokens with the `root` policy) can no longer be created except by
another root token or the
[`generate-root`](https://www.vaultproject.io/docs/http/sys-generate-root.html)
[`generate-root`](/docs/http/sys-generate-root.html)
endpoint or CLI command.
## PKI Backend Certificates Will Contain Default Key Usages
@ -50,14 +50,14 @@ compatibility with some software that requires strict adherence to RFCs, such
as OpenVPN.
This behavior is fully adjustable; see the [PKI backend
documentation](https://www.vaultproject.io/docs/secrets/pki/index.html) for
documentation](/docs/secrets/pki/index.html) for
details.
## DynamoDB Does Not Support HA By Default
If using DynamoDB and want to use HA support, you will need to explicitly
enable it in Vault's configuration; see the
[documentation](https://www.vaultproject.io/docs/config/index.html#ha_enabled)
[documentation](/docs/config/index.html#ha_enabled)
for details.
If you are already using DynamoDB in an HA fashion and wish to keep doing so,
@ -83,7 +83,7 @@ unfortunately has the side effect that `memberOf` is no longer searched for by
default, which is a breaking change for many existing setups.
`Scenario 2` in the [updated
documentation](https://www.vaultproject.io/docs/auth/ldap.html) shows an
documentation](/docs/auth/ldap.html) shows an
example of configuring the backend to query `memberOf`. It is recommended that
a test Vault server be set up and that successful authentication can be
performed using the new configuration before upgrading a primary or production
@ -97,7 +97,7 @@ configuration can be specified successfully.
## App-ID is Deprecated
With the addition of of the new [AppRole
backend](https://www.vaultproject.io/docs/auth/approle.html), App-ID is
backend](/docs/auth/approle.html), App-ID is
deprecated. There are no current plans to remove it, but we encourage using
AppRole whenever possible, as it offers enhanced functionality and can
accommodate many more types of authentication paradigms. App-ID will receive

View file

@ -16,7 +16,7 @@ for Vault 0.6.2. Please read it carefully.
In 0.6.1 this feature was in beta and required opting-in, but is now enabled by
default. This can be disabled via the `"disable_clustering"` parameter in
Vault's [config](https://www.vaultproject.io/docs/config/index.html), or
Vault's [config](/docs/config/index.html), or
per-request with the `X-Vault-No-Request-Forwarding` header.
## AppRole Role Constraints

View file

@ -170,5 +170,5 @@ The following HTTP status codes are used throughout the API.
## Limits
A maximum request size of 32MB is imposed to prevent a denial
A maximum request size of 32MB is imposed to prevent a denial
of service attack with arbitrarily large requests.

View file

@ -0,0 +1,357 @@
---
layout: "http"
page_title: "HTTP API"
sidebar_current: "docs-http-secret-aws"
description: |-
This is the API documentation for the Vault AWS secret backend.
---
# AWS Secret Backend HTTP API
This is the API documentation for the Vault AWS secret backend. For general
information about the usage and operation of the AWS backend, please see the
[Vault AWS backend documentation](/docs/secrets/aws/index.html).
This documentation assumes the AWS backend is mounted at the `/aws` path in
Vault. Since it is possible to mount secret backends at any location, please
update your API calls accordingly.
## Configure Root IAM Credentials
This endpoint configures the root IAM credentials to communicate with AWS. There
are multiple ways to pass root IAM credentials to the Vault server, specified
below with the highest precedence first. If credentials already exist, this will
overwrite them.
- Static credentials provided to the API as a payload
- Credentials in the `AWS_ACCESS_KEY`, `AWS_SECRET_KEY`, and `AWS_REGION`
environment variables **on the server**
- Querying the EC2 metadata service if the **Vault server** is on EC2 and has
querying capabilities
At present, this endpoint does not confirm that the provided AWS credentials are
valid AWS credentials with proper permissions.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `POST` | `/aws/config/root` | `204 (empty body)` |
### Parameters
- `access_key` `(string: <required>)` Specifies the AWS access key ID.
- `secret_key` `(string: <required>)`  Specifies the AWS secret access key.
- `region` `(string: <required>)`  Specifies the AWS region.
### Sample Payload
```json
{
"access_key": "AKIA...",
"secret_key": "2J+...",
"region": "us-east-1"
}
```
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request POST \
--data @payload.json \
https://vault.rocks/v1/aws/config/root
```
## Configure Lease
This endpoint configures lease settings for the AWS secret backend. It is
optional, as there are default values for `lease` and `lease_max`.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `POST` | `/aws/config/lease` | `204 (empty body)` |
### Parameters
- `lease` `(string: <required>)` Specifies the lease value provided as a
string duration with time suffix. "h" (hour) is the largest suffix.
- `lease_max` `(string: <required>)`  Specifies the maximum lease value
provided as a string duration with time suffix. "h" (hour) is the largest
suffix.
### Sample Payload
```json
{
"lease": "30m",
"lease_max": "12h"
}
```
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request POST \
--data @payload.json \
https://vault.rocks/v1/aws/config/lease
```
## Read Lease
This endpoint returns the current lease settings for the AWS secret backend.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `GET` | `/aws/config/lease` | `200 application/json` |
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
https://vault.rocks/v1/aws/config/lease
```
### Sample Response
```json
{
"data": {
"lease": "30m0s",
"lease_max": "12h0m0s"
}
}
```
## Create/Update Role
This endpoint creates or updates the role with the given `name`. If a role with
the name does not exist, it will be created. If the role exists, it will be
updated with the new attributes.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `POST` | `/aws/roles/:name` | `204 (empty body)` |
### Parameters
- `name` `(string: <required>)`  Specifies the name of the role to create. This
is part of the request URL.
- `policy` `(string: <required unless arn provided>)` Specifies the IAM policy
in JSON format.
- `arn` `(string: <required unless policy provided>)`  Specifies the full ARN
reference to the desired existing policy.
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request POST \
--data @payload.json \
https://vault.rocks/v1/aws/roles/example-role
```
### Sample Payloads
Using an inline IAM policy:
```json
{
"policy": "{\"Version\": \"...\"}",
}
```
Using an ARN:
```json
{
"arn": "arn:aws:iam::123456789012:user/David"
}
```
## Read Role
This endpoint queries an existing role by the given name. If the role does not
exist, a 404 is returned.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `GET` | `/aws/roles/:name` | `200 application/json` |
### Parameters
- `name` `(string: <required>)`  Specifies the name of the role to read. This
is part of the request URL.
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
https://vault.rocks/v1/aws/roles/example-role
```
### Sample Responses
For an inline IAM policy:
```json
{
"data": {
"policy": "{\"Version\": \"...\"}"
}
}
```
For an ARN:
```json
{
"data": {
"arn": "arn:aws:iam::123456789012:user/David"
}
}
```
## List Roles
This endpoint lists all existing roles in the backend.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `LIST` | `/aws/roles` | `200 application/json` |
### Sample Request
```
$ curl
--header "X-Vault-Token: ..." \
--request LIST \
https://vault.rocks/v1/aws/roles
```
### Sample Response
```json
{
"data": {
"keys": [
"example-role"
]
}
}
```
## Delete Role
This endpoint deletes an existing role by the given name. If the role does not
exist, a 404 is returned.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `DELET` | `/aws/roles/:name` | `204 (empty body)` |
### Parameters
- `name` `(string: <required>)`  Specifies the name of the role to delete. This
is part of the request URL.
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request DELETE \
https://vault.rocks/v1/aws/roles/example-role
```
## Generate IAM Credentials
This endpoint generates dynamic IAM credentials based on the named role. This
role must be created before queried.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `GET` | `/aws/creds/:name` | `200 application/json` |
### Parameters
- `name` `(string: <required>)`  Specifies the name of the role to generate
credentials againts. This is part of the request URL.
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
https://vault.rocks/v1/aws/creds/example-role
```
### Sample Response
```json
{
"data": {
"access_key": "AKIA...",
"secret_key": "xlCs...",
"security_token": null
}
}
```
## Generate IAM with STS
This generates a dynamic IAM credential with an STS token based on the named
role.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `POST` | `/aws/sts/:name` | `204 (empty body)` |
### Parameters
- `name` `(string: <required>)`  Specifies the name of the role against which
to create this STS credential. This is part of the request URL.
- `ttl` `(string: "3600s")` Specifies the TTL for the use of the STS token.
This is specified as a string with a duration suffix.
### Sample Payload
```json
{
"ttl": "5m"
}
```
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request POST \
--data @payload.json \
https://vault.rocks/v1/aws/sts/example-role
```
### Sample Response
```json
{
"data": {
"access_key": "AKIA...",
"secret_key": "xlCs...",
"security_token": "429255"
}
}
```

View file

@ -0,0 +1,239 @@
---
layout: "http"
page_title: "Cassandra Secret Backend - HTTP API"
sidebar_current: "docs-http-secret-cassandra"
description: |-
This is the API documentation for the Vault Cassandra secret backend.
---
# Cassandra Secret Backend HTTP API
This is the API documentation for the Vault Cassandra secret backend. For
general information about the usage and operation of the Cassandra backend,
please see the
[Vault Cassandra backend documentation](/docs/secrets/cassandra/index.html).
This documentation assumes the Cassandra backend is mounted at the `/cassandra`
path in Vault. Since it is possible to mount secret backends at any location,
please update your API calls accordingly.
## Configure Connection
This endpoint configures the connection information used to communicate with
Cassandra.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `POST` | `/cassandra/config/connection` | `204 (empty body)` |
### Parameters
- `hosts` `(string: <required>)` Specifies a set of comma-delineated Cassandra
hosts to connect to.
- `username` `(string: <required>)`  Specifies the username to use for
superuser access.
- `password` `(string: <required>)`  Specifies the password corresponding to
the given username.
- `tls` `(bool: true)` Specifies whether to use TLS when connecting to
Cassandra.
- `insecure_tls` `(bool: false)`  Specifies whether to skip verification of the
server certificate when using TLS.
- `pem_bundle` `(string: "")` Specifies concatenated PEM blocks containing a
certificate and private key; a certificate, private key, and issuing CA
certificate; or just a CA certificate.
- `pem_json` `(string: "")`  Specifies JSON containing a certificate and
private key; a certificate, private key, and issuing CA certificate; or just a
CA certificate. For convenience format is the same as the output of the
`issue` command from the `pki` backend; see
[the pki documentation](/docs/secrets/pki/index.html).
- `protocol_version` `(int: 2)`  Specifies the CQL protocol version to use.
- `connect_timeout` `(string: "5s")`  Specifies the connection timeout to use.
TLS works as follows:
- If `tls` is set to true, the connection will use TLS; this happens
automatically if `pem_bundle`, `pem_json`, or `insecure_tls` is set
- If `insecure_tls` is set to true, the connection will not perform verification
of the server certificate; this also sets `tls` to true
- If only `issuing_ca` is set in `pem_json`, or the only certificate in
`pem_bundle` is a CA certificate, the given CA certificate will be used for
server certificate verification; otherwise the system CA certificates will be
used
- If `certificate` and `private_key` are set in `pem_bundle` or `pem_json`,
client auth will be turned on for the connection
`pem_bundle` should be a PEM-concatenated bundle of a private key + client
certificate, an issuing CA certificate, or both. `pem_json` should contain the
same information; for convenience, the JSON format is the same as that output by
the issue command from the PKI backend.
### Sample Payload
```json
{
"hosts": "cassandra1.local",
"username": "user",
"password": "pass"
}
```
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request POST \
--data @payload.json \
https://vault.rocks/v1/cassandra/config/connection
```
## Create Role
This endpoint creates or updates the role definition.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `POST` | `/cassandra/roles/:name` | `204 (empty body)` |
### Parameters
- `creation_cql` `(string: "")`  Specifies the CQL statements executed to
create and configure the new user. Must be a semicolon-separated string, a
base64-encoded semicolon-separated string, a serialized JSON string array, or
a base64-encoded serialized JSON string array. The '{{username}}' and
'{{password}}' values will be substituted; it is required that these
parameters are in single quotes. The default creates a non-superuser user with
no authorization grants.
- `rollback_cql` `(string: "")` Specifies the CQL statements executed to
attempt a rollback if an error is encountered during user creation. The
default is to delete the user. Must be a semicolon-separated string, a
base64-encoded semicolon-separated string, a serialized JSON string array, or
a base64-encoded serialized JSON string array. The '{{username}}' and
'{{password}}' values will be substituted; it is required that these
parameters are in single quotes.
- `lease` `(string: "")`  Specifies the lease value provided as a string
duration with time suffix. "h" hour is the largest suffix.
- `consistency` `(string: "Quorum")`  Specifies the consistency level value
provided as a string. Determines the consistency level used for operations
performed on the Cassandra database.
### Sample Payload
```json
{
"creation_cql": "CREATE USER ..."
}
```
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request POST \
--data @payload.json \
https://vault.rocks/v1/cassandra/roles/my-role
```
## Read Role
This endpoint queries the role definition.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `GET` | `/cassandra/roles/:name` | `200 application/json` |
### Parameters
- `name` `(string: <required>)`  Specifies the name of the role to read. This
is part of the request URL.
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
https://vault.rocks/v1/cassandra/roles/my-role
```
### Sample Response
```json
{
"data": {
"creation_cql": "CREATE USER...",
"rollback_cql": "DROP USER...",
"lease": "12h",
"consistency": "Quorum"
}
}
```
## Delete Role
This endpoint deletes the role definition.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `DELETE` | `/cassandra/roles/:name` | `204 (no body)` |
### Parameters
- `name` `(string: <required>)`  Specifies the name of the role to delete. This
is part of the request URL.
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request DELETE \
https://vault.rocks/v1/cassandra/roles/my-role
```
## Generate Credentials
This endpoint generates a new set of dynamic credentials based on the named
role.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `GET` | `/cassandra/creds/:name` | `200 application/json` |
### Parameters
- `name` `(string: <required>)`  Specifies the name of the role to create
credentials against. This is part of the request URL.
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \Z
https://vault.rocks/v1/cassandra/creds/my-role
```
### Sample Response
```json
{
"data": {
"username": "vault-root-1430158508-126",
"password": "132ae3ef-5a64-7499-351e-bfe59f3a2a21"
}
}
```

View file

@ -0,0 +1,201 @@
---
layout: "http"
page_title: "Consul Secret Backend - HTTP API"
sidebar_current: "docs-http-secret-consul"
description: |-
This is the API documentation for the Vault Consul secret backend.
---
# Consul Secret Backend HTTP API
This is the API documentation for the Vault Consul secret backend. For general
information about the usage and operation of the Consul backend, please see the
[Vault Consul backend documentation](/docs/secrets/consul/index.html).
This documentation assumes the Consul backend is mounted at the `/consul` path
in Vault. Since it is possible to mount secret backends at any location, please
update your API calls accordingly.
## Configure Access
This endpoint configures the access information for Consul. This access
information is used so that Vault can communicate with Consul and generate
Consul tokens.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `POST` | `/consul/config/access` | `204 (empty body)` |
### Parameters
- `address` `(string: <required>)`  Specifies the address of the Consul
instance, provided as `"host:port"` like `"127.0.0.1:8500"`.
- `scheme` `(string: "http")`  Specifies the URL scheme to use.
- `token` `(string: <required>)` Specifies the Consul ACL token to use. This
must be a management type token.
### Sample Payload
```json
{
"address": "127.0.0.1:8500",
"scheme": "https",
"token": "adha..."
}
```
### Sample Request
```
$ curl \
--request POST \
--header "X-Vault-Token: ..." \
--data @payload.json \
https://vault.rocks/v1/consul/config/access
```
## Create/Update Role
This endpoint creates or updates the Consul role definition. If the role does
not exist, it will be created. If the role already exists, it will receive
updated attributes.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `POST` | `/consul/roles/:name` | `204 (empty body)` |
### Parameters
- `name` `(string: <required>)`  Specifies the name of an existing role against
which to create this Consul credential. This is part of the request URL.
- `lease` `(string: "")`  Specifies the lease for this role. This is provided
as a string duration with a time suffix like `"30s"` or `"1h"`. If not
provided, the default Vault lease is used.
- `policy` `(string: <required>)` Specifies the base64 encoded ACL policy. The
ACL format can be found in the [Consul ACL
documentation](https://www.consul.io/docs/internals/acl.html). This is
required unless the `token_type` is `management`.
- `token_type` `(string: "client")` - Specifies the type of token to create when
using this role. Valid values are `"client"` or `"management"`.
### Sample Payload
To create management tokens:
```json
{
"token_type": "management"
}
```
To create a client token with a custom policy:
```json
{
"policy": "abd2...=="
}
```
### Sample Request
```
$ curl \
--request POST \
--header "X-Vault-Token: ..." \
--data @payload.json \
https://vault.rocks/v1/consul/roles/example-role
```
## Read Role
This endpoint queries for information about a Consul role with the given name.
If no role exists with that name, a 404 is returned.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `GET` | `/consul/roles/:name` | `200 application/json` |
### Parameters
- `name` `(string: <required>)`  Specifies the name of the role to query. This
is part of the request URL.
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
https://vault.rocks/v1/consul/roles/example-role
```
### Sample Response
```json
{
"data": {
"policy": "abd2...==",
"lease": "1h0m0s",
"token_type": "client"
}
}
```
## Delete Role
This endpoint deletes a Consul role with the given name. Even if the role does
not exist, this endpoint will still return a successful response.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `DELETE` | `/consul/roles/:name` | `204 (empty body)` |
### Parameters
- `name` `(string: <required>)`  Specifies the name of the role to delete. This
is part of the request URL.
### Sample Request
```
$ curl \
--request DELETE \
--header "X-Vault-Token: ..." \
https://vault.rocks/v1/consul/roles/example-role
```
## Generate Credential
This endpoint generates a dynamic Consul token based on the given role
definition.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `GET` | `/consul/creds/:name` | `200 application/json` |
### Parameters
- `name` `(string: <required>)`  Specifies the name of an existing role against
which to create this Consul credential. This is part of the request URL.
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
https://vault.rocks/v1/consul/creds/example-role
```
### Sample Response
```json
{
"data": {
"token": "973a31ea-1ec4-c2de-0f63-623f477c2510"
}
}
```

View file

@ -0,0 +1,155 @@
---
layout: "http"
page_title: "Cubbyhole Secret Backend - HTTP API"
sidebar_current: "docs-http-secret-cubbyhole"
description: |-
This is the API documentation for the Vault Cubbyhole secret backend.
---
# Cubbyhole Secret Backend HTTP API
This is the API documentation for the Vault Cubbyhole secret backend. For
general information about the usage and operation of the Cubbyhole backend,
please see the
[Vault Cubbyhole backend documentation](/docs/secrets/cubbyhole/index.html).
This documentation assumes the Cubbyhole backend is mounted at the `/cubbyhole`
path in Vault. Since it is possible to mount secret backends at any location,
please update your API calls accordingly.
## Read Secret
This endpoint retrieves the secret at the specified location.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `GET` | `/cubbyhole/:path` | `200 application/json` |
### Parameters
- `path` `(string: <required>)` Specifies the path of the secret to read.
This is specified as part of the URL.
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
https://vault.rocks/v1/cubbyhole/my-secret
```
### Sample Response
```json
{
"auth": null,
"data": {
"foo": "bar"
},
"lease_duration": 0,
"lease_id": "",
"renewable": false
}
```
## List Secrets
This endpoint returns a list of secret entries at the specified location.
Folders are suffixed with `/`. The input must be a folder; list on a file will
not return a value. The values themselves are not accessible via this command.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `List` | `/cubbyhole/:path` | `200 application/json` |
### Parameters
- `path` `(string: <required>)` Specifies the path of the secrets to list.
This is specified as part of the URL.
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request LIST \
https://vault.rocks/v1/cubbyhole/my-secret
```
### Sample Response
The example below shows output for a query path of `cubbyhole/` when there are
secrets at `cubbyhole/foo` and `cubbyhole/foo/bar`; note the difference in the
two entries.
```json
{
"auth": null,
"data": {
"keys": ["foo", "foo/"]
},
"lease_duration": 2764800,
"lease_id": "",
"renewable": false
}
```
## Create/Update Secret
This endpoint stores a secret at the specified location.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `POST` | `/cubbyhole/:path` | `204 (empty body)` |
| `PUT` | `/cubbyhole/:path` | `204 (empty body)` |
### Parameters
- `path` `(string: <required>)` Specifies the path of the secrets to
create/update. This is specified as part of the URL.
- `:key` `(string: "")`  Specifies a key, paired with an associated value, to
be held at the given location. Multiple key/value pairs can be specified, and
all will be returned on a read operation. A key called `ttl` will trigger some
special behavior; see above for details.
### Sample Payload
```json
{
"foo": "bar",
"zip": "zap"
}
```
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request POST \
--data @payload.json \
https://vault.rocks/v1/cubbyhole/my-secret
```
## Delete Secret
This endpoint deletes the secret at the specified location.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `DELETE` | `/cubbyhole/:path` | `204 (empty body)` |
### Parameters
- `path` `(string: <required>)` Specifies the path of the secret to delete.
This is specified as part of the URL.
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request DELETE \
https://vault.rocks/v1/cubbyhole/my-secret
```

View file

@ -0,0 +1,159 @@
---
layout: "http"
page_title: "Generic Secret Backend - HTTP API"
sidebar_current: "docs-http-secret-generic"
description: |-
This is the API documentation for the Vault Generic secret backend.
---
# Generic Secret Backend HTTP API
This is the API documentation for the Vault Generic secret backend. For general
information about the usage and operation of the Generic backend, please see
the [Vault Generic backend documentation](/docs/secrets/generic/index.html).
This documentation assumes the Generic backend is mounted at the `/secret`
path in Vault. Since it is possible to mount secret backends at any location,
please update your API calls accordingly.
## Read Secret
This endpoint retrieves the secret at the specified location.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `GET` | `/secret/:path` | `200 application/json` |
### Parameters
- `path` `(string: <required>)` Specifies the path of the secret to read.
This is specified as part of the URL.
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
https://vault.rocks/v1/secret/my-secret
```
### Sample Response
```json
{
"auth": null,
"data": {
"foo": "bar"
},
"lease_duration": 2764800,
"lease_id": "",
"renewable": false
}
```
## List Secrets
This endpoint returns a list of key names at the specified location. Folders are
suffixed with `/`. The input must be a folder; list on a file will not return a
value. Note that no policy-based filtering is performed on keys; do not encode
sensitive information in key names. The values themselves are not accessible via
this command.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `LIST` | `/secret/:path` | `200 application/json` |
### Parameters
- `path` `(string: <required>)` Specifies the path of the secrets to list.
This is specified as part of the URL.
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request LIST \
https://vault.rocks/v1/secret/my-secret
```
### Sample Response
The example below shows output for a query path of `secret/` when there are
secrets at `secret/foo` and `secret/foo/bar`; note the difference in the two
entries.
```json
{
"auth": null,
"data": {
"keys": ["foo", "foo/"]
},
"lease_duration": 2764800,
"lease_id": "",
"renewable": false
}
```
## Create/Update Secret
This endpoint stores a secret at the specified location. If the value does not
yet exist, the calling token must have an ACL policy granting the `create`
capability. If the value already exists, the calling token must have an ACL
policy granting the `update` capability.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `POST` | `/secret/:path` | `204 (empty body)` |
| `PUT` | `/secret/:path` | `204 (empty body)` |
### Parameters
- `path` `(string: <required>)` Specifies the path of the secrets to
create/update. This is specified as part of the URL.
- `:key` `(string: "")`  Specifies a key, paired with an associated value, to
be held at the given location. Multiple key/value pairs can be specified, and
all will be returned on a read operation. A key called `ttl` will trigger some
special behavior; see above for details.
### Sample Payload
```json
{
"foo": "bar",
"zip": "zap"
}
```
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request POST \
--data @payload.json \
https://vault.rocks/v1/secret/my-secret
```
## Delete Secret
This endpoint deletes the secret at the specified location.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `DELETE` | `/secret/:path` | `204 (empty body)` |
### Parameters
- `path` `(string: <required>)` Specifies the path of the secret to delete.
This is specified as part of the URL.
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request DELETE \
https://vault.rocks/v1/secret/my-secret
```

View file

@ -0,0 +1,19 @@
---
layout: "http"
page_title: "HTTP API"
sidebar_current: "docs-http-secret"
description: |-
Each secret backend publishes its own set of API paths and methods. These
endpoints are documented in this section.
---
# Secret Backends
Each secret backend publishes its own set of API paths and methods. These
endpoints are documented in this section. Secret backends are mounted at a path,
but the documentation will assume the default mount points for simplicity. If
you are mounting at a different path, you should adjust your API calls
accordingly.
For the API documentation for a specific secret backend, please choose a secret
backend from the navigation.

View file

@ -0,0 +1,344 @@
---
layout: "http"
page_title: "MongoDB Secret Backend - HTTP API"
sidebar_current: "docs-http-secret-mongodb"
description: |-
This is the API documentation for the Vault MongoDB secret backend.
---
# MongoDB Secret Backend HTTP API
This is the API documentation for the Vault MongoDB secret backend. For general
information about the usage and operation of the MongoDB backend, please see
the [Vault MongoDB backend documentation](/docs/secrets/mongodb/index.html).
This documentation assumes the MongoDB backend is mounted at the `/mongodb`
path in Vault. Since it is possible to mount secret backends at any location,
please update your API calls accordingly.
## Configure Connection
This endpoint configures the standard connection string (URI) used to
communicate with MongoDB.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `POST` | `/mongodb/config/connection` | `200 application/json` |
### Parameters
- `url` `(string: <required>)` Specifies the MongoDB standard connection
string (URI).
- `verify_connection` `(bool: true)`  Specifies if the connection is verified
during initial configuration.
### Sample Payload
```json
{
"url": "mongodb://db1.example.net,db2.example.net:2500/?replicaSet=test"
}
```
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request POST \
--data @payload.json \
https://vault.rocks/v1/mongodb/config/connection
```
### Sample Response
```json
{
"lease_id": "",
"renewable": false,
"lease_duration": 0,
"data": null,
"wrap_info": null,
"warnings": [
"Read access to this endpoint should be controlled via ACLs as it will return the connection URI as it is, including passwords, if any."
],
"auth": null
}
```
## Read Connection
This endpoint queries the connection configuration. Access to this endpoint
should be controlled via ACLs as it will return the connection URI as it is,
including passwords, if any.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `GET` | `/mongodb/config/connection` | `200 application/json` |
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
https://vault.rocks/v1/mongodb/config/connection
```
### Sample Response
```json
{
"lease_id": "",
"renewable": false,
"lease_duration": 0,
"data": {
"uri": "mongodb://admin:Password!@mongodb.acme.com:27017/admin?ssl=true"
},
"wrap_info": null,
"warnings": null,
"auth": null
}
```
## Configure Lease
This endpoint configures the default lease TTL settings for credentials
generated by the mongodb backend.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `POST` | `/mongodb/config/lease` | `204 (empty body)` |
### Parameters
- `lease` `(string: <required>)`  Specifies the lease value provided as a
string duration with time suffix. "h" (hour) is the largest suffix.
- `lease_max` `(string: <required>)`  Specifies the maximum lease value
provided as a string duration with time suffix. "h" (hour) is the largest
suffix.
### Sample Payload
```json
{
"lease": "12h",
"lease_max": "24h"
}
```
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request POST \
--data @payload.json \
https://vault.rocks/v1/mongodb/config/lease
```
## Read Lease
This endpoint queries the lease configuration.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `GET` | `/mongodb/config/lease` | `200 application/json` |
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
https://vault.rocks/v1/mongodb/config/lease
```
### Sample Response
```json
{
"lease_id": "",
"renewable": false,
"lease_duration": 0,
"data": {
"max_ttl": 60,
"ttl": 60
},
"wrap_info": null,
"warnings": null,
"auth": null
}
```
## Create Role
This endpoint creates or updates a role definition.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `POST` | `/mongodb/roles/:name` | `204 (empty body)` |
### Parameters
- `db` `(string: <required>)` Specifies the name of the database users should
be created in for this role.
- `roles` `(string: "")`  Specifies the MongoDB roles to assign to the users
generated for this role.
### Sample Payload
```json
{
"db": "my-db",
"roles": "[\"readWrite\",{\"db\":\"bar\",\"role\":\"read\"}]"
}
```
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request POST \
--data @payload.json \
https://vault.rocks/v1/mongodb/roles/my-role
```
## Read Role
This endpoint queries the role definition.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `GET` | `/mongodb/roles/:name` | `200 application/json` |
### Parameters
- `name` `(string: <required>)` Specifies the name of the role to read. This
is specified as part of the URL.
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
https://vault.rocks/v1/mongodb/roles/my-role
```
### Sample Response
```json
{
"lease_id": "",
"renewable": false,
"lease_duration": 0,
"data": {
"db": "foo",
"roles": "[\"readWrite\",{\"db\":\"bar\",\"role\":\"read\"}]"
},
"wrap_info": null,
"warnings": null,
"auth": null
}
```
## List Roles
This endpoint returns a list of available roles. Only the role names are
returned, not any values.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `LIST` | `/mongodb/roles` | `200 application/json` |
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request LIST \
https://vault.rocks/v1/mongodb/roles
```
### Sample Response
```json
{
"lease_id": "",
"renewable": false,
"lease_duration": 0,
"data": {
"keys": [
"dev",
"prod"
]
},
"wrap_info": null,
"warnings": null,
"auth": null
}
```
## Delete Role
This endpoint deletes the role definition.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `DELETE` | `/mongodb/roles/:name` | `204 (empty body)` |
### Parameters
- `name` `(string: <required>)` Specifies the name of the role to delete. This
is specified as part of the URL.
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request DELETE \
https://vault.rocks/v1/mongodb/roles/my-role
```
## Generate Credentials
This endpoint generates a new set of dynamic credentials based on the named
role.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `GET` | `/mongodb/creds/:name` | `200 application/json` |
### Parameters
- `name` `(string: <required>)` Specifies the name of the role to create
credentials against. This is specified as part of the URL.
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
https://vault.rocks/v1/mongodb/creds/my-role
```
### Sample Response
```json
{
"lease_id": "mongodb/creds/readonly/e64e79d8-9f56-e379-a7c5-373f9b4ee3d8",
"renewable": true,
"lease_duration": 3600,
"data": {
"db": "foo",
"password": "de0f7b50-d700-54e5-4e81-5c3724283999",
"username": "vault-token-b32098cb-7ff2-dcf5-83cd-d5887cedf81b"
},
"wrap_info": null,
"warnings": null,
"auth": null
}
```

View file

@ -0,0 +1,244 @@
---
layout: "http"
page_title: "MSSQL Secret Backend - HTTP API"
sidebar_current: "docs-http-secret-mssql"
description: |-
This is the API documentation for the Vault MSSQL secret backend.
---
# MSSQL Secret Backend HTTP API
This is the API documentation for the Vault MSSQL secret backend. For general
information about the usage and operation of the MSSQL backend, please see
the [Vault MSSQL backend documentation](/docs/secrets/mssql/index.html).
This documentation assumes the MSSQL backend is mounted at the `/mssql`
path in Vault. Since it is possible to mount secret backends at any location,
please update your API calls accordingly.
## Configure Connection
This endpoint configures the connection DSN used to communicate with Microsoft
SQL Server.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `POST` | `/mssql/config/connection` | `204 (empty body)` |
### Parameters
- `connection_string` `(string: <required>)`  Specifies the MSSQL DSN.
- `max_open_connections` `(int: 2)`  Specifies the maximum number of open
connections to the database.
- `max_idle_connections` `(int: 0)`  Specifies the maximum number of idle
connections to the database. A zero uses the value of `max_open_connections`
and a negative value disables idle connections. If larger than
`max_open_connections` it will be reduced to be equal.
### Sample Payload
```json
{
"connection_string": "Server=myServerAddress;Database=myDataBase;User Id=myUsername; Password=myPassword;"
}
```
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request POST \
--data @payload.json \
https://vault.rocks/v1/mssql/config/connection
```
## Configure Lease
This endpoint configures the lease settings for generated credentials.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `POST` | `/mysql/config/lease` | `204 (empty body)` |
### Parameters
- `lease` `(string: <required>)`  Specifies the lease value provided as a
string duration with time suffix. "h" (hour) is the largest suffix.
- `lease_max` `(string: <required>)`  Specifies the maximum lease value
provided as a string duration with time suffix. "h" (hour) is the largest
suffix.
### Sample Payload
```json
{
"lease": "12h",
"lease_max": "24h"
}
```
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request POST \
--data @payload.json \
https://vault.rocks/v1/mssql/config/lease
```
## Create Role
This endpoint creates or updates the role definition.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `POST` | `/mssql/roles/:name` | `204 (empty body)` |
### Parameters
- `sql` `(string: <required>)`  Specifies the SQL statements executed to create
and configure the role. The '{{name}}' and '{{password}}' values will be
substituted. Must be a semicolon-separated string, a base64-encoded
semicolon-separated string, a serialized JSON string array, or a
base64-encoded serialized JSON string array.
### Sample Payload
```json
{
"sql": "CREATE LOGIN ..."
}
```
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request POST \
--data @payload.json \
https://vault.rocks/v1/mssql/roles/my-role
```
## Read Role
This endpoint queries the role definition.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `GET` | `/mssql/roles/:name` | `200 application/json` |
### Parameters
- `name` `(string: <required>)` Specifies the name of the role to read. This
is specified as part of the URL.
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
https://vault.rocks/v1/mssql/roles/my-role
```
### Sample Response
```json
{
"data": {
"sql": "CREATE LOGIN..."
}
}
```
## List Roles
This endpoint returns a list of available roles. Only the role names are
returned, not any values.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `LIST` | `/mssql/roles` | `200 application/json` |
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request LIST \
https://vault.rocks/v1/mssql/roles
```
### Sample Response
```json
{
"auth": null,
"data": {
"keys": ["dev", "prod"]
},
"lease_duration": 2764800,
"lease_id": "",
"renewable": false
}
```
## Delete Role
This endpoint deletes the role definition.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `DELETE` | `/mssql/roles/:name` | `204 (empty body)` |
### Parameters
- `name` `(string: <required>)` Specifies the name of the role to delete. This
is specified as part of the URL.
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request DELETE \
https://vault.rocks/v1/mssql/roles/my-role
```
## Generate Credentials
This endpoint generates a new set of dynamic credentials based on the named
role.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `GET` | `/mssql/creds/:name` | `200 application/json` |
### Parameters
- `name` `(string: <required>)` Specifies the name of the role to create
credentials against. This is specified as part of the URL.
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
https://vault.rocks/v1/mssql/creds/my-role
```
### Sample Response
```json
{
"data": {
"username": "root-a147d529-e7d6-4a16-8930-4c3e72170b19",
"password": "ee202d0d-e4fd-4410-8d14-2a78c5c8cb76"
}
}
```

View file

@ -0,0 +1,265 @@
---
layout: "http"
page_title: "MySQL Secret Backend - HTTP API"
sidebar_current: "docs-http-secret-mysql"
description: |-
This is the API documentation for the Vault MySQL secret backend.
---
# MySQL Secret Backend HTTP API
This is the API documentation for the Vault MySQL secret backend. For general
information about the usage and operation of the MySQL backend, please see
the [Vault MySQL backend documentation](/docs/secrets/mysql/index.html).
This documentation assumes the MySQL backend is mounted at the `/mysql`
path in Vault. Since it is possible to mount secret backends at any location,
please update your API calls accordingly.
## Configure Connection
This endpoint configures the connection DSN used to communicate with MySQL.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `POST` | `/mysql/config/connection` | `204 (empty body)` |
### Parameters
- `connection_url` `(string: <required>)`  Specifies the MySQL DSN.
- `max_open_connections` `(int: 2)`  Specifies the maximum number of open
connections to the database.
- `max_idle_connections` `(int: 0)`  Specifies the maximum number of idle
connections to the database. A zero uses the value of `max_open_connections`
and a negative value disables idle connections. If larger than
`max_open_connections` it will be reduced to be equal.
- `verify_connection` `(bool: true)`  Specifies if the connection is verified
during initial configuration.
### Sample Payload
```json
{
"connection_url": "mysql:host=localhost;dbname=testdb"
}
```
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request POST \
--data @payload.json \
https://vault.rocks/v1/mysql/config/connection
```
## Configure Lease
This endpoint configures the lease settings for generated credentials. If not
configured, leases default to 1 hour. This is a root protected endpoint.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `POST` | `/mysql/config/lease` | `204 (empty body)` |
### Parameters
- `lease` `(string: <required>)`  Specifies the lease value provided as a
string duration with time suffix. "h" (hour) is the largest suffix.
- `lease_max` `(string: <required>)`  Specifies the maximum lease value
provided as a string duration with time suffix. "h" (hour) is the largest
suffix.
### Sample Payload
```json
{
"lease": "12h",
"lease_max": "24h"
}
```
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request POST \
--data @payload.json \
https://vault.rocks/v1/mysql/config/lease
```
## Create Role
This endpoint creates or updates the role definition.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `POST` | `/mysql/roles/:name` | `204 (empty body)` |
### Parameters
- `sql` `(string: <required>)`  Specifies the SQL statements executed to create
and configure a user. Must be a semicolon-separated string, a base64-encoded
semicolon-separated string, a serialized JSON string array, or a
base64-encoded serialized JSON string array. The '{{name}}' and
'{{password}}' values will be substituted.
- `revocation_sql` `(string: "")` Specifies the SQL statements executed to
revoke a user. Must be a semicolon-separated string, a base64-encoded
semicolon-separated string, a serialized JSON string array, or a
base64-encoded serialized JSON string array. The '{{name}}' value will be
substituted.
- `rolename_length` `(int: 4)`  Specifies how many characters from the role
name will be used to form the mysql username interpolated into the '{{name}}'
field of the sql parameter.
- `displayname_length` `(int: 4)`  Specifies how many characters from the token
display name will be used to form the mysql username interpolated into the
'{{name}}' field of the sql parameter.
- `username_length` `(int: 16)`  Specifies the maximum total length in
characters of the mysql username interpolated into the '{{name}}' field of the
sql parameter.
### Sample Payload
```json
{
"sql": "CREATE USER ..."
}
```
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request POST \
--data @payload.json \
https://vault.rocks/v1/mysql/roles/my-role
```
## Read Role
This endpoint queries the role definition.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `GET` | `/mysql/roles/:name` | `200 application/json` |
### Parameters
- `name` `(string: <required>)` Specifies the name of the role to read. This
is specified as part of the URL.
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
https://vault.rocks/v1/mysql/roles/my-role
```
### Sample Response
```json
{
"data": {
"sql": "CREATE USER..."
}
}
```
## List Roles
This endpoint returns a list of available roles. Only the role names are
returned, not any values.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `LIST` | `/mysql/roles` | `200 application/json` |
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request LIST \
https://vault.rocks/v1/mysql/roles
```
### Sample Response
```json
{
"auth": null,
"data": {
"keys": ["dev", "prod"]
},
"lease_duration": 2764800,
"lease_id": "",
"renewable": false
}
```
## Delete Role
This endpoint deletes the role definition.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `DELETE` | `/mysql/roles/:name` | `204 (empty body)` |
### Parameters
- `name` `(string: <required>)` Specifies the name of the role to delete. This
is specified as part of the URL.
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request DELETE \
https://vault.rocks/v1/mysql/roles/my-role
```
## Generate Credentials
This endpoint generates a new set of dynamic credentials based on the named
role.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `GET` | `/mysql/creds/:name` | `200 application/json` |
### Parameters
- `name` `(string: <required>)` Specifies the name of the role to create
credentials against. This is specified as part of the URL.
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
https://vault.rocks/v1/mysql/creds/my-role
```
### Sample Response
```json
{
"data": {
"username": "user-role-aefa63",
"password": "132ae3ef-5a64-7499-351e-bfe59f3a2a21"
}
}
```

File diff suppressed because it is too large Load diff

View file

@ -0,0 +1,259 @@
---
layout: "http"
page_title: "PostgreSQL Secret Backend - HTTP API"
sidebar_current: "docs-http-secret-postgresql"
description: |-
This is the API documentation for the Vault PostgreSQL secret backend.
---
# PostgreSQL Secret Backend HTTP API
This is the API documentation for the Vault PostgreSQL secret backend. For
general information about the usage and operation of the PostgreSQL backend,
please see the
[Vault PostgreSQL backend documentation](/docs/secrets/postgresql/index.html).
This documentation assumes the PostgreSQL backend is mounted at the
`/postgresql` path in Vault. Since it is possible to mount secret backends at
any location, please update your API calls accordingly.
## Configure Connection
This endpoint configures the connection string used to communicate with
PostgreSQL.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `POST` | `/postgresql/config/connection` | `204 (empty body)` |
### Parameters
- `connection_url` `(string: <required>)`  Specifies the PostgreSQL connection
URL or PG-style string, for example `"user=foo host=bar"`.
- `max_open_connections` `(int: 2)`  Specifies the maximum number of open
connections to the database. A negative value means unlimited.
- `max_idle_connections` `(int: 0)`  Specifies the maximum number of idle
connections to the database. A zero uses the value of `max_open_connections`
and a negative value disables idle connections. If this is larger than
`max_open_connections` it will be reduced to be equal.
- `verify_connection` `(bool: true)`  Specifies if the connection is verified
during initial configuration.
### Sample Payload
```json
{
"connection_url": "postgresql://user:pass@localhost/my-db"
}
```
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request POST \
--data @payload.json \
https://vault.rocks/v1/postgresql/config/connection
```
## Configure Lease
This configures the lease settings for generated credentials. If not configured,
leases default to 1 hour. This is a root protected endpoint.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `POST` | `/postgresql/config/lease` | `204 (empty body)` |
### Parameters
- `lease` `(string: <required>)`  Specifies the lease value provided as a
string duration with time suffix. "h" (hour) is the largest suffix.
- `lease_max` `(string: <required>)`  Specifies the maximum lease value
provided as a string duration with time suffix. "h" (hour) is the largest
suffix.
### Sample Payload
```json
{
"lease": "12h",
"lease_max": "24h"
}
```
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request POST \
--data @payload.json \
https://vault.rocks/v1/postgresql/config/lease
```
## Create Role
This endpoint creates or updates a role definition.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `POST` | `/postgresql/roles/:name` | `204 (empty body)` |
### Parameters
- `name` `(string: <required>)` Specifies the name of the role to create. This
is specified as part of the URL.
- `sql` `(string: <required>)`  Specifies the SQL statements executed to create
and configure the role. Must be a semicolon-separated string, a base64-encoded
semicolon-separated string, a serialized JSON string array, or a
base64-encoded serialized JSON string array. The '{{name}}', '{{password}}'
and '{{expiration}}' values will be substituted.
- `revocation_sql` `(string: "")`  Specifies the SQL statements to be executed
to revoke a user. Must be a semicolon-separated string, a base64-encoded
semicolon-separated string, a serialized JSON string array, or a
base64-encoded serialized JSON string array. The '{{name}}' value will be
substituted.
### Sample Payload
```json
{
"sql": "CREATE USER WITH ROLE {{name}}"
}
```
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request POST \
--data @payload.json \
https://vault.rocks/v1/postgresql/roles/my-role
```
## Read Role
This endpoint queries the role definition.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `GET` | `/postgresql/roles/:name` | `200 application/json` |
### Parameters
- `name` `(string: <required>)` Specifies the name of the role to read. This
is specified as part of the URL.
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
https://vault.rocks/v1/postgresql/roles/my-role
```
### Sample Response
```json
{
"data": {
"sql": "CREATE USER..."
}
}
```
## List Roles
This endpoint returns a list of available roles. Only the role names are
returned, not any values.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `LIST` | `/postgresql/roles` | `200 application/json` |
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request LIST \
https://vault.rocks/v1/postgresql/roles
```
### Sample Response
```json
{
"auth": null,
"data": {
"keys": ["dev", "prod"]
},
"lease_duration": 2764800,
"lease_id": "",
"renewable": false
}
```
## Delete Role
This endpoint deletes the role definition.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `DELETE` | `/postgresql/roles/:name` | `204 (empty body)` |
### Parameters
- `name` `(string: <required>)` Specifies the name of the role to delete. This
is specified as part of the URL.
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request DELETE \
https://vault.rocks/v1/postgresql/roles/my-role
```
## Generate Credentials
This endpoint generates a new set of dynamic credentials based on the named
role.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `GET` | `/postgresql/creds/:name` | `200 application/json` |
### Parameters
- `name` `(string: <required>)` Specifies the name of the role to create
credentials against. This is specified as part of the URL.
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
https://vault.rocks/v1/postgresql/creds/my-role
```
### Sample Response
```json
{
"data": {
"username": "root-1430158508-126",
"password": "132ae3ef-5a64-7499-351e-bfe59f3a2a21"
}
}
```

View file

@ -0,0 +1,218 @@
---
layout: "http"
page_title: "RabbitMQ Secret Backend - HTTP API"
sidebar_current: "docs-http-secret-rabbitmq"
description: |-
This is the API documentation for the Vault RabbitMQ secret backend.
---
# RabbitMQ Secret Backend HTTP API
This is the API documentation for the Vault RabbitMQ secret backend. For general
information about the usage and operation of the RabbitMQ backend, please see
the [Vault RabbitMQ backend documentation](/docs/secrets/rabbitmq/index.html).
This documentation assumes the RabbitMQ backend is mounted at the `/rabbitmq`
path in Vault. Since it is possible to mount secret backends at any location,
please update your API calls accordingly.
## Configure Connection
This endpoint configures the connection string used to communicate with
RabbitMQ.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `POST` | `/rabbitmq/config/connection` | `204 (empty body)` |
### Parameters
- `connection_uri` `(string: <required>)`  Specifies the RabbitMQ connection
URI.
- `username` `(string: <required>)` Specifies the RabbitMQ management
administrator username.
- `password` `(string: <required>)`  Specifies the RabbitMQ management
administrator password.
- `verify_connection` `(bool: true)`  Specifies whether to verify connection
URI, username, and password.
### Sample Payload
```json
{
"connection_uri": "https://...",
"username": "user",
"password": "password"
}
```
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request POST \
--data @payload.json \
https://vault.rocks/v1/rabbitmq/config/connection
```
## Configure Lease
This endpoint configures the lease settings for generated credentials. This is
endpoint requires sudo privileges.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `POST` | `/rabbitmq/config/lease` | `204 (empty body)` |
### Parameters
- `ttl` `(int: 0)`  Specifies the lease ttl provided in seconds.
- `max_ttl` `(int: 0)` Specifies the maximum ttl provided in seconds.
### Sample Payload
```json
{
"ttl": 1800,
"max_ttl": 3600
}
```
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request POST \
--data @payload.json \
https://vault.rocks/v1/rabbitmq/config/lease
```
## Create Role
This endpoint creates or updates the role definition.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `POST` | `/rabbitmq/roles/:name` | `204 (empty body)` |
### Parameters
- `name` `(string: <required>)` Specifies the name of the role to create. This
is specified as part of the URL.
- `tags` `(string: "")`  Specifies a comma-separated RabbitMQ management tags.
- `vhost` `(string: "")`  Specifies a map of virtual hosts to
permissions.
### Sample Payload
```json
{
"tags": "tag1,tag2",
"vhost": "{\"/\": {\"configure\":\".*\", \"write\":\".*\", \"read\": \".*\"}}"
}
```
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request POST \
--data @payload.json \
https://vault.rocks/v1/rabbitmq/roles/my-role
```
## Read Role
This endpoint queries the role definition.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `GET` | `/rabbitmq/roles/:name` | `200 application/json` |
### Parameters
- `name` `(string: <required>)` Specifies the name of the role to read. This
is specified as part of the URL.
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
https://vault.rocks/v1/rabbitmq/roles/my-role
```
### Sample Response
```json
{
"data": {
"tags": "",
"vhost": "{\"/\": {\"configure\":\".*\", \"write\":\".*\", \"read\": \".*\"}}"
}
}
```
## Delete Role
This endpoint deletes the role definition.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `DELETE` | `/rabbitmq/roles/:namer` | `204 (empty body)` |
### Parameters
- `name` `(string: <required>)` Specifies the name of the role to delete. This
is specified as part of the URL.
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request DELETE \
https://vault.rocks/v1/rabbitmq/roles/my-role
```
## Generate Credentials
This endpoint generates a new set of dynamic credentials based on the named
role.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `GET` | `/rabbitmq/creds/:name` | `200 application/json` |
### Parameters
- `name` `(string: <required>)` Specifies the name of the role to create
credentials against. This is specified as part of the URL.
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
https://vault.rocks/v1/rabbitmq/creds/my-role
```
### Sample Response
```json
{
"data": {
"username": "root-4b95bf47-281d-dcb5-8a60-9594f8056092",
"password": "e1b6c159-ca63-4c6a-3886-6639eae06c30"
}
}
```

View file

@ -0,0 +1,749 @@
---
layout: "http"
page_title: "SSH Secret Backend - HTTP API"
sidebar_current: "docs-http-secret-ssh"
description: |-
This is the API documentation for the Vault SSH secret backend.
---
# SSH Secret Backend HTTP API
This is the API documentation for the Vault SSH secret backend. For general
information about the usage and operation of the SSH backend, please see the
[Vault SSH backend documentation](/docs/secrets/ssh/index.html).
This documentation assumes the SSH backend is mounted at the `/ssh` path in
Vault. Since it is possible to mount secret backends at any location, please
update your API calls accordingly.
## Create/Update Key
This endpoint creates or updates a named key.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `POST` | `/ssh/keys/:name` | `204 (empty body)` |
### Parameters
- `name` `(string: <required>)`  Specifies the name of the key to create. This
is part of the request URL.
- `key` `(string: <required>)` Specifies an SSH private key with appropriate
privileges on remote hosts.
### Sample Payload
```json
{
"key": "..."
}
```
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request POST \
--data @payload.json \
https://vault.rocks/v1/ssh/keys/my-key
```
## Delete Key
This endpoint deletes a named key.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `DELETE` | `/ssh/keys/:name` | `204 (empty body)` |
### Parameters
- `name` `(string: <required>)`  Specifies the name of the key to delete. This
is part of the request URL.
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request DELETE \
https://vault.rocks/v1/ssh/keys/my-key
```
## Create Role
This endpoint creates or updates a named role.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `POST` | `/ssh/roles/:name` | `204 (empty body)` |
### Parameters
- `name` `(string: <required>)`  Specifies the name of the role to create. This
is part of the request URL.
- `key` `(string: "")`  Specifies the name of the registered key in Vault.
Before creating the role, use the `keys/` endpoint to create a named key. This
is required for "Dynamic Key" type.
- `admin_user` `(string: "")`  Specifies the admin user at remote host. The
shared key being registered should be for this user and should have root or
sudo privileges. Every time a dynamic credential is generated for a client,
Vault uses this admin username to login to remote host and install the
generated credential. This is required for Dynamic Key type.
- `default_user` `(string: "")`  Specifies the default username for which a
credential will be generated. When the endpoint `creds/` is used without a
username, this value will be used as default username. Its recommended to
create individual roles for each username to ensure absolute isolation between
usernames. This is required for Dynamic Key type and OTP type.
For the CA type, if you wish this to be a valid principal, it must also be
in `allowed_users`.
- `cidr_list` `(string: "")`  Specifies a comma separated list of CIDR blocks
for which the role is applicable for.CIDR blocks can belong to more than one
role.
- `exclude_cidr_list` `(string: "")`  Specifies a comma-separated list of CIDR
blocks. IP addresses belonging to these blocks are not accepted by the role.
This is particularly useful when big CIDR blocks are being used by the role
and certain parts need to be kept out.
- `port` `(int: 22)`  Specifies the port number for SSH connection. Port number
does not play any role in OTP generation. For the `otp` backend type, this is
just a way to inform the client about the port number to use. The port number
will be returned to the client by Vault along with the OTP.
- `key_type` `(string: <required>)`  Specifies the type of credentials
generated by this role. This can be either `otp`, `dynamic` or `ca`.
- `key_bits` `(int: 1024)`  Specifies the length of the RSA dynamic key in
bits. This can be either 1024 or 2048.
- `install_script` `(string: "")`  Specifies the script used to install and
uninstall public keys in the target machine. Defaults to the built-in script.
- `allowed_users` `(string: "")`  If this option is not specified, client can
request for a credential for any valid user at the remote host, including the
admin user. If only certain usernames are to be allowed, then this list
enforces it. If this field is set, then credentials can only be created for
`default_user` and usernames present in this list. Setting this option will
enable all the users with access this role to fetch credentials for all other
usernames in this list. Use with caution.
- `allowed_domains` `(string: "")`  If this option is not specified, client can
request for a signed certificate for any valid host. If only certain domains
are allowed, then this list enforces it. If this option is explicitly set to
`"*"`, then credentials can be created for any domain.
- `key_option_specs` `(string: "")`  Specifies a aomma separated option
specification which will be prefixed to RSA keys in the remote host's
authorized_keys file. N.B.: Vault does not check this string for validity.
- `ttl` `(string: "")`  Specifies the Time To Live value provided as a string
duration with time suffix. Hour is the largest suffix. If not set, uses the
system default value or the value of `max_ttl`, whichever is shorter.
- `max_ttl` `(string: "")`  Specifies the maximum Time To Live provided as a
string duration with time suffix. Hour is the largest suffix. If not set,
defaults to the system maximum lease TTL.
- `allowed_critical_options` `(string: "")`  Specifies a comma-separated list
of critical options that certificates can have when signed. To allow any
critical options, set this to an empty string. Will default to allowing any
critical options.
- `allowed_extensions` `(string: "")` Specifies a comma-separated list of
extensions that certificates can have when signed. To allow any critical
options, set this to an empty string. Will default to allowing any extensions.
- `default_critical_options` `(map<string|string>: "")`  Specifies a map of
critical options certificates should have if none are provided when signing.
This field takes in key value pairs in JSON format. Note that these are not
restricted by `allowed_critical_options`. Defaults to none.
- `default_extensions` `(map<string|string>: "")`  Specifies a map of
extensions certificates should have if none are provided when signing. This
field takes in key value pairs in JSON format. Note that these are not
restricted by `allowed_extensions`. Defaults to none.
- `allow_user_certificates` `(bool: false)`  Specifies if certificates are
allowed to be signed for use as a 'user'.
- `allow_host_certificates` `(bool: false)`  Specifies if certificates are
allowed to be signed for use as a 'host'.
- `allow_bare_domains` `(bool: false)`  Specifies if host certificates that are
requested are allowed to use the base domains listed in "allowed_users", e.g.
"example.com". This is a separate option as in some cases this can be
considered a security threat.
- `allow_subdomains` `(bool: false)` Specifies if host certificates that are
requested are allowed to use subdomains of those listed in "allowed_users".
- `allow_user_key_ids` `(bool: false)` Specifies if users can override the key
ID for a signed certificate with the "key_id" field. When false, the key ID
will always be the token display name. The key ID is logged by the SSH server
and can be useful for auditing.
### Sample Payload
```json
{
"key_type": "otp"
}
```
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request POST \
--data @payload.json \
https://vault.rocks/v1/ssh/roles/my-role
```
## Read Role
This endpoint queries a named role.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `GET` | `/ssh/roles/:name` | `200 application/json` |
### Parameters
- `name` `(string: <required>)`  Specifies the name of the role to read. This
is part of the request URL.
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
https://vault.rocks/v1/ssh/roles/my-role
```
### Sample Response
For a dynamic key role:
```json
{
"admin_user": "username",
"cidr_list": "x.x.x.x/y",
"default_user": "username",
"key": "<key name>",
"key_type": "dynamic",
"port": 22
}
```
For an OTP role:
```json
{
"cidr_list": "x.x.x.x/y",
"default_user": "username",
"key_type": "otp",
"port": 22
}
```
For a CA role:
```json
{
"allow_bare_domains": false,
"allow_host_certificates": true,
"allow_subdomains": false,
"allow_user_key_ids": false,
"allow_user_certificates": true,
"allowed_critical_options": "",
"allowed_extensions": "",
"default_critical_options": {},
"default_extensions": {},
"max_ttl": "768h",
"ttl": "4h"
}
```
## List Roles
This endpoint returns a list of available roles. Only the role names are
returned, not any values.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `LIST` | `/ssh/roles` | `200 application/json` |
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request LIST \
https://vault.rocks/v1/ssh/roles
```
### Sample Response
```json
{
"auth": null,
"data": {
"keys": ["dev", "prod"]
},
"lease_duration": 2764800,
"lease_id": "",
"renewable": false
}
```
## Delete Role
This endpoint deletes a named role.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `DELETE` | `/ssh/roles/:name` | `204 (empty body)` |
### Parameters
- `name` `(string: <required>)`  Specifies the name of the role to delete. This
is part of the request URL.
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request DELETE \
--data @payload.json \
https://vault.rocks/v1/ssh/roles/my-role
```
## List Zero-Address Roles
This endpoint returns the list of configured zero-address roles.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `GET` | `/ssh/config/zeroaddress` | `200 application/json` |
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
https://vault.rocks/v1/ssh/config/zeroaddress
```
### Sample Response
```json
{
"lease_id":"",
"renewable":false,
"lease_duration":0,
"data":{
"roles":[
"otp_key_role"
]
},
"warnings":null,
"auth":null
}
```
## Configure Zero-Address Roles
This endpoint configures zero-address roles.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `POST` | `/ssh/config/zeroaddress` | `204 (empty body)` |
### Parameters
- `roles` `(string: <required>)`  Specifies a string containing comma separated
list of role names which allows credentials to be requested for any IP
address. CIDR blocks previously registered under these roles will be ignored.
### Sample Payload
```json
{
"roles": ["otp_key_role"]
}
```
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request POST \
--data @payload.json \
https://vault.rocks/v1/ssh/config/zeroaddress
```
## Delete Zero-Address Role
This endpoint deletes the zero-address roles configuration.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `DELETE` | `/ssh/config/zeroaddress` | `204 (empty body)` |
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request DELETE \
https://vault.rocks/v1/ssh/config/zeroaddress
```
## Generate SSH Credentials
This endpoint creates credentials for a specific username and IP with the
parameters defined in the given role.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `POST` | `/ssh/creds/:name` | `200 application/json` |
### Parameters
- `name` `(string: <required>)`  Specifies the name of the role to create
credentials against. This is part of the request URL.
- `username` `(string: "")`  Specifies the username on the remote host.
- `ip` `(string: <required>)` Specifies the IP of the remote host.
### Sample Payload
```json
{
"ip": "1.2.3.4"
}
```
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request POST \
--data @payload.json \
https://vault.rocks/v1/ssh/creds/my-role
```
### Sample Response
For a dynamic key role:
```json
{
"lease_id": "",
"renewable": false,
"lease_duration": 0,
"data": {
"admin_user": "rajanadar",
"allowed_users": "",
"cidr_list": "x.x.x.x/y",
"default_user": "rajanadar",
"exclude_cidr_list": "x.x.x.x/y",
"install_script": "pretty_large_script",
"key": "5d9ee6a1-c787-47a9-9738-da243f4f69bf",
"key_bits": 1024,
"key_option_specs": "",
"key_type": "dynamic",
"port": 22
},
"warnings": null,
"auth": null
}
```
For an OTP role:
```json
{
"lease_id": "sshs/creds/c3c2e60c-5a48-415a-9d5a-a41e0e6cdec5/3ee6ad28-383f-d482-2427-70498eba4d96",
"renewable": false,
"lease_duration": 2764800,
"data": {
"ip": "127.0.0.1",
"key": "6d6411fd-f622-ea0a-7e2c-989a745cbbb2",
"key_type": "otp",
"port": 22,
"username": "rajanadar"
},
"warnings": null,
"auth": null
}
```
## List Roles by IP
This endpoint lists all of the roles with which the given IP is associated.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `POST` | `/ssh/lookup` | `200 application/json` |
### Parameters
- `ip` `(string: <required>)`  Specifies the IP of the remote host.
### Sample Payload
```json
{
"ip": "1.2.3.4"
}
```
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request POST \
--data @payload.json \
https://vault.rocks/v1/ssh/lookup
```
### Sample Response
An array of roles as a secret structure.
```json
{
"lease_id": "",
"renewable": false,
"lease_duration": 0,
"data": {
"roles": [
"fe6f61b7-7e4a-46a6-b2c8-0d530b8513df",
"6d6411fd-f622-ea0a-7e2c-989a745cbbb2"
]
},
"warnings": null,
"auth": null
}
```
## Verify SSH OTP
This endpoint verifies if the given OTP is valid. This is an unauthenticated
endpoint.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `POST` | `/ssh/verify` | `200 application/json` |
## Parameters
- `otp` `(string: <required>)`  Specifies the One-Time-Key that needs to be
validated.
### Sample Payload
```json
{
"otp": "bad2b3-..."
}
```
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request POST \
--data @payload.json \
https://vault.rocks/v1/ssh/verify
### Sample Response
```json
{
"lease_id":"",
"renewable":false,
"lease_duration":0,
"data": {
"ip":"127.0.0.1",
"username":"rajanadar"
},
"warnings":null,
"auth":null
}
```
## Submit CA Information
This endpoint allows submitting the CA information for the backend via an SSH
key pair. _If you have already set a certificate and key, they will be
overridden._
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `POST` | `/ssh/config/ca` | `200/204 application/json` |
### Parameters
- `private_key` `(string: "")`  Specifies the private key part the SSH CA key
pair; required if `generate_signing_key` is false.
- `public_key` `(string: "")` Specifies the public key part of the SSH CA key
pair; required if `generate_signing_key` is false.
- `generate_signing_key` `(bool: false)`  Specifies if Vault should generate
the signing key pair internally. The generated public key will be returned so
you can add it to your configuration.
### Sample Payload
```json
{
"generate_signing_key": true
}
```
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request POST \
--data @payload.json \
https://vault.rocks/v1/ssh/config/ca
```
### Sample Response
This will return a `204` response if `generate_signing_key` was unset or false.
This will return a `200` response if `generate_signing_key` was true:
```json
{
"lease_id": "",
"renewable": false,
"lease_duration": 0,
"data": {
"public_key": "ssh-rsa AAAAHHNzaC1y...\n"
},
"warnings": null
}
```
## Read Public Key
This endpoint reads the configured/generated public key.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `GET` | `/ssh/config/ca` | `200 application/json` |
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
https://vault.rocks/v1/ssh/config/ca
```
### Sample Response
```json
{
"lease_id": "",
"renewable": false,
"lease_duration": 0,
"data": {
"public_key": "ssh-rsa AAAAHHNzaC1y...\n"
},
"warnings": null
}
```
## Sigh SSH Key
This endpoint signs an SSH public key based on the supplied parameters, subject
to the restrictions contained in the role named in the endpoint.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `POST` | `/ssh/sign/:name` | `200 application/json` |
### Parameters
- `name` `(string: <required>)`  Specifies the name of the role to sign. This
is part of the request URL.
- `public_key` `(string: <required>)` Specifies the SSH public key that should
be signed.
- `ttl` `(string: "")`  Specifies the Requested Time To Live. Cannot be greater
than the role's `max_ttl` value. If not provided, the role's `ttl` value will
be used. Note that the role values default to system values if not explicitly
set.
- `vauld_principals` `(string: "")`  Specifies valid principals, either
usernames or hostnames, that the certificate should be signed for.
- `cert_type` `(string: "user")`  Specifies the type of certificate to be
created; either "user" or "host".
- `key_id` `(string: "")`  Specifies the key id that the created certificate
should have. If not specified, the display name of the token will be used.
- `critical_options` `(map<string|string>: "")`  Specifies a map of the
critical options that the certificate should be signed for. Defaults to none.
- `extension` `(map<string|string>: "")`  Specifies a map of the extensions
that the certificate should be signed for. Defaults to none.
### Sample Payload
```json
{
"public_key": "ssh-rsa ..."
}
```
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request POST \
--data @payload.json \
https://vault.rocks/v1/ssh/sign/my-key
```
### Sample Response
```json
{
"lease_id": "ssh/sign/example/097bf207-96dd-0041-0e83-b23bd1923993",
"renewable": false,
"lease_duration": 21600,
"data": {
"serial_number": "f65ed2fd21443d5c",
"signed_key": "ssh-rsa-cert-v01@openssh.com AAAAHHNzaC1y...\n"
},
"auth": null
}
```

View file

@ -0,0 +1,859 @@
---
layout: "http"
page_title: "Transit Secret Backend - HTTP API"
sidebar_current: "docs-http-secret-transit"
description: |-
This is the API documentation for the Vault Transit secret backend.
---
# Transit Secret Backend HTTP API
This is the API documentation for the Vault Transit secret backend. For general
information about the usage and operation of the Transit backend, please see the
[Vault Transit backend documentation](/docs/secrets/transit/index.html).
This documentation assumes the Transit backend is mounted at the `/transit`
path in Vault. Since it is possible to mount secret backends at any location,
please update your API calls accordingly.
## Create Key
This endpoint creates a new named encryption key of the specified type. The
values set here cannot be changed after key creation.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `POST` | `/transit/keys/:name` | `204 (empty body)` |
### Parameters
- `name` `(string: <required>)` Specifies the name of the encryption key to
create. This is specified as part of the URL.
- `convergent_encryption` `(bool: false)` If enabled, the key will support
convergent encryption, where the same plaintext creates the same ciphertext.
This requires _derived_ to be set to `true`. When enabled, each
encryption(/decryption/rewrap/datakey) operation will derive a `nonce` value
rather than randomly generate it. Note that while this is useful for
particular situations, all nonce values used with a given context value **must
be unique** or it will compromise the security of your key, and the key space
for nonces is 96 bit -- not as large as the AES key itself.
- `derived` `(bool: false)`  Specifies if key derivation kist be used. If
enabled, all encrypt/decrypt requests to this named key must provide a context
which is used for key derivation.
- `exportable` `(bool: false)`  Specifies if the raw key is exportable.
- `type` `(string: "aes256-gcm96")`  Specifies the type of key to create. The
currently-supported types are:
- `aes256-gcm96` AES-256 wrapped with GCM using a 12-byte nonce size (symmetric)
- `ecdsa-p256` ECDSA using the P-256 elliptic curve (asymmetric)
### Sample Payload
```json
{
"type": "ecdsa-p256",
"derived": true
}
```
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request POST \
--data @payload.json \
https://vault.rocks/v1/transit/keys/my-key
```
## Read Key
This endpoint returns information about a named encryption key. The `keys`
object shows the creation time of each key version; the values are not the keys
themselves. Depending on the type of key, different information may be returned,
e.g. an asymmetric key will return its public key in a standard format for the
type.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `GET` | `/transit/keys/:name` | `200 application/json` |
### Parameters
- `name` `(string: <required>)` Specifies the name of the encryption key to
read. This is specified as part of the URL.
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
https://vault.rocks/v1/transit/keys/my-key
```
### Sample Response
```json
{
"data": {
"type": "aes256-gcm96",
"deletion_allowed": false,
"derived": false,
"exportable": false,
"keys": {
"1": 1442851412
},
"min_decryption_version": 0,
"name": "foo",
"supports_encryption": true,
"supports_decryption": true,
"supports_derivation": true,
"supports_signing": false
}
}
```
## List Keys
This endpoint returns a list of keys. Only the key names are returned (not the
actual keys themselves).
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `LIST` | `/transit/keys` | `200 application/json` |
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request LIST \
https://vault.rocks/v1/transit/keys
```
### Sample Response
```json
{
"data": {
"keys": ["foo", "bar"]
},
"lease_duration": 0,
"lease_id": "",
"renewable": false
}
```
## Delete Key
This endpoint deletes a named encryption key. It will no longer be possible to
decrypt any data encrypted with the named key. Because this is a potentially
catastrophic operation, the `deletion_allowed` tunable must be set in the key's
`/config` endpoint.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `DELETE` | `/transit/keys/:name` | `204 (empty body)` |
### Parameters
- `name` `(string: <required>)` Specifies the name of the encryption key to
delete. This is specified as part of the URL.
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request DELETE \
https://vault.rocks/v1/transit/keys/my-key
```
#### Update Key Configuration
This endpoint allows tuning configuration values for a given key. (These values
are returned during a read operation on the named key.)
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `POST` | `/transit/keys/:name/config` | `204 (empty body)` |
### Parameters
- `min_decryption_version` `(int: 0)`  Specifies the minimum version of
ciphertext allowed to be decrypted. Adjusting this as part of a key rotation
policy can prevent old copies of ciphertext from being decrypted, should they
fall into the wrong hands. For signatures, this value controls the minimum
version of signature that can be verified against. For HMACs, this controls
the minimum version of a key allowed to be used as the key for the HMAC
function.
- `deletion_allowed` `(bool: false)`- Specifies if the key is allowed to be
deleted.
### Sample Payload
```json
{
"deletion_allowed": true
}
```
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request POST \
--data @payload.json \
https://vault.rocks/v1/transit/keys/my-key/config
```
## Rotate Key
This endpoint rotates the version of the named key. After rotation, new
plaintext requests will be encrypted with the new version of the key. To upgrade
ciphertext to be encrypted with the latest version of the key, use the `rewrap`
endpoint. This is only supported with keys that support encryption and
decryption operations.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `POST` | `/transit/keys/:name/rotate` | `204 (empty body)` |
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request POST \
https://vault.rocks/v1/transit/keys/my-key/rotate
```
## Read Key
This endpoint returns the named key. The `keys` object shows the value of the
key for each version. If `version` is specified, the specific version will be
returned. If `latest` is provided as the version, the current key will be
provided. Depending on the type of key, different information may be returned.
The key must be exportable to support this operation and the version must still
be valid.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `GET` | `/transit/export/:key_type/:name(/:version)` | `200 application/json` |
### Parameters
- `key_type` `(string: <required>)`  Specifies the type of the key to export.
This is specified as part of the URL. Valid values are:
- `encryption-key`
- `signing-key`
- `hmac-key`
- `name` `(string: <required>)` Specifies the name of the key to read
information about. This is specified as part of the URL.
- `version` `(int: "")`  Specifies the version of the key to read. If omitted,
all versions of the key will be returned. This is specified as part of the
URL.
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
https://vault.rocks/v1/transit/export/encryption-key/my-key/1
```
### Sample Response
```json
{
"data": {
"name": "foo",
"keys": {
"1": "eyXYGHbTmugUJn6EtYD/yVEoF6pCxm4R/cMEutUm3MY=",
"2": "Euzymqx6iXjS3/NuGKDCiM2Ev6wdhnU+rBiKnJ7YpHE="
}
}
}
```
## Encrypt Data
This endpoint encrypts the provided plaintext using the named key. Currently,
this only supports symmetric keys. This path supports the `create` and `update`
policy capabilities as follows: if the user has the `create` capability for this
endpoint in their policies, and the key does not exist, it will be upserted with
default values (whether the key requires derivation depends on whether the
context parameter is empty or not). If the user only has `update` capability and
the key does not exist, an error will be returned.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `POST` | `/transit/encrypt/:name` | `200 application/json` |
### Parameters
- `name` `(string: <required>)` Specifies the name of the encryption key to
encrypt against. This is specified as part of the URL.
- `plaintext` `(string: <required>)` Specifies **base64 encoded** plaintext to
be encoded.
- `context` `(string: "")`  Specifies the **base64 encoded** context for key
derivation. This is required if key derivation is enabled for this key.
- `nonce` `(string: "")` Specifies the **base64 encoded** nonce value. This
must be provided if convergent encryption is enabled for this key and the key
was generated with Vault 0.6.1. Not required for keys created in 0.6.2+. The
value must be exactly 96 bits (12 bytes) long and the user must ensure that
for any given context (and thus, any given encryption key) this nonce value is
**never reused**.
- `batch_input` `(array<object>: nil)`  Specifies a list of items to be
encrypted in a single batch. When this parameter is set, if the parameters
'plaintext', 'context' and 'nonce' are also set, they will be ignored. The
format for the input is:
```json
[
{
"context": "c2FtcGxlY29udGV4dA==",
"plaintext": "dGhlIHF1aWNrIGJyb3duIGZveA=="
},
{
"context": "YW5vdGhlcnNhbXBsZWNvbnRleHQ=",
"plaintext": "dGhlIHF1aWNrIGJyb3duIGZveA=="
},
]
```
- `type` `(string: "aes256-gcm96")` This parameter is required when encryption
key is expected to be created. When performing an upsert operation, the type
of key to create. Currently, "aes256-gcm96" (symmetric) is the only type
supported.
- `convergent_encryption` `(string: "")`  This parameter will only be used when
a key is expected to be created. Whether to support convergent encryption.
This is only supported when using a key with key derivation enabled and will
require all requests to carry both a context and 96-bit (12-byte) nonce. The
given nonce will be used in place of a randomly generated nonce. As a result,
when the same context and nonce are supplied, the same ciphertext is
generated. It is _very important_ when using this mode that you ensure that
all nonces are unique for a given context. Failing to do so will severely
impact the ciphertext's security.
### Sample Payload
```json
{
"plaintext": "dGhlIHF1aWNrIGJyb3duIGZveA=="
}
```
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request POST \
--data @payload.json \
https://vault.rocks/v1/transit/encrypt/my-key
```
### Sample Response
```json
{
"data": {
"ciphertext": "vault:v1:abcdefgh"
}
}
```
## Decrypt Data
This endpoint decrypts the provided ciphertext using the named key. Currently,
this only supports symmetric keys.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `POST` | `/transit/decrypt/:name` | `200 application/json` |
### Parameters
- `name` `(string: <required>)` Specifies the name of the encryption key to
decrypt against. This is specified as part of the URL.
- `ciphertext` `(string: <required>)`  Specifies the ciphertext to decrypt.
- `context` `(string: "")` Specifies the **base64 encoded** context for key
derivation. This is required if key derivation is enabled.
- `nonce` `(string: "")`  Specifies a base64 encoded nonce value used during
encryption. Must be provided if convergent encryption is enabled for this key
and the key was generated with Vault 0.6.1. Not required for keys created in
0.6.2+.
- `batch_input` `(array<object>: nil)`  Specifies a list of items to be
decrypted in a single batch. When this parameter is set, if the parameters
'ciphertext', 'context' and 'nonce' are also set, they will be ignored. Format
for the input goes like this:
```json
[
{
"context": "c2FtcGxlY29udGV4dA==",
"ciphertext": "vault:v1:/DupSiSbX/ATkGmKAmhqD0tvukByrx6gmps7dVI="
},
{
"context": "YW5vdGhlcnNhbXBsZWNvbnRleHQ=",
"ciphertext": "vault:v1:XjsPWPjqPrBi1N2Ms2s1QM798YyFWnO4TR4lsFA="
},
]
```
### Sample Payload
```json
{
"ciphertext": "vault:v1:XjsPWPjqPrBi1N2Ms2s1QM798YyFWnO4TR4lsFA="
}
```
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request POST \
--data @payload.json \
https://vault.rocks/v1/transit/decrypt/my-key
```
### Sample Response
```json
{
"data": {
"plaintext": "dGhlIHF1aWNrIGJyb3duIGZveAo="
}
}
```
## Rewrap Data
This endpoint rewrapw the provided ciphertext using the latest version of the
named key. Because this never returns plaintext, it is possible to delegate this
functionality to untrusted users or scripts.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `POST` | `/transit/rewrap/:name` | `200 application/json` |
### Parameters
- `name` `(string: <required>)` Specifies the name of the encryption key to
re-encrypt against. This is specified as part of the URL.
- `ciphertext` `(string: <required>)`  Specifies the ciphertext to re-encrypt.
- `context` `(string: "")` Specifies the **base64 encoded** context for key
derivation. This is required if key derivation is enabled.
- `nonce` `(string: "")`  Specifies a base64 encoded nonce value used during
encryption. Must be provided if convergent encryption is enabled for this key
and the key was generated with Vault 0.6.1. Not required for keys created in
0.6.2+.
- `batch_input` `(array<object>: nil)`  Specifies a list of items to be
decrypted in a single batch. When this parameter is set, if the parameters
'ciphertext', 'context' and 'nonce' are also set, they will be ignored. Format
for the input goes like this:
```json
[
{
"context": "c2FtcGxlY29udGV4dA==",
"ciphertext": "vault:v1:/DupSiSbX/ATkGmKAmhqD0tvukByrx6gmps7dVI="
},
{
"context": "YW5vdGhlcnNhbXBsZWNvbnRleHQ=",
"ciphertext": "vault:v1:XjsPWPjqPrBi1N2Ms2s1QM798YyFWnO4TR4lsFA="
},
]
```
### Sample Payload
```json
{
"ciphertext": "vault:v1:XjsPWPjqPrBi1N2Ms2s1QM798YyFWnO4TR4lsFA="
}
```
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request POST \
--data @payload.json \
https://vault.rocks/v1/transit/rewrap/my-key
```
### Sample Response
```json
{
"data": {
"ciphertext": "vault:v2:abcdefgh"
}
}
```
## Generate Data Key
This endpoint generates a new high-entropy key and the value encrypted with the
named key. Optionally return the plaintext of the key as well. Whether plaintext
is returned depends on the path; as a result, you can use Vault ACL policies to
control whether a user is allowed to retrieve the plaintext value of a key. This
is useful if you want an untrusted user or operation to generate keys that are
then made available to trusted users.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `POST` | `/transit/datakey/:type/:name` | `200 application/json` |
### Parameters
- `type` `(string: <required>)`  Specifies the type of key to generate. If
`plaintext`, the plaintext key will be returned along with the ciphertext. If
`wrapped`, only the ciphertext value will be returned. This is specified as
part of the URL.
- `name` `(string: <required>)` Specifies the name of the encryption key to
re-encrypt against. This is specified as part of the URL.
- `context` `(string: "")`  Specifies the key derivation context, provided as a
base64-encoded string. This must be provided if derivation is enabled.
- `nonce` `(string: "")`  Specifies a nonce value, provided as base64 encoded.
Must be provided if convergent encryption is enabled for this key and the key
was generated with Vault 0.6.1. Not required for keys created in 0.6.2+. The
value must be exactly 96 bits (12 bytes) long and the user must ensure that
for any given context (and thus, any given encryption key) this nonce value is
**never reused**.
- `bits` `(int: 256)`  Specifies the number of bits in the desired key. Can be
128, 256, or 512.
### Sample Payload
```json
{
"context": "Ab3=="
}
```
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request POST \
--data @payload.json \
https://vault.rocks/v1/transit/datakey/plaintext/my-key
```
### Sample Response
```json
{
"data": {
"plaintext": "dGhlIHF1aWNrIGJyb3duIGZveAo=",
"ciphertext": "vault:v1:abcdefgh"
}
}
```
## Generate Random Bytes
This endpoint returns high-quality random bytes of the specified length.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `POST` | `/transit/random(/:bytes)` | `200 application/json` |
### Parameters
- `bytes` `(int: 32)`  Specifies the number of bytes to return. This value can
be specified either in the request body, or as a part of the URL.
- `format` `(string: "base64")` Specifies the output encoding. Valid options
are `hex` or `base64`.
### Sample Payload
```json
{
"format": "hex"
}
```
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request POST \
--data @payload.json \
https://vault.rocks/v1/transit/random/164
```
### Sample Response
```json
{
"data": {
"random_bytes": "dGhlIHF1aWNrIGJyb3duIGZveAo="
}
}
```
## Hash Data
This endpoint returns the cryptographic hash of given data using the specified
algorithm.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `POST` | `/transit/hash(/:algorithm)` | `200 application/json` |
### Parameters
- `algorithm` `(string: "sha2-256")` Specifies the hash algorithm to use. This
can also be specified as part of the URL. Currently-supported algorithms are:
- `sha2-224`
- `sha2-256`
- `sha2-384`
- `sha2-512`
- `input` `(string: <required>)`  Specifies the **base64 encoded** input data.
- `format` `(string: "hex")`  Specifies the output encoding. This can be either
`hex` or `base64`.
### Sample Payload
```json
{
"input": "adba32=="
}
```
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request POST \
--data @payload.json \
https://vault.rocks/v1/transit/hash/sha2-512
```
### Sample Response
```json
{
"data": {
"sum": "dGhlIHF1aWNrIGJyb3duIGZveAo="
}
}
```
## Generate HMAC with Key
This endpoint returns the digest of given data using the specified hash
algorithm and the named key. The key can be of any type supported by `transit`;
the raw key will be marshaled into bytes to be used for the HMAC function. If
the key is of a type that supports rotation, the latest (current) version will
be used.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `POST` | `/transit/hmac/:name(/:algorithm)` | `200 application/json` |
### Parameters
- `name` `(string: <required>)` Specifies the name of the encryption key to
generate hmac against. This is specified as part of the URL.
- `algorithm` `(string: "sha2-256")` Specifies the hash algorithm to use. This
can also be specified as part of the URL. Currently-supported algorithms are:
- `sha2-224`
- `sha2-256`
- `sha2-384`
- `sha2-512`
- `input` `(string: <required>)`  Specifies the **base64 encoded** input data.
- `format` `(string: "hex")`  Specifies the output encoding. This can be either
`hex` or `base64`.
### Sample Payload
```json
{
"input": "adba32=="
}
```
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request POST \
--data @payload.json \
https://vault.rocks/v1/transit/hmac/my-key/sha2-512
```
### Sample Response
```json
{
"data": {
"hmac": "dGhlIHF1aWNrIGJyb3duIGZveAo="
}
}
```
## Sign Data with Key
This endpoint returns the cryptographic signature of the given data using the
named key and the specified hash algorithm. The key must be of a type that
supports signing.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `POST` | `/transit/sign/:name(/:algorithm)` | `200 application/json` |
### Parameters
- `name` `(string: <required>)` Specifies the name of the encryption key to
generate hmac against. This is specified as part of the URL.
- `algorithm` `(string: "sha2-256")` Specifies the hash algorithm to use. This
can also be specified as part of the URL. Currently-supported algorithms are:
- `sha2-224`
- `sha2-256`
- `sha2-384`
- `sha2-512`
- `input` `(string: <required>)`  Specifies the **base64 encoded** input data.
- `format` `(string: "hex")`  Specifies the output encoding. This can be either
`hex` or `base64`.
### Sample Payload
```json
{
"input": "adba32=="
}
```
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request POST \
--data @payload.json \
https://vault.rocks/v1/transit/sign/my-key/sha2-512
```
### Sample Response
```json
{
"data": {
"signature": "vault:v1:MEUCIQCyb869d7KWuA0hBM9b5NJrmWzMW3/pT+0XYCM9VmGR+QIgWWF6ufi4OS2xo1eS2V5IeJQfsi59qeMWtgX0LipxEHI="
}
}
```
## Verify Data with Key
This endpoint returns whether the provided signature is valid for the given
data.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `POST` | `/transit/verify/:name(/:algorithm)` | `200 application/json` |
### Parameters
- `name` `(string: <required>)` Specifies the name of the encryption key to
generate hmac against. This is specified as part of the URL.
- `algorithm` `(string: "sha2-256")` Specifies the hash algorithm to use. This
can also be specified as part of the URL. Currently-supported algorithms are:
- `sha2-224`
- `sha2-256`
- `sha2-384`
- `sha2-512`
- `input` `(string: <required>)`  Specifies the **base64 encoded** input data.
- `format` `(string: "hex")`  Specifies the output encoding. This can be either
`hex` or `base64`.
- `signature` `(string: "")`  Specifies the signature output from the
`/transit/sign` function. Either this must be supplied or `hmac` must be
supplied.
- `hmac` `(string: "")`  Specifies the signature output from the
`/transit/hmac` function. Either this must be supplied or `signature` must be
supplied.
### Sample Payload
```json
{
"input": "abcd13==",
"signature": "vault:v1:MEUCIQCyb869d7KWuA..."
}
```
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request POST \
--data @payload.json \
https://vault.rocks/v1/transit/verify/my-key/sha2-512
```
### Sample Response
```json
{
"data": {
"valid": true
}
}
```

View file

@ -1,53 +0,0 @@
---
layout: "http"
page_title: "HTTP API: /sys/audit-hash"
sidebar_current: "docs-http-audits-hash"
description: |-
The `/sys/audit-hash` endpoint is used to hash data using an audit backend's hash function and salt.
---
# /sys/audit-hash
## POST
<dl>
<dt>Description</dt>
<dd>
Hash the given input data with the specified audit backend's hash function
and salt. This endpoint can be used to discover whether a given plaintext
string (the `input` parameter) appears in the audit log in obfuscated form.
Note that the audit log records requests and responses; since the Vault API
is JSON-based, any binary data returned from an API call (such as a
DER-format certificate) is base64-encoded by the Vault server in the
response, and as a result such information should also be base64-encoded to
supply into the `input` parameter.
</dd>
<dt>Method</dt>
<dd>POST</dd>
<dt>URL</dt>
<dd>`/sys/audit-hash/<path>`</dd>
<dt>Parameters</dt>
<dd>
<ul>
<li>
<span class="param">input</span>
<span class="param-flags">required</span>
The input string to hash.
</li>
</ul>
</dd>
<dt>Returns</dt>
<dd>
```javascript
{
"hash": "hmac-sha256:08ba357e274f528065766c770a639abf6809b39ccfd37c2a3157c7f51954da0a"
}
```
</dd>
</dl>

View file

@ -1,110 +0,0 @@
---
layout: "http"
page_title: "HTTP API: /sys/audit"
sidebar_current: "docs-http-audits-audits"
description: |-
The `/sys/audit` endpoint is used to enable and disable audit backends.
---
# /sys/audit
## GET
<dl>
<dt>Description</dt>
<dd>
List the mounted audit backends. _This endpoint requires `sudo`
capability._
</dd>
<dt>Method</dt>
<dd>GET</dd>
<dt>Parameters</dt>
<dd>
None
</dd>
<dt>Returns</dt>
<dd>
```javascript
{
"file": {
"type": "file",
"description": "Store logs in a file",
"options": {
"path": "/var/log/file"
}
}
}
```
</dd>
</dl>
## PUT
<dl>
<dt>Description</dt>
<dd>
Enable an audit backend. _This endpoint requires `sudo` capability._
</dd>
<dt>Method</dt>
<dd>PUT</dd>
<dt>URL</dt>
<dd>`/sys/audit/<path>`</dd>
<dt>Parameters</dt>
<dd>
<ul>
<li>
<span class="param">type</span>
<span class="param-flags">required</span>
The type of the audit backend.
</li>
<li>
<span class="param">description</span>
<span class="param-flags">optional</span>
A description of the audit backend for operators.
</li>
<li>
<span class="param">options</span>
<span class="param-flags">optional</span>
An object of options to configure the backend. This is
dependent on the backend type. Please consult the documentation
for the backend type you intend to use.
</li>
</ul>
</dd>
<dt>Returns</dt>
<dd>`204` response code.
</dd>
</dl>
## DELETE
<dl>
<dt>Description</dt>
<dd>
Disable the given audit backend. _This endpoint requires `sudo`
capability._
</dd>
<dt>Method</dt>
<dd>DELETE</dd>
<dt>URL</dt>
<dd>`/sys/audit/<path>`</dd>
<dt>Parameters</dt>
<dd>None
</dd>
<dt>Returns</dt>
<dd>`204` response code.
</dd>
</dl>

View file

@ -1,182 +0,0 @@
---
layout: "http"
page_title: "HTTP API: /sys/auth"
sidebar_current: "docs-http-auth-auth"
description: |-
The `/sys/auth` endpoint is used to manage auth backends in Vault.
---
# /sys/auth
## GET
<dl>
<dt>Description</dt>
<dd>
Lists all the enabled auth backends.
</dd>
<dt>Method</dt>
<dd>GET</dd>
<dt>Parameters</dt>
<dd>
None
</dd>
<dt>Returns</dt>
<dd>
```javascript
{
"github": {
"type": "github",
"description": "GitHub auth"
}
}
```
</dd>
</dl>
## POST
<dl>
<dt>Description</dt>
<dd>
Enable a new auth backend. The auth backend can be accessed and configured
via the auth path specified in the URL. This auth path will be exposed
under the `auth` prefix. For example, enabling with the `/sys/auth/foo` URL
will make the backend available at `/auth/foo`. _This endpoint requires
`sudo` capability on the final path._
</dd>
<dt>Method</dt>
<dd>POST</dd>
<dt>URL</dt>
<dd>`/sys/auth/<auth_path>`</dd>
<dt>Parameters</dt>
<dd>
<ul>
<li>
<span class="param">type</span>
<span class="param-flags">required</span>
The name of the auth backend type, such as "github"
</li>
<li>
<span class="param">description</span>
<span class="param-flags">optional</span>
A human-friendly description of the auth backend.
</li>
</ul>
</dd>
<dt>Returns</dt>
<dd>`204` response code.
</dd>
</dl>
## DELETE
<dl>
<dt>Description</dt>
<dd>
Disable the auth backend at the given auth path. _This endpoint requires
`sudo` capability on the final path._
</dd>
<dt>Method</dt>
<dd>DELETE</dd>
<dt>URL</dt>
<dd>`/sys/auth/<auth_path>`</dd>
<dt>Parameters</dt>
<dd>None
</dd>
<dt>Returns</dt>
<dd>`204` response code.
</dd>
</dl>
# /sys/auth/[auth-path]/tune
## GET
<dl>
<dt>Description</dt>
<dd>
Read the given auth path's configuration. Returns the current time
in seconds for each TTL, which may be the system default or a auth path
specific value. _This endpoint requires `sudo` capability on the final
path, but the same functionality can be achieved without `sudo` via
`sys/mounts/auth/[auth-path]/tune`._
</dd>
<dt>Method</dt>
<dd>GET</dd>
<dt>URL</dt>
<dd>`/sys/auth/[auth-path]/tune`</dd>
<dt>Parameters</dt>
<dd>
None
</dd>
<dt>Returns</dt>
<dd>
```javascript
{
"default_lease_ttl": 3600,
"max_lease_ttl": 7200
}
```
</dd>
</dl>
## POST
<dl>
<dt>Description</dt>
<dd>
Tune configuration parameters for a given auth path. _This endpoint
requires `sudo` capability on the final path, but the same functionality
can be achieved without `sudo` via `sys/mounts/auth/[auth-path]/tune`._
</dd>
<dt>Method</dt>
<dd>POST</dd>
<dt>URL</dt>
<dd>`/sys/auth/[auth-path]/tune`</dd>
<dt>Parameters</dt>
<dd>
<ul>
<li>
<span class="param">default_lease_ttl</span>
<span class="param-flags">optional</span>
The default time-to-live. If set on a specific auth path,
overrides the global default. A value of "system" or "0"
are equivalent and set to the system default TTL.
</li>
<li>
<span class="param">max_lease_ttl</span>
<span class="param-flags">optional</span>
The maximum time-to-live. If set on a specific auth path,
overrides the global default. A value of "system" or "0"
are equivalent and set to the system max TTL.
</li>
</ul>
</dd>
<dt>Returns</dt>
<dd>`204` response code.
</dd>
</dl>

View file

@ -1,48 +0,0 @@
---
layout: "http"
page_title: "HTTP API: /sys/capabilities-accessor"
sidebar_current: "docs-http-auth-capabilities-accessor"
description: |-
The `/sys/capabilities-accessor` endpoint is used to fetch the capabilities of the token associated with an accessor, on the given path.
---
# /sys/capabilities-accessor
## POST
<dl>
<dt>Description</dt>
<dd>
Returns the capabilities of the token associated with an accessor, on the given path.
</dd>
<dt>Method</dt>
<dd>POST</dd>
<dt>Parameters</dt>
<dd>
<ul>
<li>
<span class="param">accessor</span>
<span class="param-flags">required</span>
Accessor of the token.
</li>
<li>
<span class="param">path</span>
<span class="param-flags">required</span>
Path on which the token's capabilities will be checked.
</li>
</ul>
</dd>
<dt>Returns</dt>
<dd>
```javascript
{
"capabilities": ["read", "list"]
}
```
</dd>
</dl>

View file

@ -1,44 +0,0 @@
---
layout: "http"
page_title: "HTTP API: /sys/capabilities-self"
sidebar_current: "docs-http-auth-capabilities-self"
description: |-
The `/sys/capabilities-self` endpoint is used to fetch the capabilities of client token on a given path.
---
# /sys/capabilities-self
## POST
<dl>
<dt>Description</dt>
<dd>
Returns the capabilities of client token on the given path.
Client token is the Vault token with which this API call is made.
</dd>
<dt>Method</dt>
<dd>POST</dd>
<dt>Parameters</dt>
<dd>
<ul>
<li>
<span class="param">path</span>
<span class="param-flags">required</span>
Path on which the client token's capabilities will be checked.
</li>
</ul>
</dd>
<dt>Returns</dt>
<dd>
```javascript
{
"capabilities": ["read", "list"]
}
```
</dd>
</dl>

View file

@ -1,48 +0,0 @@
---
layout: "http"
page_title: "HTTP API: /sys/capabilities"
sidebar_current: "docs-http-auth-capabilities"
description: |-
The `/sys/capabilities` endpoint is used to fetch the capabilities of a token on a given path.
---
# /sys/capabilities
## POST
<dl>
<dt>Description</dt>
<dd>
Returns the capabilities of the token on the given path.
</dd>
<dt>Method</dt>
<dd>POST</dd>
<dt>Parameters</dt>
<dd>
<ul>
<li>
<span class="param">token</span>
<span class="param-flags">required</span>
Token for which capabilities are being queried.
</li>
<li>
<span class="param">path</span>
<span class="param-flags">required</span>
Path on which the token's capabilities will be checked.
</li>
</ul>
</dd>
<dt>Returns</dt>
<dd>
```javascript
{
"capabilities": ["read", "list"]
}
```
</dd>
</dl>

View file

@ -1,133 +0,0 @@
---
layout: "http"
page_title: "HTTP API: /sys/config/auditing"
sidebar_current: "docs-http-config-auditing"
description: |-
The `/sys/config/auditing` endpoint is used to configure auditing settings.
---
# /sys/config/auditing/request-headers
## GET
<dl>
<dt>Description</dt>
<dd>
List the request headers that are configured to be audited. _This endpoint requires `sudo`
capability._
</dd>
<dt>Method</dt>
<dd>GET</dd>
<dt>Parameters</dt>
<dd>
None
</dd>
<dt>Returns</dt>
<dd>
```javascript
{
"headers": {
"X-Forwarded-For": {
"hmac":true
}
}
}
```
</dd>
</dl>
# /sys/config/auditing/request-headers/
## GET
<dl>
<dt>Description</dt>
<dd>
List the information for the given request header. _This endpoint requires `sudo`
capability._
</dd>
<dt>Method</dt>
<dd>GET</dd>
<dt>URL</dt>
<dd>`/sys/config/auditing/request-headers/<name>`</dd>
<dt>Parameters</dt>
<dd>
None
</dd>
<dt>Returns</dt>
<dd>
```javascript
{
"X-Forwarded-For": {
"hmac":true
}
}
```
</dd>
</dl>
## PUT
<dl>
<dt>Description</dt>
<dd>
Enable auditing of a header. _This endpoint requires `sudo` capability._
</dd>
<dt>Method</dt>
<dd>PUT</dd>
<dt>URL</dt>
<dd>`/sys/config/auditing/request-headers/<name>`</dd>
<dt>Parameters</dt>
<dd>
<ul>
<li>
<span class="param">hmac</span>
<span class="param-flags">optional</span>
Bool, if this header's value should be hmac'ed in the audit logs.
Defaults to false.
</li>
</ul>
</dd>
<dt>Returns</dt>
<dd>`204` response code.
</dd>
</dl>
## DELETE
<dl>
<dt>Description</dt>
<dd>
Disable auditing of the given request header. _This endpoint requires `sudo`
capability._
</dd>
<dt>Method</dt>
<dd>DELETE</dd>
<dt>URL</dt>
<dd>`/sys/config/auditing/request-headers/<name>`</dd>
<dt>Parameters</dt>
<dd>None
</dd>
<dt>Returns</dt>
<dd>`204` response code.
</dd>
</dl>

View file

@ -1,188 +0,0 @@
---
layout: "http"
page_title: "HTTP API: /sys/generate-root/"
sidebar_current: "docs-http-sys-generate-root"
description: |-
The `/sys/generate-root/` endpoints are used to create a new root key for Vault.
---
# /sys/generate-root/attempt
## GET
<dl>
<dt>Description</dt>
<dd>
Reads the configuration and progress of the current root generation
attempt.
</dd>
<dt>Method</dt>
<dd>GET</dd>
<dt>URL</dt>
<dd>`/sys/generate-root/attempt`</dd>
<dt>Parameters</dt>
<dd>
None
</dd>
<dt>Returns</dt>
<dd>
If a root generation is started, `progress` is how many unseal keys have
been provided for this generation attempt, where `required` must be reached
to complete. The `nonce` for the current attempt and whether the attempt is
complete is also displayed. If a PGP key is being used to encrypt the final
root token, its fingerprint will be returned. Note that if an OTP is being
used to encode the final root token, it will never be returned.
```javascript
{
"started": true,
"nonce": "2dbd10f1-8528-6246-09e7-82b25b8aba63",
"progress": 1,
"required": 3,
"encoded_root_token": "",
"pgp_fingerprint": "",
"complete": false
}
```
</dd>
</dl>
## PUT
<dl>
<dt>Description</dt>
<dd>
Initializes a new root generation attempt. Only a single root generation
attempt can take place at a time. One (and only one) of `otp` or `pgp_key`
are required.
</dd>
<dt>Method</dt>
<dd>PUT</dd>
<dt>URL</dt>
<dd>`/sys/generate-root/attempt`</dd>
<dt>Parameters</dt>
<dd>
<ul>
<li>
<span class="param">otp</span>
<span class="param-flags">optional</span>
A base64-encoded 16-byte value. The raw bytes of the token will be
XOR'd with this value before being returned to the final unseal key
provider.
</li>
<li>
<span class="param">pgp_key</span>
<span class="param-flags">optional</span>
A base64-encoded PGP public key. The raw bytes of the token will be
encrypted with this value before being returned to the final unseal key
provider.
</li>
</ul>
</dd>
<dt>Returns</dt>
<dd>
The current progress.
```javascript
{
"started": true,
"nonce": "2dbd10f1-8528-6246-09e7-82b25b8aba63",
"progress": 1,
"required": 3,
"encoded_root_token": "",
"pgp_fingerprint": "816938b8a29146fbe245dd29e7cbaf8e011db793",
"complete": false
}
```
</dd>
</dl>
## DELETE
<dl>
<dt>Description</dt>
<dd>
Cancels any in-progress root generation attempt. This clears any progress
made. This must be called to change the OTP or PGP key being used.
</dd>
<dt>Method</dt>
<dd>DELETE</dd>
<dt>URL</dt>
<dd>`/sys/generate-root/attempt`</dd>
<dt>Parameters</dt>
<dd>None
</dd>
<dt>Returns</dt>
<dd>`204` response code.
</dd>
</dl>
# /sys/generate-root/update
## PUT
<dl>
<dt>Description</dt>
<dd>
Enter a single master key share to progress the root generation attempt.
If the threshold number of master key shares is reached, Vault will
complete the root generation and issue the new token. Otherwise, this API
must be called multiple times until that threshold is met. The attempt
nonce must be provided with each call.
</dd>
<dt>Method</dt>
<dd>PUT</dd>
<dt>URL</dt>
<dd>`/sys/generate-root/update`</dd>
<dt>Parameters</dt>
<dd>
<ul>
<li>
<span class="param">key</span>
<span class="param-flags">required</span>
A single master share key.
</li>
<li>
<span class="param">nonce</span>
<span class="param-flags">required</span>
The nonce of the attempt.
</li>
</ul>
</dd>
<dt>Returns</dt>
<dd>
A JSON-encoded object indicating the attempt nonce, and completion status,
and the encoded root token, if the attempt is complete.
```javascript
{
"started": true,
"nonce": "2dbd10f1-8528-6246-09e7-82b25b8aba63",
"progress": 3,
"required": 3,
"pgp_fingerprint": "",
"complete": true,
"encoded_root_token": "FPzkNBvwNDeFh4SmGA8c+w=="
}
```
</dd>
</dl>

View file

@ -1,81 +0,0 @@
---
layout: "http"
page_title: "HTTP API: /sys/health"
sidebar_current: "docs-http-debug-health"
description: |-
The '/sys/health' endpoint is used to check the health status of Vault.
---
# /sys/health
<dl>
<dt>Description</dt>
<dd>
Returns the health status of Vault. This matches the semantics of a
Consul HTTP health check and provides a simple way to monitor the
health of a Vault instance.
</dd>
<dt>Method</dt>
<dd>GET/HEAD</dd>
<dt>Parameters</dt>
<dd>
<ul>
<li>
<span class="param">standbyok</span>
<span class="param-flags">optional</span>
A query parameter provided to indicate that being a standby should
still return the active status code instead of the standby code
</li>
<li>
<span class="param">activecode</span>
<span class="param-flags">optional</span>
A query parameter provided to indicate the status code that should
be returned for an active node instead of the default of `200`
</li>
<li>
<span class="param">standbycode</span>
<span class="param-flags">optional</span>
A query parameter provided to indicate the status code that should
be returned for a standby node instead of the default of `429`
</li>
<li>
<span class="param">sealedcode</span>
<span class="param-flags">optional</span>
A query parameter provided to indicate the status code that should
be returned for a sealed node instead of the default of `503`
</li>
<li>
<span class="param">uninitcode</span>
<span class="param-flags">optional</span>
A query parameter provided to indicate the status code that should
be returned for an uninitialized Vault instead of the default of
`501`
</li>
</ul>
</dd>
<dt>Returns (only with GET)</dt>
<dd>
```javascript
{
"cluster_id": "c9abceea-4f46-4dab-a688-5ce55f89e228",
"cluster_name": "vault-cluster-5515c810",
"version": "0.6.1-dev"
"server_time_utc": 1469555798,
"standby": false,
"sealed": false,
"initialized": true
}
```
Default Status Codes (GET/HEAD):
* `200` if initialized, unsealed, and active.
* `429` if unsealed and standby.
* `501` if not initialized.
* `503` if sealed.
</dd>
</dl>

View file

@ -1,130 +0,0 @@
---
layout: "http"
page_title: "HTTP API: /sys/init"
sidebar_current: "docs-http-sys-init"
description: |-
The '/sys/init' endpoint is used to initialize a new Vault.
---
# /sys/init
## GET
<dl>
<dt>Description</dt>
<dd>
Return the initialization status of a Vault.
</dd>
<dt>Method</dt>
<dd>GET</dd>
<dt>Parameters</dt>
<dd>None</dd>
<dt>Returns</dt>
<dd>
```javascript
{
"initialized": true
}
```
</dd>
</dl>
## PUT
<dl>
<dt>Description</dt>
<dd>
Initializes a new Vault. The Vault must not have been previously
initialized. The recovery options, as well as the stored shares option, are
only available when using Vault HSM.
</dd>
<dt>Method</dt>
<dd>PUT</dd>
<dt>Parameters</dt>
<dd>
<ul>
<li>
<span class="param">root_token_pgp_key</span>
<span class="param-flags">optional</span>
A PGP public key used to encrypt the initial root token. The key
must be base64-encoded from its original binary representation.
</li>
<li>
<span class="param">secret_shares</span>
<span class="param-flags">required</span>
The number of shares to split the master key into.
</li>
<li>
<span class="param">secret_threshold</span>
<span class="param-flags">required</span>
The number of shares required to reconstruct the master key. This must
be less than or equal to <code>secret_shares</code>. If using Vault HSM
with auto-unsealing, this value must be the same as
<code>secret_shares</code>.
</li>
<li>
<span class="param">pgp_keys</span>
<span class="param-flags">optional</span>
An array of PGP public keys used to encrypt the output unseal keys.
Ordering is preserved. The keys must be base64-encoded from their
original binary representation. The size of this array must be the
same as <code>secret_shares</code>.
</li>
<li>
<span class="param">stored_shares</span>
<span class="param-flags">required</span>
The number of shares that should be encrypted by the HSM and stored for
auto-unsealing (Vault HSM only). Currently must be the same as
<code>secret_shares</code>.
</li>
<li>
<span class="param">recovery_shares</span>
<span class="param-flags">required</span>
The number of shares to split the recovery key into (Vault HSM only).
</li>
<li>
<span class="param">recovery_threshold</span>
<span class="param-flags">required</span>
The number of shares required to reconstruct the recovery key (Vault
HSM only). This must be less than or equal to
<code>recovery_shares</code>.
</li>
<li>
<span class="param">recovery_pgp_keys</span>
<span class="param-flags">optional</span>
An array of PGP public keys used to encrypt the output recovery keys
(Vault HSM only). Ordering is preserved. The keys must be
base64-encoded from their original binary representation. The size of
this array must be the same as <code>recovery_shares</code>.
</li>
</ul>
</dd>
<dt>Returns</dt>
<dd>
A JSON-encoded object including the (possibly encrypted, if
<code>pgp_keys</code> was provided) master keys, base 64 encoded master keys and initial root token:
```javascript
{
"keys": ["one", "two", "three"],
"keys_base64": ["cR9No5cBC", "F3VLrkOo", "zIDSZNGv"],
"root_token": "foo"
}
```
</dd>
<dt>See Also</dt>
<dd>
For more information on the PGP/Keybase.io process please see the
[Vault GPG and Keybase integration documentation](/docs/concepts/pgp-gpg-keybase.html).
</dd>
</dl>

View file

@ -1,38 +0,0 @@
---
layout: "http"
page_title: "HTTP API: /sys/key-status"
sidebar_current: "docs-http-rotate-key-status"
description: |-
The '/sys/key-status' endpoint is used to query info about the current encryption key of Vault.
---
# /sys/key-status
<dl>
<dt>Description</dt>
<dd>
Returns information about the current encryption key used by Vault.
</dd>
<dt>Method</dt>
<dd>GET</dd>
<dt>Parameters</dt>
<dd>
None
</dd>
<dt>Returns</dt>
<dd>
The "term" parameter is the sequential key number, and "install_time" is the time that
encryption key was installed.
```javascript
{
"term": 3,
"install_time": "2015-05-29T14:50:46.223692553-07:00"
}
```
</dd>
</dl>

View file

@ -1,37 +0,0 @@
---
layout: "http"
page_title: "HTTP API: /sys/leader"
sidebar_current: "docs-http-ha-leader"
description: |-
The '/sys/leader' endpoint is used to check the high availability status and current leader of Vault.
---
# /sys/leader
<dl>
<dt>Description</dt>
<dd>
Returns the high availability status and current leader instance of Vault.
</dd>
<dt>Method</dt>
<dd>GET</dd>
<dt>Parameters</dt>
<dd>
None
</dd>
<dt>Returns</dt>
<dd>
```javascript
{
"ha_enabled": true,
"is_self": false,
"leader_address": "https://127.0.0.1:8200/"
}
```
</dd>
</dl>

View file

@ -1,203 +0,0 @@
---
layout: "http"
page_title: "HTTP API: /sys/mounts"
sidebar_current: "docs-http-mounts-mounts"
description: |-
The '/sys/mounts' endpoint is used manage secret backends in Vault.
---
# /sys/mounts
## GET
<dl>
<dt>Description</dt>
<dd>
Lists all the mounted secret backends. `default_lease_ttl`
or `max_lease_ttl` values of `0` mean that the system
defaults are used by this backend.
</dd>
<dt>Method</dt>
<dd>GET</dd>
<dt>URL</dt>
<dd>`/sys/mounts`</dd>
<dt>Parameters</dt>
<dd>
None
</dd>
<dt>Returns</dt>
<dd>
```javascript
{
"aws": {
"type": "aws",
"description": "AWS keys",
"config": {
"default_lease_ttl": 0,
"max_lease_ttl": 0,
"force_no_cache": false
}
},
"sys": {
"type": "system",
"description": "system endpoint",
"config": {
"default_lease_ttl": 0,
"max_lease_ttl": 0,
"force_no_cache": false
}
}
}
```
</dd>
</dl>
## POST
<dl>
<dt>Description</dt>
<dd>
Mount a new secret backend to the mount point in the URL.
</dd>
<dt>Method</dt>
<dd>POST</dd>
<dt>URL</dt>
<dd>`/sys/mounts/<mount point>`</dd>
<dt>Parameters</dt>
<dd>
<ul>
<li>
<span class="param">type</span>
<span class="param-flags">required</span>
The name of the backend type, such as "aws"
</li>
<li>
<span class="param">description</span>
<span class="param-flags">optional</span>
A human-friendly description of the mount.
</li>
<li>
<span class="param">config</span>
<span class="param-flags">optional</span>
Config options for this mount. This is an object with
three possible values: `default_lease_ttl`,
`max_lease_ttl`, and`force_no_cache`. These control the default and
maximum lease time-to-live, and force disabling backend caching respectively.
If set on a specific mount, this overrides the global defaults.
</li>
</ul>
</dd>
<dt>Returns</dt>
<dd>`204` response code.
</dd>
</dl>
## DELETE
<dl>
<dt>Description</dt>
<dd>
Unmount the mount point specified in the URL.
</dd>
<dt>Method</dt>
<dd>DELETE</dd>
<dt>URL</dt>
<dd>`/sys/mounts/<mount point>`</dd>
<dt>Parameters</dt>
<dd>None
</dd>
<dt>Returns</dt>
<dd>`204` response code.
</dd>
</dl>
# /sys/mounts/[mount point]/tune
## GET
<dl>
<dt>Description</dt>
<dd>
Read the given mount's configuration. Unlike the `mounts`
endpoint, this will return the current time in seconds for each
TTL, which may be the system default or a mount-specific value.
</dd>
<dt>Method</dt>
<dd>GET</dd>
<dt>URL</dt>
<dd>`/sys/mounts/<mount point>/tune`</dd>
<dt>Parameters</dt>
<dd>
None
</dd>
<dt>Returns</dt>
<dd>
```javascript
{
"default_lease_ttl": 3600,
"max_lease_ttl": 7200,
"force_no_cache": false
}
```
</dd>
</dl>
## POST
<dl>
<dt>Description</dt>
<dd>
Tune configuration parameters for a given mount point.
</dd>
<dt>Method</dt>
<dd>POST</dd>
<dt>URL</dt>
<dd>`/sys/mounts/<mount point>/tune`</dd>
<dt>Parameters</dt>
<dd>
<ul>
<li>
<span class="param">default_lease_ttl</span>
<span class="param-flags">optional</span>
The default time-to-live. If set on a specific mount,
overrides the global default. A value of "system" or "0"
are equivalent and set to the system default TTL.
</li>
<li>
<span class="param">max_lease_ttl</span>
<span class="param-flags">optional</span>
The maximum time-to-live. If set on a specific mount,
overrides the global default. A value of "system" or "0"
are equivalent and set to the system max TTL.
</li>
</ul>
</dd>
<dt>Returns</dt>
<dd>`204` response code.
</dd>
</dl>

View file

@ -1,126 +0,0 @@
---
layout: "http"
page_title: "HTTP API: /sys/policy"
sidebar_current: "docs-http-auth-policy"
description: |-
The `/sys/policy` endpoint is used to manage ACL policies in Vault.
---
# /sys/policy
## GET
<dl>
<dt>Description</dt>
<dd>
Lists all the available policies.
</dd>
<dt>Method</dt>
<dd>GET</dd>
<dt>Parameters</dt>
<dd>
None
</dd>
<dt>Returns</dt>
<dd>
```javascript
{
"policies": ["root", "deploy"]
}
```
</dd>
</dl>
# /sys/policy/
## GET
<dl>
<dt>Description</dt>
<dd>
Retrieve the rules for the named policy.
</dd>
<dt>Method</dt>
<dd>GET</dd>
<dt>URL</dt>
<dd>`/sys/policy/<name>`</dd>
<dt>Parameters</dt>
<dd>
None
</dd>
<dt>Returns</dt>
<dd>
```javascript
{
"rules": "path..."
}
```
</dd>
</dl>
## PUT
<dl>
<dt>Description</dt>
<dd>
Add or update a policy. Once a policy is updated, it takes effect
immediately to all associated users.
</dd>
<dt>Method</dt>
<dd>PUT</dd>
<dt>URL</dt>
<dd>`/sys/policy/<name>`</dd>
<dt>Parameters</dt>
<dd>
<ul>
<li>
<span class="param">rules</span>
<span class="param-flags">required</span>
The policy document.
</li>
</ul>
</dd>
<dt>Returns</dt>
<dd>`204` response code.
</dd>
</dl>
## DELETE
<dl>
<dt>Description</dt>
<dd>
Delete the policy with the given name. This will immediately
affect all associated users.
</dd>
<dt>Method</dt>
<dd>DELETE</dd>
<dt>URL</dt>
<dd>`/sys/policy/<name>`</dd>
<dt>Parameters</dt>
<dd>None
</dd>
<dt>Returns</dt>
<dd>`204` response code.
</dd>
</dl>

View file

@ -1,96 +0,0 @@
---
layout: "http"
page_title: "HTTP API: /sys/raw"
sidebar_current: "docs-http-debug-raw"
description: |-
The `/sys/raw` endpoint is access the raw underlying store in Vault.
---
# /sys/raw
## GET
<dl>
<dt>Description</dt>
<dd>
Reads the value of the key at the given path. This is the raw path in the
storage backend and not the logical path that is exposed via the mount system.
</dd>
<dt>Method</dt>
<dd>GET</dd>
<dt>URL</dt>
<dd>`/sys/raw/<path>`</dd>
<dt>Parameters</dt>
<dd>
None
</dd>
<dt>Returns</dt>
<dd>
```javascript
{
"value": "{'foo':'bar'}"
}
```
</dd>
</dl>
## PUT
<dl>
<dt>Description</dt>
<dd>
Update the value of the key at the given path. This is the raw path in the
storage backend and not the logical path that is exposed via the mount system.
</dd>
<dt>Method</dt>
<dd>PUT</dd>
<dt>URL</dt>
<dd>`/sys/raw/<path>`</dd>
<dt>Parameters</dt>
<dd>
<ul>
<li>
<span class="param">value</span>
<span class="param-flags">required</span>
The value of the key.
</li>
</ul>
</dd>
<dt>Returns</dt>
<dd>`204` response code.
</dd>
</dl>
## DELETE
<dl>
<dt>Description</dt>
<dd>
Delete the key with given path. This is the raw path in the
storage backend and not the logical path that is exposed via the mount system.
</dd>
<dt>Method</dt>
<dd>DELETE</dd>
<dt>URL</dt>
<dd>`/sys/raw/<path>`</dd>
<dt>Parameters</dt>
<dd>None
</dd>
<dt>Returns</dt>
<dd>`204` response code.
</dd>
</dl>

View file

@ -1,251 +0,0 @@
---
layout: "http"
page_title: "HTTP API: /sys/rekey/"
sidebar_current: "docs-http-rotate-rekey"
description: |-
The `/sys/rekey/` endpoints are used to rekey the unseal keys for Vault.
---
# /sys/rekey/init
## GET
<dl>
<dt>Description</dt>
<dd>
Reads the configuration and progress of the current rekey attempt.
</dd>
<dt>Method</dt>
<dd>GET</dd>
<dt>URL</dt>
<dd>`/sys/rekey/init`</dd>
<dt>Parameters</dt>
<dd>
None
</dd>
<dt>Returns</dt>
<dd>
If a rekey is started, then `n` is the new shares to generate and `t` is
the threshold required for the new shares. `progress` is how many unseal
keys have been provided for this rekey, where `required` must be reached to
complete. The `nonce` for the current rekey operation is also displayed. If
PGP keys are being used to encrypt the final shares, the key fingerprints
and whether the final keys will be backed up to physical storage will also
be displayed.
```javascript
{
"started": true,
"nonce": "2dbd10f1-8528-6246-09e7-82b25b8aba63",
"t": 3,
"n": 5,
"progress": 1,
"required": 3,
"pgp_fingerprints": ["abcd1234"],
"backup": true
}
```
</dd>
</dl>
## PUT
<dl>
<dt>Description</dt>
<dd>
Initializes a new rekey attempt. Only a single rekey attempt can take place
at a time, and changing the parameters of a rekey requires canceling and
starting a new rekey, which will also provide a new nonce.
</dd>
<dt>Method</dt>
<dd>PUT</dd>
<dt>URL</dt>
<dd>`/sys/rekey/init`</dd>
<dt>Parameters</dt>
<dd>
<ul>
<li>
<span class="param">secret_shares</span>
<span class="param-flags">required</span>
The number of shares to split the master key into.
</li>
<li>
<span class="param">secret_threshold</span>
<span class="param-flags">required</span>
The number of shares required to reconstruct the master key.
This must be less than or equal to <code>secret_shares</code>.
</li>
<li>
<spam class="param">pgp_keys</span>
<span class="param-flags">optional</spam>
An array of PGP public keys used to encrypt the output unseal keys.
Ordering is preserved. The keys must be base64-encoded from their
original binary representation. The size of this array must be the
same as <code>secret_shares</code>.
</li>
<li>
<spam class="param">backup</span>
<span class="param-flags">optional</spam>
If using PGP-encrypted keys, whether Vault should also back them up to
a well-known location in physical storage (`core/unseal-keys-backup`).
These can then be retrieved and removed via the `sys/rekey/backup`
endpoint.
</li>
</ul>
</dd>
<dt>Returns</dt>
<dd>`204` response code.
</dd>
</dl>
## DELETE
<dl>
<dt>Description</dt>
<dd>
Cancels any in-progress rekey. This clears the rekey settings as well as any
progress made. This must be called to change the parameters of the rekey.
</dd>
<dt>Method</dt>
<dd>DELETE</dd>
<dt>URL</dt>
<dd>`/sys/rekey/init`</dd>
<dt>Parameters</dt>
<dd>None
</dd>
<dt>Returns</dt>
<dd>`204` response code.
</dd>
</dl>
# /sys/rekey/backup
## GET
<dl>
<dt>Description</dt>
<dd>
Return the backup copy of PGP-encrypted unseal keys. The returned value is
the nonce of the rekey operation and a map of PGP key fingerprint to
hex-encoded PGP-encrypted key.
</dd>
<dt>Method</dt>
<dd>GET</dd>
<dt>URL</dt>
<dd>`/sys/rekey/backup`</dd>
<dt>Parameters</dt>
<dd>
None
</dd>
<dt>Returns</dt>
<dd>
```javascript
{
"nonce": "2dbd10f1-8528-6246-09e7-82b25b8aba63",
"keys": {
"abcd1234": "..."
}
}
```
</dd>
</dl>
## DELETE
<dl>
<dt>Description</dt>
<dd>
Delete the backup copy of PGP-encrypted unseal keys.
</dd>
<dt>Method</dt>
<dd>DELETE</dd>
<dt>URL</dt>
<dd>`/sys/rekey/backup`</dd>
<dt>Parameters</dt>
<dd>None
</dd>
<dt>Returns</dt>
<dd>`204` response code.
</dd>
</dl>
# /sys/rekey/update
## PUT
<dl>
<dt>Description</dt>
<dd>
Enter a single master key share to progress the rekey of the Vault.
If the threshold number of master key shares is reached, Vault
will complete the rekey. Otherwise, this API must be called multiple
times until that threshold is met. The rekey nonce operation must be
provided with each call.
</dd>
<dt>Method</dt>
<dd>PUT</dd>
<dt>URL</dt>
<dd>`/sys/rekey/update`</dd>
<dt>Parameters</dt>
<dd>
<ul>
<li>
<span class="param">key</span>
<span class="param-flags">required</span>
A single master share key.
</li>
<li>
<span class="param">nonce</span>
<span class="param-flags">required</span>
The nonce of the rekey operation.
</li>
</ul>
</dd>
<dt>Returns</dt>
<dd>
A JSON-encoded object indicating the rekey operation nonce and completion
status; if completed, the new master keys are returned. If the keys are
PGP-encrypted, an array of key fingerprints will also be provided (with the
order in which the keys were used for encryption) along with whether or not
the keys were backed up to physical storage:
```javascript
{
"complete": true,
"keys": ["one", "two", "three"],
"nonce": "2dbd10f1-8528-6246-09e7-82b25b8aba63",
"pgp_fingerprints": ["abcd1234"],
"keys_base64": ["base64keyvalue"],
"backup": true
}
```
</dd>
</dl>

View file

@ -1,39 +0,0 @@
---
layout: "http"
page_title: "HTTP API: /sys/remount"
sidebar_current: "docs-http-mounts-remount"
description: |-
The '/sys/remount' endpoint is used remount a mounted backend to a new endpoint.
---
# /sys/remount
<dl>
<dt>Description</dt>
<dd>
Remount an already-mounted backend to a new mount point.
</dd>
<dt>Method</dt>
<dd>POST</dd>
<dt>Parameters</dt>
<dd>
<ul>
<li>
<span class="param">from</span>
<span class="param-flags">required</span>
The previous mount point.
</li>
<li>
<span class="param">to</span>
<span class="param-flags">required</span>
The new mount point.
</li>
</ul>
</dd>
<dt>Returns</dt>
<dd>`204` response code.
</dd>
</dl>

View file

@ -1,44 +0,0 @@
---
layout: "http"
page_title: "HTTP API: /sys/renew"
sidebar_current: "docs-http-lease-renew"
description: |-
The `/sys/renew` endpoint is used to renew secrets.
---
# /sys/renew
<dl>
<dt>Description</dt>
<dd>
Renew a secret, requesting to extend the lease.
</dd>
<dt>Method</dt>
<dd>PUT</dd>
<dt>URL</dt>
<dd>`/sys/renew(/<lease id>)`</dd>
<dt>Parameters</dt>
<dd>
<ul>
<li>
<span class="param">increment</span>
<span class="param-flags">optional</span>
A requested amount of time in seconds to extend the lease.
This is advisory.
</li>
<li>
<span class="param">lease_id</span>
<span class="param-flags">required</span>
The ID of the lease to extend. This can be specified as part of the URL
or in the request body.
</li>
</ul>
</dd>
<dt>Returns</dt>
<dd>A secret structure.
</dd>
</dl>

View file

@ -1,118 +0,0 @@
---
layout: "http"
page_title: "HTTP API: /sys/replication"
sidebar_current: "docs-http-replication-common"
description: |-
The '/sys/replication' endpoint focuses on managing general operations in Vault Enterprise replication sets
---
# /sys/replication/recover
## POST
<dl>
<dt>Description</dt>
<dd>
Attempts recovery if replication is in an adverse state. For example: an
error has caused replication to stop syncing.
</dd>
<dt>Method</dt>
<dd>POST</dd>
<dt>URL</dt>
<dd>`/sys/replication/recover`</dd>
<dt>Parameters</dt>
<dd>
None
</dd>
<dt>Returns</dt>
<dd>
A `200` response code and a warning.
</dd>
</dl>
# /sys/replication/reindex
## POST
<dl>
<dt>Description</dt>
<dd>
Requires sudo capability. Reindex the local data storage. This can cause
a very long delay depending on the number and size of objects in the data
store.
</dd>
<dt>Method</dt>
<dd>POST</dd>
<dt>URL</dt>
<dd>`/sys/replication/reindex`</dd>
<dt>Parameters</dt>
<dd>
None
</dd>
<dt>Returns</dt>
<dd>
A `200` response code and a warning.
</dd>
</dl>
# /sys/replication/status
## GET
<dl>
<dt>Description</dt>
<dd>
Unauthenticated. Print information about the status of replication (mode,
sync progress, etc).
</dd>
<dt>Method</dt>
<dd>GET</dd>
<dt>URL</dt>
<dd>`/sys/replication/status`</dd>
<dt>Parameters</dt>
<dd>
None
</dd>
<dt>Returns</dt>
<dd>
The printed status of the replication environment. As an example, for a
primary, it will look something like:
```javascript
{
"mode": "primary",
"cluster_id": "d4095d41-3aee-8791-c421-9bc7f88f7c3e",
"known_secondaries": [],
"last_wal": 0,
"merkle_root": "c3260c4c682ff2d6eb3c8bfd877134b3cec022d1",
"request_id": "009ea98c-06cd-6dc3-74f2-c4904b22e535",
"lease_id": "",
"renewable": false,
"lease_duration": 0,
"data": {
"cluster_id": "d4095d41-3aee-8791-c421-9bc7f88f7c3e",
"known_secondaries": [],
"last_wal": 0,
"merkle_root": "c3260c4c682ff2d6eb3c8bfd877134b3cec022d1",
"mode": "primary"
},
"wrap_info": null,
"warnings": null,
"auth": null
}
```
</dd>
</dl>

View file

@ -1,206 +0,0 @@
---
layout: "http"
page_title: "HTTP API: /sys/repliation/primary"
sidebar_current: "docs-http-replication-primary"
description: |-
The '/sys/replication/primary' endpoint focuses on managing replication behavior for a primary cluster, including management of secondaries.
---
# /sys/replication/primary/enable
## POST
<dl>
<dt>Description</dt>
<dd>
Enables replication in primary mode. This is used when replication is
currently disabled on the cluster (if the cluster is already a secondary,
it must be promoted).
Caution: only one primary should be active at a given time. Multiple
primaries may result in data loss!
</dd>
<dt>Method</dt>
<dd>POST</dd>
<dt>URL</dt>
<dd>`/sys/repliation/primary/enable`</dd>
<dt>Parameters</dt>
<dd>
<ul>
<li>
<span class="param">primary_cluster_addr /span>
<span class="param-flags">optional</span>
Can be used to override the cluster address that the primary gives to
secondary nodes. Useful if the primarys cluster address is not
directly accessible and must be accessed via an alternate path/address,
such as through a TCP-based load balancer.
</li>
</ul>
</dd>
<dt>Returns</dt>
<dd>
`200` response code with a warning.
</dd>
</dl>
# /sys/replication/primary/demote
## POST
<dl>
<dt>Description</dt>
<dd>
Demotes a primary cluster to a secondary. This secondary cluster will not
attempt to connect to a primary (see the update-primary call), but will
maintain knowledge of its cluster ID and can be reconnected to the same
replication set without wiping local storage.
</dd>
<dt>Method</dt>
<dd>POST</dd>
<dt>URL</dt>
<dd>`/sys/repliation/primary/demote`</dd>
<dt>Parameters</dt>
<dd>
None
</dd>
<dt>Returns</dt>
<dd>
`200` response code with a warning.
</dd>
</dl>
# /sys/replication/primary/disable
## POST
<dl>
<dt>Description</dt>
<dd>
Disable replication entirely on the cluster. Any secondaries will no longer
be able to connect. Caution: re-enabling this node as a primary or secondary
will change its cluster ID; in the secondary case this means a wipe of the
underlying storage when connected to a primary, and in the primary case,
secondaries connecting back to the cluster (even if they have connected
before) will require a wipe of the underlying storage.
</dd>
<dt>Method</dt>
<dd>POST</dd>
<dt>URL</dt>
<dd>`/sys/repliation/primary/disable`</dd>
<dt>Parameters</dt>
<dd>
None
</dd>
<dt>Returns</dt>
<dd>
`200` response code with a warning..
</dd>
</dl>
# /sys/replication/primary/secondary-token
## GET
<dl>
<dt>Description</dt>
<dd>
Requires sudo capability. Generate a secondary activation token for the
cluster with the given opaque identifier, which must be unique. This
identifier can later be used to revoke a secondary's access.
</dd>
<dt>Method</dt>
<dd>GET</dd>
<dt>URL</dt>
<dd>`/sys/replication/primary/secondary-token`</dd>
<dt>Parameters</dt>
<dd>
<ul>
<li>
<span class="param">id</span>
<span class="param-flags">required</span>
An opaque identifier, e.g. us-east
</li>
<li>
<span class="param">ttl</span>
<span class="param-flags">optional</span>
The TTL for the secondary activation token. Defaults to "30m".
</li>
</ul>
</dd>
<dt>Returns</dt>
<dd>
```javascript
{
"request_id": "",
"lease_id": "",
"lease_duration": 0,
"renewable": false,
"data": null,
"warnings": null,
"wrap_info": {
"token": "fb79b9d3-d94e-9eb6-4919-c559311133d6",
"ttl": 300,
"creation_time": "2016-09-28T14:41:00.56961496-04:00",
"wrapped_accessor": ""
}
}
```
</dd>
</dl>
# /sys/replication/primary/revoke-secondary
## POST
<dl>
<dt>Description</dt>
<dd>
Revoke a secondarys ability to connect to the primary cluster; the
secondary will immediately be disconnected and will not be allowed to
connect again unless given a new activation token.
</dd>
<dt>Method</dt>
<dd></dd>
<dt>URL</dt>
<dd>`/sys/replication/secondary/revoke-secondary`</dd>
<dt>Parameters</dt>
<dd>
<ul>
<li>
<span class="param">id</span>
<span class="param-flags">required</span>
The identifier used when fetching the secondary token.
</li>
</ul>
</dd>
<dt>Returns</dt>
<dd>
`200` response code with a warning.
</dd>
</dl>

View file

@ -1,197 +0,0 @@
---
layout: "http"
page_title: "HTTP API: /sys/replication/secondary"
sidebar_current: "docs-http-replication-secondary"
description: |-
The '/sys/replication/secondary' endpoint focuses on replication management operations on secondary clusters.
---
# /sys/replication/secondary/enable
## POST
<dl>
<dt>Description</dt>
<dd>
Enables replication on a secondary using a secondary activation token.
Caution: this will immediately clear all data in the cluster!
</dd>
<dt>Method</dt>
<dd></dd>
<dt>URL</dt>
<dd>`/sys/replication/secondary/enable`</dd>
<dt>Parameters</dt>
<dd>
<ul>
<li>
<span class="param">token</span>
<span class="param-flags">required</span>
The secondary activation token fetched from the primary.
</li>
<li>
<span class="param">primary_api_addr</span>
<span class="param-flags">optional</span>
Set this to the API address (normal Vault address) to override the
value embedded in the token. This can be useful if the primarys
redirect address is not accessible directly from this cluster (e.g.
through a load balancer).
</li>
<li>
<span class="param">ca_file</span>
<span class="param-flags">optional</span>
The path to a CA root file (PEM format) that the secondary can use when
unwrapping the token from the primary. If this and ca_path are not
given, defaults to system CA roots.
</li>
<li>
<span class="param">ca_path</span>
<span class="param-flags">optional</span>
The path to a CA root directory containing PEM-format files that the
secondary can use when unwrapping the token from the primary. If this
and ca_file are not given, defaults to system CA roots.
</li>
</ul>
</dd>
<dt>Returns</dt>
<dd>
`200` response code and a warning.
</dd>
</dl>
# /sys/replication/secondary/promote
## POST
<dl>
<dt>Description</dt>
<dd>
Promotes the secondary cluster to primary. For data safety and security
reasons, new secondary tokens will need to be issued to other secondaries,
and there should never be more than one primary at a time.
</dd>
<dt>Method</dt>
<dd></dd>
<dt>URL</dt>
<dd>`/sys/replication/secondary/promote`</dd>
<dt>Parameters</dt>
<dd>
<ul>
<li>
<span class="param">primary_cluster_addr</span>
<span class="param-flags">optional</span>
Can be used to override the cluster address that the primary gives to
secondary nodes. Useful if the primarys cluster address is not
directly accessible and must be accessed via an alternate path/address
(e.g. through a load balancer).
</li>
</ul>
</dd>
<dt>Returns</dt>
<dd>
`200` response code and a warning.
</dd>
</dl>
# /sys/replication/secondary/disable
## POST
<dl>
<dt>Description</dt>
<dd>
Disable replication entirely on the cluster. The cluster will no longer be
able to connect to the primary.
Caution: re-enabling this node as a primary or secondary will change its
cluster ID; in the secondary case this means a wipe of the underlying
storage when connected to a primary, and in the primary case, secondaries
connecting back to the cluster (even if they have connected before) will
require a wipe of the underlying storage.
</dd>
<dt>Method</dt>
<dd></dd>
<dt>URL</dt>
<dd>`/sys/replication/secondary/disable`</dd>
<dt>Parameters</dt>
<dd>
None
</dd>
<dt>Returns</dt>
<dd>
`200` response code and a warning.
</dd>
</dl>
# /sys/replication/secondary/update-primary
## POST
<dl>
<dt>Description</dt>
<dd>
Change a secondary clusters assigned primary
cluster using a secondary activation token.
This does not wipe all data in the cluster.
</dd>
<dt>Method</dt>
<dd></dd>
<dt>URL</dt>
<dd>`/sys/replication/secondary/update-primary`</dd>
<dt>Parameters</dt>
<dd>
<ul>
<li>
<span class="param">token</span>
<span class="param-flags">required</span>
The secondary activation token fetched from the primary. If you set
this to a blank string, the cluster will stay a secondary but clear its
knowledge of any past primary (and thus not attempt to connect to the
previous primary). This can be useful if the primary is down to stop
the secondary from trying to reconnect to it.
</li>
<li>
<span class="param">primary_api_addr</span>
<span class="param-flags">optional</span>
Set this to the API address (normal Vault address) to override the
value embedded in the token. This can be useful if the primarys
redirect address is not accessible directly from this cluster.
</li>
<li>
<span class="param">ca_file</span>
<span class="param-flags">optional</span>
The path to a CA root file (PEM format) that the secondary can use when
unwrapping the token from the primary. If this and ca_path are not
given, defaults to system CA roots.
</li>
<li>
<span class="param">ca_path</span>
<span class="param-flags">optional</span>
The path to a CA root directory containing PEM-format files that the
secondary can use when unwrapping the token from the primary. If this
and ca_file are not given, defaults to system CA roots.
</li>
</ul>
</dd>
<dt>Returns</dt>
<dd>
`200` response code and a warning.
</dd>
</dl>

View file

@ -1,118 +0,0 @@
---
layout: "http"
page_title: "HTTP API: /sys/replication"
sidebar_current: "docs-http-replication"
description: |-
The '/sys/replication' endpoint focuses on managing general operations in Vault Enterprise replication sets
---
# /sys/replication/recover
## POST
<dl>
<dt>Description</dt>
<dd>
Attempts recovery if replication is in an adverse state. For example: an
error has caused replication to stop syncing.
</dd>
<dt>Method</dt>
<dd>POST</dd>
<dt>URL</dt>
<dd>`/sys/replication/recover`</dd>
<dt>Parameters</dt>
<dd>
None
</dd>
<dt>Returns</dt>
<dd>
A `200` response code and a warning.
</dd>
</dl>
# /sys/replication/reindex
## POST
<dl>
<dt>Description</dt>
<dd>
Requires sudo capability. Reindex the local data storage. This can cause
a very long delay depending on the number and size of objects in the data
store.
</dd>
<dt>Method</dt>
<dd>POST</dd>
<dt>URL</dt>
<dd>`/sys/replication/reindex`</dd>
<dt>Parameters</dt>
<dd>
None
</dd>
<dt>Returns</dt>
<dd>
A `200` response code and a warning.
</dd>
</dl>
# /sys/replication/status
## GET
<dl>
<dt>Description</dt>
<dd>
Unauthenticated. Print information about the status of replication (mode,
sync progress, etc).
</dd>
<dt>Method</dt>
<dd>GET</dd>
<dt>URL</dt>
<dd>`/sys/replication/status`</dd>
<dt>Parameters</dt>
<dd>
None
</dd>
<dt>Returns</dt>
<dd>
The printed status of the replication environment. As an example, for a
primary, it will look something like:
```javascript
{
"mode": "primary",
"cluster_id": "d4095d41-3aee-8791-c421-9bc7f88f7c3e",
"known_secondaries": [],
"last_wal": 0,
"merkle_root": "c3260c4c682ff2d6eb3c8bfd877134b3cec022d1",
"request_id": "009ea98c-06cd-6dc3-74f2-c4904b22e535",
"lease_id": "",
"renewable": false,
"lease_duration": 0,
"data": {
"cluster_id": "d4095d41-3aee-8791-c421-9bc7f88f7c3e",
"known_secondaries": [],
"last_wal": 0,
"merkle_root": "c3260c4c682ff2d6eb3c8bfd877134b3cec022d1",
"mode": "primary"
},
"wrap_info": null,
"warnings": null,
"auth": null
}
```
</dd>
</dl>

View file

@ -1,36 +0,0 @@
---
layout: "http"
page_title: "HTTP API: /sys/revoke-force"
sidebar_current: "docs-http-lease-revoke-force"
description: |-
The `/sys/revoke-force` endpoint is used to revoke secrets or tokens based on prefix while ignoring backend errors.
---
# /sys/revoke-force
<dl>
<dt>Description</dt>
<dd>
Revoke all secrets or tokens generated under a given prefix immediately.
Unlike `/sys/revoke-prefix`, this path ignores backend errors encountered
during revocation. This is <i>potentially very dangerous</i> and should
only be used in specific emergency situations where errors in the backend
or the connected backend service prevent normal revocation. <i>By ignoring
these errors, Vault abdicates responsibility for ensuring that the issued
credentials or secrets are properly revoked and/or cleaned up. Access to
this endpoint should be tightly controlled.</i>
</dd>
<dt>Method</dt>
<dd>PUT</dd>
<dt>URL</dt>
<dd>`/sys/revoke-force/<path prefix>`</dd>
<dt>Parameters</dt>
<dd>None</dd>
<dt>Returns</dt>
<dd>A `204` response code.
</dd>
</dl>

View file

@ -1,32 +0,0 @@
---
layout: "http"
page_title: "HTTP API: /sys/revoke-prefix"
sidebar_current: "docs-http-lease-revoke-prefix"
description: |-
The `/sys/revoke-prefix` endpoint is used to revoke secrets or tokens based on prefix.
---
# /sys/revoke-prefix
<dl>
<dt>Description</dt>
<dd>
Revoke all secrets (via a lease ID prefix) or tokens (via the tokens' path
property) generated under a given prefix immediately. This requires `sudo`
capability and access to it should be tightly controlled as it can be used
to revoke very large numbers of secrets/tokens at once.
</dd>
<dt>Method</dt>
<dd>PUT</dd>
<dt>URL</dt>
<dd>`/sys/revoke-prefix/<path prefix>`</dd>
<dt>Parameters</dt>
<dd>None</dd>
<dt>Returns</dt>
<dd>A `204` response code.
</dd>
</dl>

View file

@ -1,29 +0,0 @@
---
layout: "http"
page_title: "HTTP API: /sys/revoke"
sidebar_current: "docs-http-lease-revoke-single"
description: |-
The `/sys/revoke` endpoint is used to revoke secrets.
---
# /sys/revoke
<dl>
<dt>Description</dt>
<dd>
Revoke a secret immediately.
</dd>
<dt>Method</dt>
<dd>PUT</dd>
<dt>URL</dt>
<dd>`/sys/revoke/<lease id>`</dd>
<dt>Parameters</dt>
<dd>None</dd>
<dt>Returns</dt>
<dd>A `204` response code.
</dd>
</dl>

View file

@ -1,37 +0,0 @@
---
layout: "http"
page_title: "HTTP API: /sys/rotate"
sidebar_current: "docs-http-rotate-rotate"
description: |-
The `/sys/rotate` endpoint is used to rotate the encryption key.
---
# /sys/rotate
## PUT
<dl>
<dt>Description</dt>
<dd>
Trigger a rotation of the backend encryption key. This is the key that is used
to encrypt data written to the storage backend, and is not provided to operators.
This operation is done online. Future values are encrypted with the new key, while
old values are decrypted with previous encryption keys.
</dd>
<dt>Method</dt>
<dd>PUT</dd>
<dt>URL</dt>
<dd>`/sys/rotate`</dd>
<dt>Parameters</dt>
<dd>
None
</dd>
<dt>Returns</dt>
<dd>`204` response code.
</dd>
</dl>

View file

@ -1,54 +0,0 @@
---
layout: "http"
page_title: "HTTP API: /sys/seal-status"
sidebar_current: "docs-http-seal-status"
description: |-
The '/sys/seal-status' endpoint is used to check the seal status of a Vault.
---
# /sys/seal-status
<dl>
<dt>Description</dt>
<dd>
Returns the seal status of the Vault.<br/><br/>This is an unauthenticated endpoint.
</dd>
<dt>Method</dt>
<dd>GET</dd>
<dt>Parameters</dt>
<dd>
None
</dd>
<dt>Returns</dt>
<dd>
The "t" parameter is the threshold, and "n" is the number of shares.
```javascript
{
"sealed": true,
"t": 3,
"n": 5,
"progress": 2,
"version": "0.6.1-dev"
}
```
Sample response when Vault is unsealed.
```javascript
{
"sealed": false,
"t": 3,
"n": 5,
"progress": 0,
"version": "0.6.1-dev",
"cluster_name": "vault-cluster-d6ec3c7f",
"cluster_id": "3e8b3fec-3749-e056-ba41-b62a63b997e8"
}
```
</dd>
</dl>

View file

@ -1,30 +0,0 @@
---
layout: "http"
page_title: "HTTP API: /sys/seal"
sidebar_current: "docs-http-seal-seal"
description: |-
The '/sys/seal' endpoint seals the Vault.
---
# /sys/seal
<dl>
<dt>Description</dt>
<dd>
Seals the Vault. In HA mode, only an active node can be sealed. Standby
nodes should be restarted to get the same effect. Requires a token with
`root` policy or `sudo` capability on the path.
</dd>
<dt>Method</dt>
<dd>PUT</dd>
<dt>Parameters</dt>
<dd>
None
</dd>
<dt>Returns</dt>
<dd>A `204` response code.
</dd>
</dl>

View file

@ -1,33 +0,0 @@
---
layout: "http"
page_title: "HTTP API: /sys/step-down"
sidebar_current: "docs-http-ha-step-down"
description: |-
The '/sys/step-down' endpoint causes the node to give up active status.
---
# /sys/step-down
<dl>
<dt>Description</dt>
<dd>
Forces the node to give up active status. If the node does not have active
status, this endpoint does nothing. Note that the node will sleep for ten
seconds before attempting to grab the active lock again, but if no standby
nodes grab the active lock in the interim, the same node may become the
active node again. Requires a token with `root` policy or `sudo` capability
on the path.
</dd>
<dt>Method</dt>
<dd>PUT</dd>
<dt>Parameters</dt>
<dd>
None
</dd>
<dt>Returns</dt>
<dd>A `204` response code.
</dd>
</dl>

View file

@ -1,44 +0,0 @@
---
layout: "http"
page_title: "HTTP API: /sys/seal-unseal"
sidebar_current: "docs-http-seal-unseal"
description: |-
The '/sys/seal-unseal' endpoint is used to unseal the Vault.
---
# /sys/unseal
<dl>
<dt>Description</dt>
<dd>
Enter a single master key share to progress the unsealing of the Vault.
If the threshold number of master key shares is reached, Vault
will attempt to unseal the Vault. Otherwise, this API must be
called multiple times until that threshold is met.<br/><br/>Either
the `key` or `reset` parameter must be provided; if both are provided,
`reset` takes precedence.
</dd>
<dt>Method</dt>
<dd>PUT</dd>
<dt>Parameters</dt>
<dd>
<ul>
<li>
<span class="param">key</span>
<span class="param-flags">optional</span>
A single master share key.
</li>
<li>
<span class="param">reset</span>
<span class="param-flags">optional</span>
A boolean; if true, the previously-provided unseal keys are discarded
from memory and the unseal process is reset.
</li>
</ul>
</dd>
<dt>Returns</dt>
<dd>The same result as `/sys/seal-status`.
</dd>
</dl>

View file

@ -1,54 +0,0 @@
---
layout: "http"
page_title: "HTTP API: /sys/wrapping/lookup"
sidebar_current: "docs-http-wrapping-lookup"
description: |-
The '/sys/wrapping/lookup' endpoint returns wrapping token properties
---
# /sys/wrapping/lookup
## POST
<dl>
<dt>Description</dt>
<dd>
Looks up wrapping properties for the given token.
</dd>
<dt>Method</dt>
<dd>POST</dd>
<dt>URL</dt>
<dd>`/sys/wrapping/lookup`</dd>
<dt>Parameters</dt>
<dd>
<ul>
<li>
<span class="param">token</span>
<span class="param-flags">required</span>
The wrapping token ID.
</li>
</ul>
</dd>
<dt>Returns</dt>
<dd>
```javascript
{
"request_id": "481320f5-fdf8-885d-8050-65fa767fd19b",
"lease_id": "",
"lease_duration": 0,
"renewable": false,
"data": {
"creation_time": "2016-09-28T14:16:13.07103516-04:00",
"creation_ttl": 300
},
"warnings": null
}
```
</dd>
</dl>

View file

@ -1,60 +0,0 @@
---
layout: "http"
page_title: "HTTP API: /sys/wrapping/rewrap"
sidebar_current: "docs-http-wrapping-rewrap"
description: |-
The '/sys/wrapping/rewrap' endpoint can be used to rotate a wrapping token and refresh its TTL
---
# /sys/wrapping/rewrap
## POST
<dl>
<dt>Description</dt>
<dd>
Rewraps a response-wrapped token; the new token will use the same creation
TTL as the original token and contain the same response. The old token will
be invalidated. This can be used for long-term storage of a secret in a
response-wrapped token when rotation is a requirement.
</dd>
<dt>Method</dt>
<dd>POST</dd>
<dt>URL</dt>
<dd>`/sys/wrapping/rewrap`</dd>
<dt>Parameters</dt>
<dd>
<ul>
<li>
<span class="param">token</span>
<span class="param-flags">required</span>
The wrapping token ID.
</li>
</ul>
</dd>
<dt>Returns</dt>
<dd>
```javascript
{
"request_id": "",
"lease_id": "",
"lease_duration": 0,
"renewable": false,
"data": null,
"warnings": null,
"wrap_info": {
"token": "3b6f1193-0707-ac17-284d-e41032e74d1f",
"ttl": 300,
"creation_time": "2016-09-28T14:22:26.486186607-04:00",
"wrapped_accessor": ""
}
}
```
</dd>
</dl>

View file

@ -1,65 +0,0 @@
---
layout: "http"
page_title: "HTTP API: /sys/wrapping/unwrap"
sidebar_current: "docs-http-wrapping-unwrap"
description: |-
The '/sys/wrapping/unwrap' endpoint unwraps a wrapped response
---
# /sys/wrapping/unwrap
## POST
<dl>
<dt>Description</dt>
<dd>
Returns the original response inside the given wrapping token. Unlike
simply reading `cubbyhole/response` (which is deprecated), this endpoint
provides additional validation checks on the token, returns the original
value on the wire rather than a JSON string representation of it, and
ensures that the response is properly audit-logged.<br/><br/>This endpoint
can be used by using a wrapping token as the client token in the API call,
in which case the `token` parameter is not required; or, a different token
with permissions to access this endpoint can make the call and pass in the
wrapping token in the `token` parameter. Do _not_ use the wrapping token in
both locations; this will cause the wrapping token to be revoked but the
value to be unable to be looked up, as it will basically be a double-use of
the token!
</dd>
<dt>Method</dt>
<dd>POST</dd>
<dt>URL</dt>
<dd>`/sys/wrapping/unwrap`</dd>
<dt>Parameters</dt>
<dd>
<ul>
<li>
<span class="param">token</span>
<span class="param-flags">optional</span>
The wrapping token ID; required if the client token is not the wrapping
token. Do not use the wrapping token in both locations.
</li>
</ul>
</dd>
<dt>Returns</dt>
<dd>
```javascript
{
"request_id": "8e33c808-f86c-cff8-f30a-fbb3ac22c4a8",
"lease_id": "",
"lease_duration": 2592000,
"renewable": false,
"data": {
"zip": "zap"
},
"warnings": null
}
```
</dd>
</dl>

View file

@ -1,59 +0,0 @@
---
layout: "http"
page_title: "HTTP API: /sys/wrapping/wrap"
sidebar_current: "docs-http-wrapping-wrap"
description: |-
The '/sys/wrapping/wrap' endpoint wraps the given values in a response-wrapped token
---
# /sys/wrapping/wrap
## POST
<dl>
<dt>Description</dt>
<dd>
Wraps the given user-supplied data inside a response-wrapped token.
</dd>
<dt>Method</dt>
<dd>POST</dd>
<dt>URL</dt>
<dd>`/sys/wrapping/wrap`</dd>
<dt>Parameters</dt>
<dd>
<ul>
<li>
<span class="param">[any]</span>
<span class="param-flags">optional</span>
Parameters should be supplied as keys/values in a JSON object. The
exact set of given parameters will be contained in the wrapped
response.
</li>
</ul>
</dd>
<dt>Returns</dt>
<dd>
```javascript
{
"request_id": "",
"lease_id": "",
"lease_duration": 0,
"renewable": false,
"data": null,
"warnings": null,
"wrap_info": {
"token": "fb79b9d3-d94e-9eb6-4919-c559311133d6",
"ttl": 300,
"creation_time": "2016-09-28T14:41:00.56961496-04:00",
"wrapped_accessor": ""
}
}
```
</dd>
</dl>

View file

@ -0,0 +1,63 @@
---
layout: "http"
page_title: /sys/audit-hash - HTTP API"
sidebar_current: "docs-http-system-audit-hash"
description: |-
The `/sys/audit-hash` endpoint is used to hash data using an audit backend's
hash function and salt.
---
# `/sys/audit-hash`
The `/sys/audit-hash` endpoint is used to calculate the hash of the data used by
an audit backend's hash function and salt. This can be used to search audit logs
for a hashed value when the original value is known.
## Calculate Hash
This endpoint hashes the given input data with the specified audit backend's
hash function and salt. This endpoint can be used to discover whether a given
plaintext string (the `input` parameter) appears in the audit log in obfuscated
form.
The audit log records requests and responses. Since the Vault API is JSON-based,
any binary data returned from an API call (such as a DER-format certificate) is
base64-encoded by the Vault server in the response. As a result such information
should also be base64-encoded to supply into the `input` parameter.
| Method | Path | Produces |
| :------- | :---------------------- | :--------------------- |
| `POST` | `/sys/audit-hash/:path` | `204 (empty body)` |
### Parameters
- `path` `(string: <required>)`  Specifies the path of the audit backend to
generate hashes for. This is part of the request URL.
- `input` `(string: <required>)`  Specifies the input string to hash.
### Sample Payload
```json
{
"input": "my-secret-vault"
}
```
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request POST \
--data @payload.json \
https://vault.rocks/v1/sys/audit-hash/example-audit
```
### Sample Response
```json
{
"hash": "hmac-sha256:08ba35..."
}
```

View file

@ -0,0 +1,118 @@
---
layout: "http"
page_title: "/sys/audit - HTTP API"
sidebar_current: "docs-http-system-audit/"
description: |-
The `/sys/audit` endpoint is used to enable and disable audit backends.
---
# `/sys/audit`
The `/sys/audit` endpoint is used to list, mount, and unmount audit backends.
Audit backends must be enabled before use, and more than one backend may be
enabled at a time.
## List Mounted Audit Backends
This endpoint lists only the mounted audit backends (it does not list all
available audit backends).
- **`sudo` required**  This endpoint requires `sudo` capability in addition to
any path-specific capabilities.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `GET` | `/sys/audit` | `200 application/json` |
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
https://vault.rocks/v1/sys/audit
```
### Sample Response
```javascript
{
"file": {
"type": "file",
"description": "Store logs in a file",
"options": {
"path": "/var/log/vault.log"
}
}
}
```
## Mount Audit Backend
This endpoint mounts a new audit backend at the supplied path. The path can be a
single word name or a more complex, nested path.
- **`sudo` required**  This endpoint requires `sudo` capability in addition to
any path-specific capabilities.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `PUT` | `/sys/audit/:path` | `204 (empty body)` |
### Parameters
- `path` `(string: <required>)`  Specifies the path in which to mount the audit
backend. This is part of the request URL.
- `description` `(string: "")`  Specifies a human-friendly description of the
audit backend.
- `options` `(map<string|string>: nil)`  Specifies configuration options to
pass to the audit backend itself. This is dependent on the audit backend type.
- `type` `(string: <required>)`  Specifies the type of the audit backend.
### Sample Payload
```json
{
"type": "file",
"options": {
"path": "/var/log/vault/log"
}
}
```
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request PUT \
--data @payload.json \
https://vault.rocks/v1/sys/audit/example-audit
```
## Unmount Audit Backend
This endpoint un-mounts the audit backend at the given path.
- **`sudo` required**  This endpoint requires `sudo` capability in addition to
any path-specific capabilities.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `DELETE` | `/sys/audit/:path` | `204 (empty body)` |
### Parameters
- `path` `(string: <required>)`  Specifies the path of the audit backend to
delete. This is part of the request URL.
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request DELETE \
https://vault.rocks/v1/sys/audit/example-audit
```

View file

@ -0,0 +1,193 @@
---
layout: "http"
page_title: "/sys/auth - HTTP API"
sidebar_current: "docs-http-system-auth"
description: |-
The `/sys/auth` endpoint is used to manage auth backends in Vault.
---
# `/sys/auth`
The `/sys/auth` endpoint is used to list, create, update, and delete auth
backends. Auth backends convert user or machine-supplied information into a
token which can be used for all future requests.
## List Auth Backends
This endpoint lists all enabled auth backends.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `GET` | `/sys/auth` | `200 application/json` |
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
https://vault.rocks/v1/sys/auth
```
### Sample Response
```json
{
"github/": {
"type": "github",
"description": "GitHub auth"
},
"token/": {
"config": {
"default_lease_ttl": 0,
"max_lease_ttl": 0
},
"description": "token based credentials",
"type": "token"
}
}
```
## Mount Auth Backend
This endpoint enables a new auth backend. After mounting, the auth backend can
be accessed and configured via the auth path specified as part of the URL. This
auth path will be nested under the `auth` prefix.
For example, mounting the "foo" auth backend will make it accessible at
`/auth/foo`.
- **`sudo` required**  This endpoint requires `sudo` capability in addition to
any path-specific capabilities.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `POST` | `/sys/auth/:path` | `204 (empty body)` |
### Parameters
- `path` `(string: <required>)`  Specifies the path in which to mount the auth
backend. This is part of the request URL.
- `description` `(string: "")`  Specifies a human-friendly description of the
auth backend.
- `type` `(string: <required>)`  Specifies the name of the authentication
backend type, such as "github" or "token".
### Sample Payload
```json
{
"type": "github",
"description": "Login with GitHub"
}
```
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request POST \
--data @payload.json \
https://vault.rocks/v1/sys/auth/my-auth
```
## Unmount Auth Backend
This endpoint un-mounts the auth backend at the given auth path.
- **`sudo` required**  This endpoint requires `sudo` capability in addition to
any path-specific capabilities.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `DELETE` | `/sys/auth/:path` | `204 (empty body)` |
### Parameters
- `path` `(string: <required>)`  Specifies the path to unmount. This is part of
the request URL.
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request DELETE \
https://vault.rocks/v1/sys/auth/my-auth
```
## Read Auth Backend Tuning
This endpoint reads the given auth path's configuration. _This endpoint requires
`sudo` capability on the final path, but the same functionality can be achieved
without `sudo` via `sys/mounts/auth/[auth-path]/tune`._
- **`sudo` required**  This endpoint requires `sudo` capability in addition to
any path-specific capabilities.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `GET` | `/sys/auth/:path/tune` | `200 application/json` |
### Parameters
- `path` `(string: <required>)`  Specifies the path in which to tune.
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
https://vault.rocks/v1/sys/auth/my-auth/tune
```
### Sample Response
```json
{
"default_lease_ttl": 3600,
"max_lease_ttl": 7200
}
```
## Tune Auth Backend
Tune configuration parameters for a given auth path. _This endpoint
requires `sudo` capability on the final path, but the same functionality
can be achieved without `sudo` via `sys/mounts/auth/[auth-path]/tune`._
- **`sudo` required**  This endpoint requires `sudo` capability in addition to
any path-specific capabilities.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `POST` | `/sys/auth/:path/tune` | `204 (empty body)` |
### Parameters
- `default_lease_ttl` `(int: 0)` Specifies the default time-to-live. If set on
a specific auth path, this overrides the global default.
- `max_lease_ttl` `(int: 0)`  Specifies the maximum time-to-live. If set on a
specific auth path, this overrides the global default.
### Sample Payload
```json
{
"default_lease_ttl": 1800,
"max_lease_ttl": 86400
}
```
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request POST \
--data @payload.json \
https://vault.rocks/v1/sys/auth/my-auth/tune
```

View file

@ -0,0 +1,57 @@
---
layout: "http"
page_title: "/sys/capabilities-accessor - HTTP API"
sidebar_current: "docs-http-system-capabilities-accessor"
description: |-
The `/sys/capabilities-accessor` endpoint is used to fetch the capabilities of
the token associated with an accessor, on the given path.
---
# `/sys/capabilities-accessor`
The `/sys/capabilities-accessor` endpoint is used to fetch the capabilities of a
token associated with an accessor.
## Query Token Accessor Capabilities
This endpoint returns the capabilities of the token associated with an accessor,
for the given path.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `POST` | `/sys/capabilities-accessor` | `200 application/json` |
### Parameters
- `accessor` `(string: <required>)` Specifies the accessor of the token to
check.
- `path` `(string: <required>)` Specifies the path on which the token's
capabilities will be checked.
### Sample Payload
```json
{
"accessor": "abcd1234",
"path": "secret/foo"
}
```
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request POST \
--data payload.json \
https://vault.rocks/v1/sys/capabilities-accessor
```
### Sample Response
```json
{
"capabilities": ["read", "list"]
}
```

View file

@ -0,0 +1,54 @@
---
layout: "http"
page_title: "/sys/capabilities-self - HTTP API"
sidebar_current: "docs-http-system-capabilities-self"
description: |-
The `/sys/capabilities-self` endpoint is used to fetch the capabilities of
client token on a given path.
---
# `/sys/capabilities-self`
The `/sys/capabilities-self` endpoint is used to fetch the capabilities of a the
supplied token.
## Query Self Capabilities
This endpoint returns the capabilities of client token on the given path. The
client token is the Vault token with which this API call is made.
| Method | Path | Produces |
| :------- | :----------------------- | :--------------------- |
| `POST` | `/sys/capabilities-self` | `200 application/json` |
### Parameters
- `path` `(string: <required>)`  Specifies the path on which the client token's
capabilities will be checked.
### Sample Payload
```json
{
"path": "secret/foo"
}
```
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request POST \
--data payload.json \
https://vault.rocks/v1/sys/capabilities-self
```
### Sample Response
```json
{
"capabilities": ["read", "list"]
}
```

View file

@ -0,0 +1,56 @@
---
layout: "http"
page_title: "/sys/capabilities - HTTP API"
sidebar_current: "docs-http-system-capabilities/"
description: |-
The `/sys/capabilities` endpoint is used to fetch the capabilities of a token
on a given path.
---
# `/sys/capabilities`
The `/sys/capabilities` endpoint is used to fetch the capabilities of a token on
a given path.
## Query Token Capabilities
This endpoint returns the list of capabilities for a provided token.
| Method | Path | Produces |
| :------- | :------------------- | :--------------------- |
| `POST` | `/sys/capabilities` | `200 application/json` |
### Parameters
- `path` `(string: <required>)`  Specifies the path against which to check the
token's capabilities.
- `token` `(string: <required>)`  Specifies the token for which to check
capabilities.
### Sample Payload
```json
{
"path": "secret/foo",
"token": "abcd1234"
}
```
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request POST \
--data @payload.json \
https://vault.rocks/v1/sys/capabilities
```
### Sample Response
```json
{
"capabilities": ["read", "list"]
}
```

View file

@ -0,0 +1,130 @@
---
layout: "http"
page_title: "/sys/config/auditing - HTTP API"
sidebar_current: "docs-http-system-config-auditing"
description: |-
The `/sys/config/auditing` endpoint is used to configure auditing settings.
---
# `/sys/config/auditing/request-headers`
The `/sys/config/auditing` endpoint is used to configure auditing settings.
## Read All Audited Request Headers
This endpoint lists the request headers that are configured to be audited.
- **`sudo` required**  This endpoint requires `sudo` capability in addition to
any path-specific capabilities.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `GET` | `/sys/config/auditing/request-headers` | `200 application/json` |
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
https://vault.rocks/v1/sys/config/auditing/request-headers
```
### Sample Response
```json
{
"headers": {
"X-Forwarded-For": {
"hmac": true
}
}
}
```
## Read Single Audit Request Header
This endpoint lists the information for the given request header.
- **`sudo` required**  This endpoint requires `sudo` capability in addition to
any path-specific capabilities.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `POST` | `/sys/config/auditing/request-headers/:name` | `200 application/json` |
### Parameters
- `name` `(string: <required>)` Specifies the name of the request header to
query. This is specified as part of the URL.
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
https://vault.rocks/v1/sys/config/auditing/request-headers/my-header
```
### Sample Response
```json
{
"X-Forwarded-For": {
"hmac": true
}
}
```
## Create/Update Audit Request Header
This endpoint enables auditing of a header.
- **`sudo` required**  This endpoint requires `sudo` capability in addition to
any path-specific capabilities.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `PUT` | `/sys/config/auditing/request-headers/:name` | `204 (empty body)` |
### Parameters
- `hmac` `(bool: false)`  Specifies if this header's value should be HMAC'ed in
the audit logs.
### Sample Payload
```json
{
"hmac": true
}
```
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request PUT \
--data payload.json \
https://vault.rocks/v1/sys/config/auditing/request-headers/my-header
```
## Delete Audit Request Header
This endpoint disables auditing of the given request header.
- **`sudo` required**  This endpoint requires `sudo` capability in addition to
any path-specific capabilities.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `DELETE` | `/sys/config/auditing/request-headers/:name` | `204 (empty body)` |
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request DELETE \
https://vault.rocks/v1/sys/config/auditing/request-headers/my-header
```

View file

@ -0,0 +1,170 @@
---
layout: "http"
page_title: "/sys/generate-root - HTTP API"
sidebar_current: "docs-http-system-generate-root"
description: |-
The `/sys/generate-root/` endpoints are used to create a new root key for
Vault.
---
# `/sys/generate-root`
The `/sys/generate-root` endpoint is used to create a new root key for Vault.
## Read Root Generation Progress
This endpoint reads the configuration and process of the current root generation
attempt.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `GET` | `/sys/generate-root/attempt` | `200 application/json` |
### Sample Request
```
$ curl \
https://vault.rocks/v1/sys/generate-root/attempt
```
### Sample Response
```json
{
"started": true,
"nonce": "2dbd10f1-8528-6246-09e7-82b25b8aba63",
"progress": 1,
"required": 3,
"encoded_root_token": "",
"pgp_fingerprint": "",
"complete": false
}
```
If a root generation is started, `progress` is how many unseal keys have been
provided for this generation attempt, where `required` must be reached to
complete. The `nonce` for the current attempt and whether the attempt is
complete is also displayed. If a PGP key is being used to encrypt the final root
token, its fingerprint will be returned. Note that if an OTP is being used to
encode the final root token, it will never be returned.
## Start Root Token Generation
This endpoint initializes a new root generation attempt. Only a single root
generation attempt can take place at a time. One (and only one) of `otp` or
`pgp_key` are required.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `PUT` | `/sys/generate-root/attempt` | `200 application/json` |
### Parameters
- `otp` `(string: <required-unless-pgp>)`  Specifies a base64-encoded 16-byte
value. The raw bytes of the token will be XOR'd with this value before being
returned to the final unseal key provider.
- `pgp_key` `(string: <required-unless-otp>)` Specifies a base64-encoded PGP
public key. The raw bytes of the token will be encrypted with this value
before being returned to the final unseal key provider.
### Sample Payload
```json
{
"otp": "CB23=="
}
```
### Sample Request
```
$ curl \
--request PUT \
--data payload.json \
https://vault.rocks/v1/sys/generate-root/attempt
```
### Sample Response
```json
{
"started": true,
"nonce": "2dbd10f1-8528-6246-09e7-82b25b8aba63",
"progress": 1,
"required": 3,
"encoded_root_token": "",
"pgp_fingerprint": "816938b8a29146fbe245dd29e7cbaf8e011db793",
"complete": false
}
```
## Cancel Root Generation
This endpoint cancels any in-progress root generation attempt. This clears any
progress made. This must be called to change the OTP or PGP key being used.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `DELETE` | `/sys/generate-root/attempt` | `204 (empty body)` |
### Sample Request
```
$ curl \
--request DELETE \
https://vault.rocks/v1/sys/generate-root/attempt
```
## Provide Key Share to Generate Root
This endpoint is used to enter a single master key share to progress the root
generation attempt. If the threshold number of master key shares is reached,
Vault will complete the root generation and issue the new token. Otherwise,
this API must be called multiple times until that threshold is met. The attempt
nonce must be provided with each call.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `PUT` | `/sys/generate-root/update` | `200 application/json` |
### Parameters
- `key` `(string: <required>)` Specifies a single master key share.
- `nonce` `(string: <required>)`  Specifies the nonce of the attempt.
### Sample Payload
```json
{
"key": "acbd1234",
"nonce": "ad235",
}
```
### Sample Request
```
$ curl \
--request PUT \
--data payload.json \
https://vault.rocks/v1/sys/generate-root/update
```
### Sample Response
This returns a JSON-encoded object indicating the attempt nonce, and completion
status, and the encoded root token, if the attempt is complete.
```json
{
"started": true,
"nonce": "2dbd10f1-8528-6246-09e7-82b25b8aba63",
"progress": 3,
"required": 3,
"pgp_fingerprint": "",
"complete": true,
"encoded_root_token": "FPzkNBvwNDeFh4SmGA8c+w=="
}
```

View file

@ -0,0 +1,71 @@
---
layout: "http"
page_title: "/sys/health - HTTP API"
sidebar_current: "docs-http-system-health"
description: |-
The `/sys/health` endpoint is used to check the health status of Vault.
---
# `/sys/health`
The `/sys/health` endpoint is used to check the health status of Vault.
## Read Health Information
This endpoint returns the health status of Vault. This matches the semantics of
a Consul HTTP health check and provides a simple way to monitor the health of a
Vault instance.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `HEAD` | `/sys/health` | `000 (empty body)` |
| `GET` | `/sys/health` | `000 application/json` |
The default status codes are:
- `200` if initialized, unsealed, and active
- `429` if unsealed and standby
- `501` if not initialized
- `503` if sealed
### Parameters
- `standbyok` `(bool: false)` Specifies if being a standby should still return
the active status code instead of the standby status code. This is useful when
Vault is behind a non-configurable load balance that just wants a 200-level
response.
- `activecode` `(int: 200)`  Specifies the status code that should be returned
for an active node.
- `standbycode` `(int: 429)` Specifies the status code that should be returned
for a standby node.
- `sealedcode` `(int: 503)` Specifies the status code that should be returned
for a sealed node.
- `uninitcode` `(int: 501)` Specifies the status code that should be returned
for a uninitialized node.
### Sample Request
```
$ curl \
https://vault.rocks/v1/sys/health
```
### Sample Response
This response is only returned for a `GET` request.
```json
{
"cluster_id": "c9abceea-4f46-4dab-a688-5ce55f89e228",
"cluster_name": "vault-cluster-5515c810",
"version": "0.6.2",
"server_time_utc": 1469555798,
"standby": false,
"sealed": false,
"initialized": true
}
```

View file

@ -0,0 +1,17 @@
---
layout: "http"
page_title: "System Backend - HTTP API"
sidebar_current: "docs-http-system"
description: |-
The system backend is a default backend in Vault that is mounted at the `/sys`
endpoint. This endpoint cannot be unmounted or moved, and is used to configure
Vault and interact with many of Vault's internal features.
---
# System Backend
The system backend is a default backend in Vault that is mounted at the `/sys`
endpoint. This endpoint cannot be unmounted or moved, and is used to configure
Vault and interact with many of Vault's internal features.
For more information about a particular path, please click on it in the sidebar.

View file

@ -0,0 +1,112 @@
---
layout: "http"
page_title: "/sys/init - HTTP API"
sidebar_current: "docs-http-system-init"
description: |-
The `/sys/init` endpoint is used to initialize a new Vault.
---
# `/sys/init`
The `/sys/init` endpoint is used to initialize a new Vault.
## Read Initialization Status
This endpoint returns the initialization status of Vault.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `GET` | `/sys/init` | `200 application/json` |
### Sample Request
```
$ curl \
https://vault.rocks/v1/sys/init
```
### Sample Response
```json
{
"initialized": true
}
```
## Start Initialization
This endpoint initializes a new Vault. The Vault must not have been previously
initialized. The recovery options, as well as the stored shares option, are only
available when using Vault HSM.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `PUT` | `/sys/init` | `200 application/json` |
### Parameters
- `pgp_keys` `(array<string>: nil)` Specifies an array of PGP public keys used
to encrypt the output unseal keys. Ordering is preserved. The keys must be
base64-encoded from their original binary representation. The size of this
array must be the same as `secret_shares`.
- `root_token_pgp_key` `(string: "")`  Specifies a PGP public key used to
encrypt the initial root token. The key must be base64-encoded from its
original binary representation.
- `secret_shares` `(int: <required>)`  Specifies the number of shares to
split the master key into.
- `secret_threshold` `(int: <required>)`  Specifies the number of shares
required to reconstruct the master key. This must be less than or equal
`secret_shares`. If using Vault HSM with auto-unsealing, this value must be
the same as `secret_shares`.
Additionally, the following options are only supported on Vault Pro/Enterprise:
- `stored_shares` `(int: <required>)` Specifies the number of shares that
should be encrypted by the HSM and stored for auto-unsealing. Currently must
be the same as `secret_shares`.
- `recovery_shares` `(int: <required>)` Specifies rhe number of shares to
split the recovery key into.
- `recovery_threshold` `(int: <required>)`  Specifies rhe number of shares
required to reconstruct the recovery key. This must be less than or equal to
`recovery_shares`.
- `recovery_pgp_keys` `(array<string>: nil)` Specifies an array of PGP public
keys used to encrypt the output recovery keys. Ordering is preserved. The keys
must be base64-encoded from their original binary representation. The size of
this array must be the same as `recovery_shares`.
### Sample Payload
```json
{
"secret_shares": 10,
"secret_threshold": 5
}
```
### Sample Request
```
$ curl \
--request PUT \
--data payload.json \
https://vault.rocks/v1/sys/init
```
### Sample Response
A JSON-encoded object including the (possibly encrypted, if `pgp_keys` was
provided) master keys, base 64 encoded master keys and initial root token:
```json
{
"keys": ["one", "two", "three"],
"keys_base64": ["cR9No5cBC", "F3VLrkOo", "zIDSZNGv"],
"root_token": "foo"
}
```

View file

@ -0,0 +1,37 @@
---
layout: "http"
page_title: "/sys/key-status - HTTP API"
sidebar_current: "docs-http-system-key-status"
description: |-
The `/sys/key-status` endpoint is used to query info about the current
encryption key of Vault.
---
# `/sys/key-status`
The `/sys/key-status` endpoint is used to query info about the current
encryption key of Vault.
## Get Encryption Key Status
This endpoint returns information about the current encryption key used by
Vault.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `GET` | `/sys/key-status` | `200 application/json` |
### Sample Request
### Sample Response
```json
{
"term": 3,
"install_time": "2015-05-29T14:50:46.223692553-07:00"
}
```
The `term` parameter is the sequential key number, and `install_time` is the
time that encryption key was installed.

View file

@ -0,0 +1,39 @@
---
layout: "http"
page_title: "/sys/leader - HTTP API"
sidebar_current: "docs-http-system-leader"
description: |-
The `/sys/leader` endpoint is used to check the high availability status and
current leader of Vault.
---
# `/sys/leader`
The `/sys/leader` endpoint is used to check the high availability status and
current leader of Vault.
## Read Leader Status
This endpoint returns the high availability status and current leader instance
of Vault.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `GET` | `/sys/leader` | `200 application/json` |
### Sample Request
```
$ curl \
https://vault.rocks/v1/sys/leader
```
### Sample Response
```json
{
"ha_enabled": true,
"is_self": false,
"leader_address": "https://127.0.0.1:8200/"
}
```

View file

@ -0,0 +1,188 @@
---
layout: "http"
page_title: "/sys/mounts - HTTP API"
sidebar_current: "docs-http-system-mounts"
description: |-
The `/sys/mounts` endpoint is used manage secret backends in Vault.
---
# `/sys/mounts`
The `/sys/mounts` endpoint is used manage secret backends in Vault.
## List Mounted Secret Backends
This endpoints lists all the mounted secret backends.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `GET` | `/sys/mounts` | `200 application/json` |
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
https://vault.rocks/v1/sys/mounts
```
### Sample Response
```json
{
"aws": {
"type": "aws",
"description": "AWS keys",
"config": {
"default_lease_ttl": 0,
"max_lease_ttl": 0,
"force_no_cache": false
}
},
"sys": {
"type": "system",
"description": "system endpoint",
"config": {
"default_lease_ttl": 0,
"max_lease_ttl": 0,
"force_no_cache": false
}
}
}
```
`default_lease_ttl` or `max_lease_ttl` values of 0 mean that the system defaults
are used by this backend.
## Mount Secret Backend
This endpoint mounts a new secret backend at the given path.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `POST` | `/sys/mounts/:path` | `204 (empty body)` |
### Parameters
- `path` `(string: <required>)`  Specifies the path where the secret backend
will be mounted. This is specified as part of the URL.
- `type` `(string: <required>)` Specifies the type of the backend, such as
"aws".
- `description` `(string: "")`  Specifies the human-friendly description of the
mount.
- `config` `(map<string|string>: nil)`  Specifies configuration options for
this mount. This is an object with three possible values:
- `default_lease_ttl`
- `max_lease_ttl`
- `force_no_cache`
These control the default and maximum lease time-to-live, and force
disabling backend caching respectively. If set on a specific mount, this
overrides the global defaults.
### Sample Payload
```json
{
"type": "aws",
"config": {
"force_no_cache": true
}
}
```
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request POST \
--data payload.json \
https://vault.rocks/v1/sys/mounts/my-mount
```
## Unmount Secret Backend
This endpoint un-mounts the mount point specified in the URL.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `DELETE` | `/sys/mounts/:path` | `204 (empty body) ` |
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request DELETE \
https://vault.rocks/v1/sys/mounts/my-mount
```
## Read Mount Configuration
This endpoint reads the given mount's configuration. Unlike the `mounts`
endpoint, this will return the current time in seconds for each TTL, which may
be the system default or a mount-specific value.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `GET` | `/sys/mounts/:path/tune` | `200 application/json` |
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
https://vault.rocks/v1/sys/mounts/my-mount/tune
```
### Sample Response
```json
{
"default_lease_ttl": 3600,
"max_lease_ttl": 7200,
"force_no_cache": false
}
```
## Tune Mount Configuration
This endpoint tunes configuration parameters for a given mount point.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `POST` | `/sys/mounts/:path/tune` | `204 (empty body)` |
### Parameters
- `default_lease_ttl` `(int: 0)`  Specifies the default time-to-live. This
overrides the global default. A value of `0` is equivalent to the system
default TTL.
- `max_lease_ttl` `(int: 0)` Specifies the maximum time-to-live. This
overrides the global default. A value of `0` are equivalent and set to the
system max TTL.
### Sample Payload
```json
{
"default_lease_ttl": 1800,
"max_lease_ttl": 3600
}
```
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request POST \
--data payload.json \
https://vault.rocks/v1/sys/mounts/my-mount/tune
```

View file

@ -0,0 +1,121 @@
---
layout: "http"
page_title: "/sys/policy - HTTP API"
sidebar_current: "docs-http-system-policy"
description: |-
The `/sys/policy` endpoint is used to manage ACL policies in Vault.
---
# `/sys/policy`
The `/sys/policy` endpoint is used to manage ACL policies in Vault.
## List Policies
This endpoint lists all configured policies.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `GET` | `/sys/policy` | `200 application/json` |
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
https://vault.rocks/v1/sys/policy
```
### Sample Response
```json
{
"policies": ["root", "deploy"]
}
```
## Read Policy
This endpoint retrieve the rules for the named policy.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `GET` | `/sys/policy/:name` | `200 application/json` |
### Parameters
- `name` `(string: <required>)`  Specifies the name of the policy to retrieve.
This is specified as part of the request URL.
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
https://vault.rocks/v1/sys/policy/my-policy
```
### Sample Response
```json
{
"rules": "path \"secret/foo\" {..."
}
```
## Create/Update Policy
This endpoint adds a new or updates an existing policy. Once a policy is
updated, it takes effect immediately to all associated users.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `PUT` | `/sys/policy/:name` | `204 (empty body)` |
### Parameters
- `name` `(string: <required>)`  Specifies the name of the policy to create.
This is specified as part of the request URL.
- `rules` `(string: <required>)` - Specifies the policy document.
### Sample Payload
```json
{
"rules": "path \"secret/foo\" {..."
}
```
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request PUT \
--data payload.json \
https://vault.rocks/v1/sys/policy/my-policy
```
## Delete Policy
This endpoint deletes the policy with the given name. This will immediately
affect all users associated with this policy.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `DELETE` | `/sys/policy/:name` | `204 (empty body)` |
### Parameters
- `name` `(string: <required>)`  Specifies the name of the policy to delete.
This is specified as part of the request URL.
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request DELETE \
https://vault.rocks/v1/sys/policy/my-policy
```

View file

@ -0,0 +1,100 @@
---
layout: "http"
page_title: "/sys/raw - HTTP API"
sidebar_current: "docs-http-system-raw"
description: |-
The `/sys/raw` endpoint is access the raw underlying store in Vault.
---
# `/sys/raw`
The `/sys/raw` endpoint is access the raw underlying store in Vault.
## Read Raw
This endpoint reads the value of the key at the given path. This is the raw path
in the storage backend and not the logical path that is exposed via the mount
system.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `GET` | `/sys/raw/:path` | `200 application/json` |
### Parameters
- `path` `(string: <required>)`  Specifies the raw path in the storage backend.
This is specified as part of the URL.
### Sample Request
```
$ curl \
---header "X-Vault-Token: ..." \
https://vault.rocks/v1/sys/raw/secret/foo
```
### Sample Response
```json
{
"value": "{'foo':'bar'}"
}
```
## Create/Update Raw
This endpoint updates the value of the key at the given path. This is the raw
path in the storage backend and not the logical path that is exposed via the
mount system.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `PUT` | `/sys/raw/:path` | `204 (empty body)` |
### Parameters
- `path` `(string: <required>)`  Specifies the raw path in the storage backend.
This is specified as part of the URL.
- `value` `(string: <required>)` Specifies the value of the key.
### Sample Payload
```json
{
"value": "{\"foo\": \"bar\"}"
}
```
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request PUT \
--data @payload.json \
https://vault.rocks/v1/sys/raw/secret/foo
```
## Delete Raw
This endpoint deletes the key with given path. This is the raw path in the
storage backend and not the logical path that is exposed via the mount system.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `DELETE` | `/sys/raw/:path` | `204 (empty body)` |
### Parameters
- `path` `(string: <required>)`  Specifies the raw path in the storage backend.
This is specified as part of the URL.
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request DELETE \
https://vault.rocks/v1/sys/raw/secret/foo
```

View file

@ -0,0 +1,217 @@
---
layout: "http"
page_title: "/sys/rekey - HTTP API"
sidebar_current: "docs-http-system-rekey"
description: |-
The `/sys/rekey` endpoints are used to rekey the unseal keys for Vault.
---
# `/sys/rekey`
The `/sys/rekey` endpoints are used to rekey the unseal keys for Vault.
## Read Rekey Progress
This endpoint reads the configuration and progress of the current rekey attempt.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `GET` | `/sys/rekey/init` | `200 application/json` |
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
https://vault.rocks/v1/sys/rekey/init
```
### Sample Response
```json
{
"started": true,
"nonce": "2dbd10f1-8528-6246-09e7-82b25b8aba63",
"t": 3,
"n": 5,
"progress": 1,
"required": 3,
"pgp_fingerprints": ["abcd1234"],
"backup": true
}
```
If a rekey is started, then `n` is the new shares to generate and `t` is the
threshold required for the new shares. `progress` is how many unseal keys have
been provided for this rekey, where `required` must be reached to complete. The
`nonce` for the current rekey operation is also displayed. If PGP keys are being
used to encrypt the final shares, the key fingerprints and whether the final
keys will be backed up to physical storage will also be displayed.
## Start Rekey
This endpoint initializes a new rekey attempt. Only a single rekey attempt can
take place at a time, and changing the parameters of a rekey requires canceling
and starting a new rekey, which will also provide a new nonce.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `PUT` | `/sys/rekey/init` | `204 (empty body)` |
### Parameters
- `secret_shares` `(int: <required>)`  Specifies the number of shares to split
the master key into.
- `secret_threshold` `(int: <required>)`  Specifies the number of shares
required to reconstruct the master key. This must be less than or equal to
`secret_shares`.
- `pgp_keys` `(array<string>: nil)`  Specifies an array of PGP public keys used
to encrypt the output unseal keys. Ordering is preserved. The keys must be
base64-encoded from their original binary representation. The size of this
array must be the same as `secret_shares`.
- `backup` `(bool: false)`  Specifies if using PGP-encrypted keys, whether
Vault should also back them up to `core/unseal-keys-backup` in the physical
storage backend. These can then be retrieved and removed via the
`sys/rekey/backup` endpoint.
### Sample Payload
```json
{
"secret_shares": 10,
"secret_threshold": 5
}
```
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request PUT \
--data @payload.json \
https://vault.rocks/v1/sys/rekey/init
```
## Cancel Rekey
This endpoint cancels any in-progress rekey. This clears the rekey settings as
well as any progress made. This must be called to change the parameters of the
rekey.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `DELETE` | `/sys/rekey/init` | `204 (empty body)` |
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request DELETE \
https://vault.rocks/v1/sys/rekey/init
```
## Read Backup Key
This endpoint returns the backup copy of PGP-encrypted unseal keys. The returned
value is the nonce of the rekey operation and a map of PGP key fingerprint to
hex-encoded PGP-encrypted key.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `GET` | `/sys/rekey/backup` | `200 application/json` |
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
https://vault.rocks/v1/sys/rekey/backup
```
### Sample Response
```json
{
"nonce": "2dbd10f1-8528-6246-09e7-82b25b8aba63",
"keys": {
"abcd1234": "..."
}
}
```
## Delete Backup Key
This endpoint deletes the backup copy of PGP-encrypted unseal keys.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `DELETE` | `/sys/rekey/backup` | `204 (empty body)` |
### Sample Request
```
$ curl \
--header "X-Vault-Token" \
--request DELETE \
https://vault.rocks/v1/sys/rekey/backup
```
## Submit Key
This endpoint is used to enter a single master key share to progress the rekey
of the Vault. If the threshold number of master key shares is reached, Vault
will complete the rekey. Otherwise, this API must be called multiple times until
that threshold is met. The rekey nonce operation must be provided with each
call.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `PUT` | `/sys/rekey/update` | `200 application/json` |
### Parameters
- `key` `(string: <required>)`  Specifies a single master share key.
- `nonce` `(string: <required>)` Specifies the nonce of the rekey operation.
### Sample Payload
```json
{
"key": "abcd1234...",
"nonce": "AB32..."
}
```
### Sample Request
```
$ curl \
--header "X-Vault-Token" \
--request PUT \
--data @payload.json \
https://vault.rocks/v1/sys/rekey/update
```
### Sample Response
```json
{
"complete": true,
"keys": ["one", "two", "three"],
"nonce": "2dbd10f1-8528-6246-09e7-82b25b8aba63",
"pgp_fingerprints": ["abcd1234"],
"keys_base64": ["base64keyvalue"],
"backup": true
}
```
If the keys are PGP-encrypted, an array of key fingerprints will also be
provided (with the order in which the keys were used for encryption) along with
whether or not the keys were backed up to physical storage.

View file

@ -0,0 +1,44 @@
---
layout: "http"
page_title: "/sys/remount - HTTP API"
sidebar_current: "docs-http-system-remount"
description: |-
The '/sys/remount' endpoint is used remount a mounted backend to a new endpoint.
---
# `/sys/remount`
The `/sys/remount` endpoint is used remount a mounted backend to a new endpoint.
## Remount Backend
This endpoint remounts an already-mounted backend to a new mount point.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `POST` | `/sys/remount` | `204 (empty body)` |
### Parameters
- `from` `(string: <required>)`  Specifies the previous mount point.
- `to` `(string: <required>)`  Specifies the new destination mount point.
### Sample Payload
```json
{
"from": "secret",
"to": "new-secret"
}
```
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request POST \
--data @payload.json \
https://vault.rocks/v1/sys/remount
```

View file

@ -0,0 +1,68 @@
---
layout: "http"
page_title: "/sys/renew - HTTP API"
sidebar_current: "docs-http-system-renew"
description: |-
The `/sys/renew` endpoint is used to renew secrets.
---
# `/sys/renew`
The `/sys/renew` endpoint is used to renew secrets.
## Renew Secret
This endpoint renews a secret, requesting to extend the lease.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `PUT` | `/sys/renew/(:lease_id)` | `200 application/json` |
### Parameters
- `lease_id` `(string: <required>)`  Specifies the ID of the lease to extend.
This can be specified as part of the URL or as part of the request body.
- `increment` `(int: 0)`  Specifies the requested amount of time (in seconds)
to extend the lease.
### Sample Payload
```json
{
"lease_id": "postgresql/creds/readonly/abcd-1234...",
"increment": 1800
}
```
### Sample Request
With the `lease_id` as part of the URL:
```
$ curl \
--header "X-Vault-Token: ..." \
--request PUT \
--data @payload.json \
https://vault.rocks/v1/sys/renew/postgresql/creds/readonly/abcd-1234
```
With the `lease_id` in the request body:
```
$ curl \
--header "X-Vault-Token: ..." \
--request PUT \
--data @payload.json \
https://vault.rocks/v1/sys/renew
```
### Sample Response
```json
{
"lease_id": "aws/creds/deploy/e31b1145-ff27-e62c-cba2-934e9f0d1dbc",
"renewable": true,
"lease_duration": 2764790
}
```

View file

@ -0,0 +1,417 @@
---
layout: "http"
page_title: "/sys/replication - HTTP API"
sidebar_current: "docs-http-system-replication"
description: |-
The '/sys/replication' endpoint focuses on managing general operations in Vault Enterprise replication sets
---
# `/sys/replication`
~> **Enterprise Only**  This endpoint requires Vault Pro or Vault Enterprise.
## Attempt Recovery
This endpoint attempts recovery if replication is in an adverse state. For
example: an error has caused replication to stop syncing.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `POST` | `/sys/replication/recover` | `200 application/json` |
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request POST \
https://vault.rocks/v1/sys/replication/recover
```
### Sample Response
```json
{
"warnings": ["..."]
}
```
## Reindex Replication
This endpoint reindexes the local data storage. This can cause a very long delay
depending on the number and size of objects in the data store.
**This endpoint requires 'sudo' capability.**
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `POST` | `/sys/replication/reindex` | `200 application/json` |
```
$ curl \
--header "X-Vault-Token: ..." \
--request POST \
https://vault.rocks/v1/sys/replication/reindex
```
### Sample Response
```json
{
"warnings": ["..."]
}
```
## Check Status
This endpoint print information about the status of replication (mode,
sync progress, etc).
This is an authenticated endpoint.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `GET` | `/sys/replication/status` | `200 application/json` |
### Sample Request
```
$ curl \
https://vault.rocks/v1/sys/replication/status
```
### Sample Response
The printed status of the replication environment. As an example, for a
primary, it will look something like:
```json
{
"mode": "primary",
"cluster_id": "d4095d41-3aee-8791-c421-9bc7f88f7c3e",
"known_secondaries": [],
"last_wal": 0,
"merkle_root": "c3260c4c682ff2d6eb3c8bfd877134b3cec022d1",
"request_id": "009ea98c-06cd-6dc3-74f2-c4904b22e535",
"lease_id": "",
"renewable": false,
"lease_duration": 0,
"data": {
"cluster_id": "d4095d41-3aee-8791-c421-9bc7f88f7c3e",
"known_secondaries": [],
"last_wal": 0,
"merkle_root": "c3260c4c682ff2d6eb3c8bfd877134b3cec022d1",
"mode": "primary"
},
"wrap_info": null,
"warnings": null,
"auth": null
}
```
## Enable Primary Replication
This endpoint enables replication in primary mode. This is used when replication
is currently disabled on the cluster (if the cluster is already a secondary, it
must be promoted).
!> Only one primary should be active at a given time. Multiple primaries may
result in data loss!
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `POST` | `/sys/replication/primary/enable` | `204 (empty body)` |
### Parameters
- `primary_cluster_addr` `(string: "")` Specifies the cluster address that the
primary gives to secondary nodes. Useful if the primary's cluster address is
not directly accessible and must be accessed via an alternate path/address,
such as through a TCP-based load balancer.
### Sample Payload
```json
{}
```
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request POST \
--data @payload.json \
https://vault.rocks/v1/sys/replication/primary/enable
```
## Demote Primary
This endpoint demotes a primary cluster to a secondary. This secondary cluster
will not attempt to connect to a primary (see the update-primary call), but will
maintain knowledge of its cluster ID and can be reconnected to the same
replication set without wiping local storage.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `POST` | `/sys/replication/primary/demote` | `204 (empty body)` |
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request POST \
https://vault.rocks/v1/sys/replication/primary/demote
```
## Disable Primary
This endptoin disables replication entirely on the cluster. Any secondaries will
no longer be able to connect. Caution: re-enabling this node as a primary or
secondary will change its cluster ID; in the secondary case this means a wipe of
the underlying storage when connected to a primary, and in the primary case,
secondaries connecting back to the cluster (even if they have connected before)
will require a wipe of the underlying storage.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `POST` | `/sys/replication/primary/disable` | `204 (empty body)` |
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request POST \
https://vault.rocks/v1/sys/replication/primary/disable
```
## Generate Secondary Token
This endpoint generates a secondary activation token for the
cluster with the given opaque identifier, which must be unique. This
identifier can later be used to revoke a secondary's access.
**This endpoint requires 'sudo' capability.**
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `GET` | `/sys/replication/primary/secondary-token` | `200 application/json` |
### Parameters
- `id` `(string: <required>)`  Specifies an opaque identifier, e.g. 'us-east'
- `ttl` `(string: "30m")`  Specifies the TTL for the secondary activation
token.
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
https://vault.rocks/v1/sys/replication/primary/secondary-token?id=us-east-1
```
### Sample Response
```json
{
"request_id": "",
"lease_id": "",
"lease_duration": 0,
"renewable": false,
"data": null,
"warnings": null,
"wrap_info": {
"token": "fb79b9d3-d94e-9eb6-4919-c559311133d6",
"ttl": 300,
"creation_time": "2016-09-28T14:41:00.56961496-04:00",
"wrapped_accessor": ""
}
}
```
## Revoke Secondary Token
This endpoint revokes a secondary's ability to connect to the primary cluster;
the secondary will immediately be disconnected and will not be allowed to
connect again unless given a new activation token.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `POST` | `/sys/replication/secondary/revoke-secondary` | `204 (empty body)` |
### Parameters
- `id` `(string: <required>)`  Specifies an opaque identifier, e.g. 'us-east'
### Sample Payload
```json
{
"id": "us-east"
}
```
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request POST \
--data @payload.json \
https://vault.rocks/v1/sys/replication/secondary/revoke-secondary
```
## Enable Secondary
This endpoint enables replication on a secondary using a secondary activation
token.
!> This will immediately clear all data in the secondary cluster!
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `POST` | `/sys/replication/secondary/enable` | `204 (empty body)` |
### Parameters
- `token` `(string: <required>)` Specifies the secondary activation token fetched from the primary.
- `primary_api_addr` `(string: "")` Specifies Set this to the API address
(normal Vault address) to override the value embedded in the token. This can
be useful if the primary's redirect address is not accessible directly from
this cluster (e.g. through a load balancer).
- `ca_file` `(string: "")` Specifies the path to a CA root file (PEM format)
that the secondary can use when unwrapping the token from the primary. If this
and ca_path are not given, defaults to system CA roots.
- `ca_path` `(string: "")` Specifies the path to a CA root directory
containing PEM-format files that the secondary can use when unwrapping the
token from the primary. If this and ca_file are not given, defaults to system
CA roots.
### Sample Payload
```json
{
"token": "..."
}
```
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request POST \
--data @payload.json \
https://vault.rocks/v1/sys/replication/secondary/enable
```
## Promote Secondary
This endpoint promotes the secondary cluster to primary. For data safety and
security reasons, new secondary tokens will need to be issued to other
secondaries, and there should never be more than one primary at a time.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `POST` | `/sys/replication/secondary/promote` | `204 (empty body)` |
### Parameters
- `primary_cluster_addr` `(string: "")` Specifies the cluster address that the
primary gives to secondary nodes. Useful if the primary's cluster address is
not directly accessible and must be accessed via an alternate path/address
(e.g. through a load balancer).
### Sample Payload
```json
{}
```
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request POST \
--data @payload.json \
https://vault.rocks/v1/sys/replication/secondary/promote
```
## Disable Secondary
This endpoint disables replication entirely on the cluster. The cluster will no
longer be able to connect to the primary.
!> Re-enabling this node as a primary or secondary will change its cluster ID;
in the secondary case this means a wipe of the underlying storage when connected
to a primary, and in the primary case, secondaries connecting back to the
cluster (even if they have connected before) will require a wipe of the
underlying storage.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `POST` | `/sys/replication/secondary/disable` | `204 (empty body)` |
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request POST \
https://vault.rocks/v1/sys/replication/secondary/disable
```
## Update Secondary's Primary
This endpoint changes a secondary cluster's assigned primary cluster using a
secondary activation token. This does not wipe all data in the cluster.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `POST` | `/sys/replication/secondary/update-primary` | `204 (empty body)` |
### Parameters
- `token` `(string: <required>)`  Specifies the secondary activation token
fetched from the primary. If you set this to a blank string, the cluster will
stay a secondary but clear its knowledge of any past primary (and thus not
attempt to connect to the previous primary). This can be useful if the primary
is down to stop the secondary from trying to reconnect to it.
- `primary_api_addr` `(string: )`  Specifies the API address (normal Vault
address) to override the value embedded in the token. This can be useful if
the primary's redirect address is not accessible directly from this cluster.
- `ca_file` `(string: "")`  Specifies the path to a CA root file (PEM format)
that the secondary can use when unwrapping the token from the primary. If this
and ca_path are not given, defaults to system CA roots.
- `ca_path` `string: ()`  Specifies the path to a CA root directory containing
PEM-format files that the secondary can use when unwrapping the token from the
primary. If this and ca_file are not given, defaults to system CA roots.
### Sample Payload
```json
{
"token": "..."
}
```
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request POST \
--data @payload.json \
https://vault.rocks/v1/sys/replication/secondary/update-primary
```

View file

@ -0,0 +1,43 @@
---
layout: "http"
page_title: "/sys/revoke-force - HTTP API"
sidebar_current: "docs-http-system-revoke-force"
description: |-
The `/sys/revoke-force` endpoint is used to revoke secrets or tokens based on
prefix while ignoring backend errors.
---
# `/sys/revoke-force`
The `/sys/revoke-force` endpoint is used to revoke secrets or tokens based on
prefix while ignoring backend errors.
## Revoke Force
This endpoint revokes all secrets or tokens generated under a given prefix
immediately. Unlike `/sys/revoke-prefix`, this path ignores backend errors
encountered during revocation. This is _potentially very dangerous_ and should
only be used in specific emergency situations where errors in the backend or the
connected backend service prevent normal revocation.
By ignoring these errors, Vault abdicates responsibility for ensuring that the
issued credentials or secrets are properly revoked and/or cleaned up. Access to
this endpoint should be tightly controlled.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `PUT` | `/sys/revoke-force/:prefix` | `204 (empty body)` |
### Parameters
- `prefix` `(string: <required>)`  Specifies the prefix to revoke. This is
specified as part of the URL.
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request PUT \
https://vault.rocks/v1/sys/revoke-force/aws/creds
```

View file

@ -0,0 +1,38 @@
---
layout: "http"
page_title: "/sys/revoke-prefix - HTTP API"
sidebar_current: "docs-http-system-revoke-prefix"
description: |-
The `/sys/revoke-prefix` endpoint is used to revoke secrets or tokens based on
prefix.
---
# `/sys/revoke-prefix`
The `/sys/revoke-prefix` endpoint is used to revoke secrets or tokens based on
prefix.
## Revoke Prefix
This endpoint revokes all secrets (via a lease ID prefix) or tokens (via the
tokens' path property) generated under a given prefix immediately. This requires
`sudo` capability and access to it should be tightly controlled as it can be
used to revoke very large numbers of secrets/tokens at once.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
| `PUT` | `/sys/revoke-prefix/:prefix` | `204 (empty body)` |
### Parameters
- `prefix` `(string: <required>)`  Specifies the prefix to revoke. This is
specified as part of the URL.
### Sample Request
```
$ curl \
--header "X-Vault-Token: ..." \
--request PUT \
https://vault.rocks/v1/sys/revoke-prefix/aws/creds
```

Some files were not shown because too many files have changed in this diff Show more