diff --git a/.github/dependabot.yml b/.github/dependabot.yml new file mode 100644 index 0000000..fa3ed22 --- /dev/null +++ b/.github/dependabot.yml @@ -0,0 +1,12 @@ +# See GitHub's documentation for more information on this file: +# https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/configuration-options-for-dependency-updates +version: 2 +updates: + - package-ecosystem: "github-actions" + directory: "/" + schedule: + interval: "daily" + - package-ecosystem: "gomod" + directory: "/" + schedule: + interval: "daily" \ No newline at end of file diff --git a/.github/images/kf_logo.png b/.github/images/kf_logo.png new file mode 100644 index 0000000..027e15e Binary files /dev/null and b/.github/images/kf_logo.png differ diff --git a/.github/workflows/keyfactor-starter-workflow.yml b/.github/workflows/keyfactor-starter-workflow.yml new file mode 100644 index 0000000..6d8de53 --- /dev/null +++ b/.github/workflows/keyfactor-starter-workflow.yml @@ -0,0 +1,19 @@ +name: Keyfactor Bootstrap Workflow + +on: + workflow_dispatch: + pull_request: + types: [opened, closed, synchronize, edited, reopened] + push: + create: + branches: + - 'release-*.*' + +jobs: + call-starter-workflow: + uses: keyfactor/actions/.github/workflows/starter.yml@v2 + secrets: + token: ${{ secrets.V2BUILDTOKEN}} + APPROVE_README_PUSH: ${{ secrets.APPROVE_README_PUSH}} + gpg_key: ${{ secrets.KF_GPG_PRIVATE_KEY }} + gpg_pass: ${{ secrets.KF_GPG_PASSPHRASE }} diff --git a/.gitignore b/.gitignore index bee9d51..d2536d7 100644 --- a/.gitignore +++ b/.gitignore @@ -1,4 +1,10 @@ .vs/* -vaultSecretsEngine-update.zip +*.zip vault/plugins/* +*.sh *.exe +keyfactor +Keyfactor Vault Secrets Engine Guide.docx +Makefile +sample_config.json +README.md diff --git a/.goreleaser.yml b/.goreleaser.yml new file mode 100644 index 0000000..af3b995 --- /dev/null +++ b/.goreleaser.yml @@ -0,0 +1,91 @@ +# Visit https://goreleaser.com for documentation on how to customize this +# behavior. +before: + hooks: + # this is just an example and not a requirement for provider building/publishing + - go mod tidy +builds: + - env: + # goreleaser does not work with CGO, it could also complicate + # usage by users in CI/CD systems like Terraform Cloud where + # they are unable to install libraries. + - CGO_ENABLED=0 + mod_timestamp: '{{ .CommitTimestamp }}' + flags: + - -trimpath + ldflags: + - '-s -w -X main.version={{.Version}} -X main.commit={{.Commit}}' + goos: + - freebsd + - windows + - linux + - darwin + goarch: + - amd64 + - '386' + - arm + - arm64 + ignore: + - goos: darwin + goarch: '386' + - goos: freebsd + goarch: 'arm64' + binary: 'keyfactor' + id: "keyfactor" + main: './cmd/keyfactor' + hooks: + pre: + - cmd: sh -c "echo $(echo -n {{.Target}}; echo -n ' '; sha256sum {{.Name}}) >> ${ env.BUILD_ARTIFACT_DIR }/vault_binary_checksums.txt" +archives: + - format: zip + name_template: '{{ .ProjectName }}_{{ .Version }}_{{ .Os }}_{{ .Arch }}' +checksum: + name_template: '{{ .ProjectName }}.{{ .Version }}.sha256' + algorithm: sha256 +signs: + - artifacts: checksum + args: + # if you are using this in a GitHub action or some other automated pipeline, you + # need to pass the batch flag to indicate its not interactive. + - "--batch" + - "--local-user" + - "{{ .Env.GPG_FINGERPRINT }}" # set this environment variable for your signing key + - "--output" + - "${signature}" + - "--detach-sign" + - "${artifact}" +release: + prerelease: auto + extra_files: + - glob: 'installation.txt' + - glob: 'LICENSE.txt' + - glob: '${ env.BUILD_ARTIFACT_DIR }/vault_binary_checksums.txt' + # If you want to manually examine the release before its live, uncomment this line: + draft: true +changelog: + sort: asc + use: github + filters: + exclude: + - '^test:' + - '^chore' + - 'merge conflict' + - Merge pull request + - Merge remote-tracking branch + - Merge branch + - go mod tidy + groups: + - title: Dependency updates + regexp: "^.*(feat|fix)\\(deps\\)*:+.*$" + order: 300 + - title: 'New Features' + regexp: "^.*feat[(\\w)]*:+.*$" + order: 100 + - title: 'Bug fixes' + regexp: "^.*fix[(\\w)]*:+.*$" + order: 200 + - title: 'Documentation updates' + regexp: "^.*docs[(\\w)]*:+.*$" + order: 400 + - title: Other work + order: 9999 diff --git a/.vscode/settings.json b/.vscode/settings.json new file mode 100644 index 0000000..05e6a94 --- /dev/null +++ b/.vscode/settings.json @@ -0,0 +1,5 @@ +{ + "files.associations": { + "*.yaml": "home-assistant" + } +} \ No newline at end of file diff --git a/CHANGELOG.md b/CHANGELOG.md new file mode 100644 index 0000000..73c02f7 --- /dev/null +++ b/CHANGELOG.md @@ -0,0 +1,18 @@ +- 1.3.1 + - Fix for issue where plugin was not enforcing plugin-side role limitations for AllowedDomains and AllowSubDomains, and was relying exclusively on the certificate template for these values. + +- 1.3.0 + - Fix for double encoding certificates when viewed in the terminal. + +- 1.2.0 + - Updated the plugin to use it's own internal configuration settings storage per instance. + +- 1.1.0 + - added subject parameters to certificate enrollment + - now defaulting to role values for subject parameters if not provided. + +- 1.0.1 + - This release fixes a bug where the CA logical name was not being URL encoded before sending the request to Keyfactor. + +- 1.00 + - initial release diff --git a/Keyfactor Vault Secrets Engine Guide.docx b/Keyfactor Vault Secrets Engine Guide.docx deleted file mode 100644 index 6b615d4..0000000 Binary files a/Keyfactor Vault Secrets Engine Guide.docx and /dev/null differ diff --git a/LICENSE.txt b/LICENSE.txt new file mode 100644 index 0000000..52b7995 --- /dev/null +++ b/LICENSE.txt @@ -0,0 +1,6 @@ +Copyright 2024 Keyfactor +Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. +You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 +Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, +WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions +and limitations under the License. \ No newline at end of file diff --git a/Makefile b/Makefile index 906dd94..da59968 100644 --- a/Makefile +++ b/Makefile @@ -1,3 +1,6 @@ +BINARY = "keyfactor" +VERSION = "v1.3.1" + GOARCH = amd64 UNAME = $(shell uname -s) @@ -31,4 +34,20 @@ clean: fmt: go fmt $$(go list ./...) + +release: + GOOS=darwin GOARCH=amd64 go build -o ./bin/${BINARY}_${VERSION}_darwin_amd64 + GOOS=freebsd GOARCH=386 go build -o ./bin/${BINARY}_${VERSION}_freebsd_386 + GOOS=freebsd GOARCH=amd64 go build -o ./bin/${BINARY}_${VERSION}_freebsd_amd64 + GOOS=freebsd GOARCH=arm go build -o ./bin/${BINARY}_${VERSION}_freebsd_arm + GOOS=linux GOARCH=386 go build -o ./bin/${BINARY}_${VERSION}_linux_386 + GOOS=linux GOARCH=amd64 go build -o ./bin/${BINARY}_${VERSION}_linux_amd64 + GOOS=linux GOARCH=arm go build -o ./bin/${BINARY}_${VERSION}_linux_arm + GOOS=openbsd GOARCH=386 go build -o ./bin/${BINARY}_${VERSION}_openbsd_386 + GOOS=openbsd GOARCH=amd64 go build -o ./bin/${BINARY}_${VERSION}_openbsd_amd64 + GOOS=solaris GOARCH=amd64 go build -o ./bin/${BINARY}_${VERSION}_solaris_amd64 + GOOS=windows GOARCH=386 go build -o ./bin/${BINARY}_${VERSION}_windows_386 + GOOS=windows GOARCH=amd64 go build -o ./bin/${BINARY}_${VERSION}_windows_amd64 + + .PHONY: build clean fmt start enable \ No newline at end of file diff --git a/README.md b/README.md index a3e5a5f..bb4a674 100644 --- a/README.md +++ b/README.md @@ -1,3 +1,27 @@ + +# keyfactor-vault-secrets-engine + +A Vault plugin that allows Vault to use Keyfactor Command as a CA and issue certificates. + +#### Integration status: Production - Ready for use in production environments. + +## About the Keyfactor API Client + +This API client allows for programmatic management of Keyfactor resources. + +## Support for keyfactor-vault-secrets-engine + +keyfactor-vault-secrets-engine is open source and community supported, meaning that there is no support guaranteed from Keyfactor Support for these tools. + +###### To report a problem or suggest a new feature, use the **[Issues](../../issues)** tab. If you want to contribute actual bug fixes or proposed enhancements, use the **[Pull requests](../../pulls)** tab. + +--- + + +--- + + + # Hashicorp Vault Secrets Engine Keyfactor enables DevOps teams to get seamless access to trusted internal and public certificates via native Vault API @@ -28,8 +52,8 @@ certificate authority. After issuance, the certificate is then returned to Hashi - [Check the Vault server status](#check-the-vault-server-status) - [Install and register the plugin](#install-and-register-the-plugin) - [Configure the plugin](#configure-the-plugin) -- [Using the plugin](#using-the-plugin) - [Adding Roles](#adding-roles) +- [Using the plugin](#using-the-plugin) - [Issuing Certificates](#issuing-certificates) - [Viewing Certificates](#viewing-certificates) - [Command Reference](#plugin-command-reference) @@ -66,6 +90,22 @@ Keyfactor Command can provide the control and visibility needed for a Vault envi !["high-level-architecture"](images/arch-diagram.png) +> [!IMPORTANT] +> The Keyfactor Vault Secrets Engine is designed to be a drop in replacement for the native +> Vault CA, and implements most of the functionality provided by the PKI secrets engine +> to enable enterprise grade certificate management for certificates requested via +> Vault. There are some important security differences when using the Keyfactor plugin, +> namely in how certificate issuance polices are enforced. The plugin only supports domain +> and subdomain restrictive role polices and defers to the Command infrastructure for it's +> issuance security model based on certificate templates. The only role parameters utilized +> by this secrets engine are "AllowedDomains" and "AllowSubDomains". Other parameters +> utilized by the Vault native PKI secrets engine, such as "TTL", "KeyType", "AllowIPSANs", +> etc. For reference, the full list of fields supported by the Vault PKI secrets engine can +> be found [here](https://developer.hashicorp.com/vault/api-docs/secret/pki#list-roles). +> When architecting a solution, consideration should be given to the +> native Vault policies, the roles implemented by the secrets engine plugin, and the template +> rules available in Command. + ## Compatibility This Vault Plugin has been tested against Hashicorp Vault version 1.10+ and the Keyfactor Platform 9.6+. We provide several pre-built binary files that correspond to various operating systems and processor architectures. If not building the plugin from source code, select the os/architecture combination that corresponds to your environment. @@ -79,18 +119,18 @@ document. ### Keyfactor Requirements - - A functional instance of Keyfactor Command - - An administrative user account to be used for configuring the Keyfactor options needed for the implementation - - A functional integrated certificate authority to be used for issuing the certificates - - A certificate template (or templates) defined to use for certificate issuance. - - A user account with permissions to connect to the Keyfactor API and submit certificate requests. This user account will require READ and ENROLL permissions on the certificate template that you will use for the Vault plugin. +- A functional instance of Keyfactor Command +- An administrative user account to be used for configuring the Keyfactor options needed for the implementation +- A functional integrated certificate authority to be used for issuing the certificates +- A certificate template (or templates) defined to use for certificate issuance. +- A user account with permissions to connect to the Keyfactor API and submit certificate requests. This user account will require READ and ENROLL permissions on the certificate template that you will use for the Vault plugin. ### Hashicorp Vault Requirements - - A functional Hashicorp Vault Installation **version 1.10.xx or greater**. - - An administrative account with permission to login to the Hashicorp Vault server in order to make administrative changes. - - An adequate number of unseal keys to meet the minimum criteria to unseal the Hashicorp Vault - - A Hashicorp Vault login token +- A functional Hashicorp Vault Installation **version 1.10.xx or greater**. +- An administrative account with permission to login to the Hashicorp Vault server in order to make administrative changes. +- An adequate number of unseal keys to meet the minimum criteria to unseal the Hashicorp Vault +- A Hashicorp Vault login token ## Installation - Keyfactor @@ -363,97 +403,103 @@ in order to view the configuration settings (see example below). !["configread"](images/configread.png) -## Using the plugin - ### Adding Roles - Hashicorp Vault supports being able to add roles to control certificate issuance policies such as allowed domains. To create a role, use the vault write command as in the below example. - `vault write keyfactor/roles/hashiwebserver allowed_domains=kftrain.lab allow_subdomains=true` +Hashicorp Vault supports being able to add roles to control certificate issuance policies for allowed domains and allowing sub-domain certificates to be created. +To create a role, use the vault write command as in the below example. + +`vault write keyfactor/roles/hashiwebserver allowed_domains=kftrain.lab allow_subdomains=true` + +This will create a role called "hashiwebserver" that can be used to generate certificates for domains ending with "kftrain.lab". + +These properties can also be set in the certificate template. If they differ, the most restrictive setting is applied. + +## Using the plugin ### Issuing Certificates - When requesting a certificate using the Keyfactor plugin, the command is the same as if you were issuing the certificate through the vault integrated PKI. As a part of the write command you will specify the role name you would like to use, as well as the common name on the certificate. A typical certificate issuance command is listed below for the hashiwebserver role, and a CN of foo.kftrain.lab on the certificate. +When requesting a certificate using the Keyfactor plugin, the command is the same as if you were issuing the certificate through the vault integrated PKI. As a part of the write command you will specify the role name you would like to use, as well as the common name on the certificate. A typical certificate issuance command is listed below for the hashiwebserver role, and a CN of foo.kftrain.lab on the certificate. - `vault write keyfactor/issue/hashiwebserver common_name=foo.kftrain.lab dns_sans=foo.kftrain.lab` +`vault write keyfactor/issue/hashiwebserver common_name=foo.kftrain.lab dns_sans=foo.kftrain.lab` - The resulting response will show the certificate data response for the request. This certificate will also be stored in the Vault secrets store. +The resulting response will show the certificate data response for the request. This certificate will also be stored in the Vault secrets store. !["vault3"](images/vault3.png) ### Viewing Certificates - After certificates are stored in the secrets store, you can then retrieve those certificates at a later time if necessary. To list the certificates that exist within the Vault store, use the LIST option with vault. The only parameter that you need to include is the secrets store name for the store that you would like to read. The system will then return a list of all of the serial numbers for certificates that are present in that secrets store. - - `vault list keyfactor/certs` - - The results of the command will be a list of serial numbers for the certificates in that store location: - - ``` - Keys - ---- - 750000276546d818cbe70231b6000000002765 - 750000276623facfaddb6c4ca1000000002766 - ``` - - If you would like to retrieve a specific certificate from the store, you can do so by using the "vault read" command, and specifying the serial number of the certificate that you would like returned. The format for the command looks like this: - - `vault read keyfactor/cert/` - - example: - - `vault read keyfactor/cert/750000276546d818cbe70231b6000000002765` - - The response will show the value for that certificate. - - ``` - Key Value - --- ----- - certificate -----BEGIN CERTIFICATE----- - LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tDQpNSUlGZXpDQ0JHT2dBd0lCQWdJ - VGRRQUFKMlZHMkJqTDV3SXh0Z0FBQUFBblpUQU5CZ2txaGtpRzl3MEJBUXNGDQpB - REJQTVJNd0VRWUtDWkltaVpQeUxHUUJHUllEYkdGaU1Sa3dGd1lLQ1pJbWlaUHlM - R1FCR1JZSmEyVjVabUZqDQpkRzl5TVIwd0d3WURWUVFERXhSclpYbG1ZV04wYjNJ - dFMwWlVVa0ZKVGkxRFFUQWVGdzB5TWpBME1qSXhOVE0xDQpNVGxhRncweU1qQTNN - akV4TlRNMU1UbGFNQm94R0RBV0JnTlZCQU1URDNWMWRTNXJablJ5WVdsdUxteGhZ - akNDDQpBU0l3RFFZSktvWklodmNOQVFFQkJRQURnZ0VQQURDQ0FRb0NnZ0VCQU9h - MmEwQzVoeWpvUHRWbWNqUGRVZlhuDQpKU3BvbkRyQ1dJT1ROcmxTcytkbWM3aFNw - SjdTanZvcCtSZUIrRFVQWWhXbFBETWZlOGFFSEkyUFAwMGg3dVd3DQpBaHJ6T2Jk - MmthUkhyOXZDU2h6dE1vYjBQd0JrTG9MK2JLUWRIK2xTM1RVMHpKQytidUV0WWJ3 - dHcvOGJSdFNFDQpIRWJaMXNrU1Y5RmJzWlBjb3I2WTVqcFV0ck85Y1dhbUs3d0Jw - dkFnVHEzYk44ZWt5ZUl4R1V6YVhjRHd2aEVnDQoxcG5xS1loY3NmOU03b2R1Ullv - Uytpcy9BTmlXZllSMDZBV29odE41VHlJVXBlcnVIZEh6WWpBYXJ4RXhzWEFrDQpR - d3BxVGF5dTFNUWU1cllYdWpyL1FEOG5EbGl5TXp6NjJINmNjRkRmWmhHNWZkVUJK - K25uRTlTbllabDRCcmNDDQpBd0VBQWFPQ0FvTXdnZ0ovTUJvR0ExVWRFUVFUTUJH - Q0QzVjFkUzVyWm5SeVlXbHVMbXhoWWpBZEJnTlZIUTRFDQpGZ1FVS0E0VkFhS3M5 - a2RjL3VXQXR3Sm5TSUJleVM4d0h3WURWUjBqQkJnd0ZvQVVjQlV6UFc3WlF1cVVN - UDNSDQpGVENiRFUxaFRHVXdnZFFHQTFVZEh3U0J6RENCeVRDQnhxQ0J3NkNCd0lh - QnZXeGtZWEE2THk4dlEwNDlhMlY1DQpabUZqZEc5eUxVdEdWRkpCU1U0dFEwRXNR - MDQ5UzBaVWNtRnBiaXhEVGoxRFJGQXNRMDQ5VUhWaWJHbGpKVEl3DQpTMlY1SlRJ - d1UyVnlkbWxqWlhNc1EwNDlVMlZ5ZG1salpYTXNRMDQ5UTI5dVptbG5kWEpoZEds - dmJpeEVRejFyDQpaWGxtWVdOMGIzSXNSRU05YkdGaVAyTmxjblJwWm1sallYUmxV - bVYyYjJOaGRHbHZia3hwYzNRL1ltRnpaVDl2DQpZbXBsWTNSRGJHRnpjejFqVWt4 - RWFYTjBjbWxpZFhScGIyNVFiMmx1ZERDQnlBWUlLd1lCQlFVSEFRRUVnYnN3DQpn - Ymd3Z2JVR0NDc0dBUVVGQnpBQ2hvR29iR1JoY0Rvdkx5OURUajFyWlhsbVlXTjBi - M0l0UzBaVVVrRkpUaTFEDQpRU3hEVGoxQlNVRXNRMDQ5VUhWaWJHbGpKVEl3UzJW - NUpUSXdVMlZ5ZG1salpYTXNRMDQ5VTJWeWRtbGpaWE1zDQpRMDQ5UTI5dVptbG5k - WEpoZEdsdmJpeEVRejFyWlhsbVlXTjBiM0lzUkVNOWJHRmlQMk5CUTJWeWRHbG1h - V05oDQpkR1UvWW1GelpUOXZZbXBsWTNSRGJHRnpjejFqWlhKMGFXWnBZMkYwYVc5 - dVFYVjBhRzl5YVhSNU1BNEdBMVVkDQpEd0VCL3dRRUF3SUZvREE5QmdrckJnRUVB - WUkzRlFjRU1EQXVCaVlyQmdFRUFZSTNGUWlEbWVSL2d1aXhNNGZaDQptUStCcTkx - RWgrQzNLZ3VGc3F4YmhyVFlWUUlCWkFJQkNUQVRCZ05WSFNVRUREQUtCZ2dyQmdF - RkJRY0RBVEFiDQpCZ2tyQmdFRUFZSTNGUW9FRGpBTU1Bb0dDQ3NHQVFVRkJ3TUJN - QTBHQ1NxR1NJYjNEUUVCQ3dVQUE0SUJBUUNBDQpqa1ZBTi9hL0NtVm5DTVV2RW1V - S0FuN1BhMFlpTmxxZVJwU2NIZ1dpYnZjc0NLM1Z1VTlSaENBdldpb1RBMytwDQpr - VXhYL0c4LzFlOXRlcWJnaElMZ2ZtemJuWndvZU1BTHo0aFZqYmtVYy83cGpaSVBr - ejA1cXRaT1ZSUzluaEVMDQpRM0xocEFtcmZXbzYxU0l3bHl3WEowV1YxU050UEtu - bUFvQUV2ZUIvSEpNSitkeTM1Q084Y2tOMFVidmk2OUhsDQoya1pIdE1LUWJsckk3 - ZXV2MHdnVERqWVIvdms3Yjl0UWlxSmE0YURvMnRsZmF2KzF4Tk40WVdxa3R2QUth - c3hsDQpBVW02bjdydVh5OEs4d005bEFVU2Rwb29iNzdQQ1lpTWhZRkF0ODUzQVlD - R1N0bU1nT21Pa0F1YVVEUHNET3pQDQplUXd1S25Hdy82WDJlUXltaU1BWQ0KLS0t - LS1FTkQgQ0VSVElGSUNBVEUtLS0tLQ0K - -----END CERTIFICATE----- - revocation_time 0 - ``` +After certificates are stored in the secrets store, you can then retrieve those certificates at a later time if necessary. To list the certificates that exist within the Vault store, use the LIST option with vault. The only parameter that you need to include is the secrets store name for the store that you would like to read. The system will then return a list of all of the serial numbers for certificates that are present in that secrets store. + +`vault list keyfactor/certs` + +The results of the command will be a list of serial numbers for the certificates in that store location: + +``` +Keys +---- +750000276546d818cbe70231b6000000002765 +750000276623facfaddb6c4ca1000000002766 +``` + +If you would like to retrieve a specific certificate from the store, you can do so by using the "vault read" command, and specifying the serial number of the certificate that you would like returned. The format for the command looks like this: + +`vault read keyfactor/cert/` + +example: + +`vault read keyfactor/cert/750000276546d818cbe70231b6000000002765` + +The response will show the value for that certificate. + +``` +Key Value +--- ----- +certificate -----BEGIN CERTIFICATE----- +LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tDQpNSUlGZXpDQ0JHT2dBd0lCQWdJ +VGRRQUFKMlZHMkJqTDV3SXh0Z0FBQUFBblpUQU5CZ2txaGtpRzl3MEJBUXNGDQpB +REJQTVJNd0VRWUtDWkltaVpQeUxHUUJHUllEYkdGaU1Sa3dGd1lLQ1pJbWlaUHlM +R1FCR1JZSmEyVjVabUZqDQpkRzl5TVIwd0d3WURWUVFERXhSclpYbG1ZV04wYjNJ +dFMwWlVVa0ZKVGkxRFFUQWVGdzB5TWpBME1qSXhOVE0xDQpNVGxhRncweU1qQTNN +akV4TlRNMU1UbGFNQm94R0RBV0JnTlZCQU1URDNWMWRTNXJablJ5WVdsdUxteGhZ +akNDDQpBU0l3RFFZSktvWklodmNOQVFFQkJRQURnZ0VQQURDQ0FRb0NnZ0VCQU9h +MmEwQzVoeWpvUHRWbWNqUGRVZlhuDQpKU3BvbkRyQ1dJT1ROcmxTcytkbWM3aFNw +SjdTanZvcCtSZUIrRFVQWWhXbFBETWZlOGFFSEkyUFAwMGg3dVd3DQpBaHJ6T2Jk +MmthUkhyOXZDU2h6dE1vYjBQd0JrTG9MK2JLUWRIK2xTM1RVMHpKQytidUV0WWJ3 +dHcvOGJSdFNFDQpIRWJaMXNrU1Y5RmJzWlBjb3I2WTVqcFV0ck85Y1dhbUs3d0Jw +dkFnVHEzYk44ZWt5ZUl4R1V6YVhjRHd2aEVnDQoxcG5xS1loY3NmOU03b2R1Ullv +Uytpcy9BTmlXZllSMDZBV29odE41VHlJVXBlcnVIZEh6WWpBYXJ4RXhzWEFrDQpR +d3BxVGF5dTFNUWU1cllYdWpyL1FEOG5EbGl5TXp6NjJINmNjRkRmWmhHNWZkVUJK +K25uRTlTbllabDRCcmNDDQpBd0VBQWFPQ0FvTXdnZ0ovTUJvR0ExVWRFUVFUTUJH +Q0QzVjFkUzVyWm5SeVlXbHVMbXhoWWpBZEJnTlZIUTRFDQpGZ1FVS0E0VkFhS3M5 +a2RjL3VXQXR3Sm5TSUJleVM4d0h3WURWUjBqQkJnd0ZvQVVjQlV6UFc3WlF1cVVN +UDNSDQpGVENiRFUxaFRHVXdnZFFHQTFVZEh3U0J6RENCeVRDQnhxQ0J3NkNCd0lh +QnZXeGtZWEE2THk4dlEwNDlhMlY1DQpabUZqZEc5eUxVdEdWRkpCU1U0dFEwRXNR +MDQ5UzBaVWNtRnBiaXhEVGoxRFJGQXNRMDQ5VUhWaWJHbGpKVEl3DQpTMlY1SlRJ +d1UyVnlkbWxqWlhNc1EwNDlVMlZ5ZG1salpYTXNRMDQ5UTI5dVptbG5kWEpoZEds +dmJpeEVRejFyDQpaWGxtWVdOMGIzSXNSRU05YkdGaVAyTmxjblJwWm1sallYUmxV +bVYyYjJOaGRHbHZia3hwYzNRL1ltRnpaVDl2DQpZbXBsWTNSRGJHRnpjejFqVWt4 +RWFYTjBjbWxpZFhScGIyNVFiMmx1ZERDQnlBWUlLd1lCQlFVSEFRRUVnYnN3DQpn +Ymd3Z2JVR0NDc0dBUVVGQnpBQ2hvR29iR1JoY0Rvdkx5OURUajFyWlhsbVlXTjBi +M0l0UzBaVVVrRkpUaTFEDQpRU3hEVGoxQlNVRXNRMDQ5VUhWaWJHbGpKVEl3UzJW +NUpUSXdVMlZ5ZG1salpYTXNRMDQ5VTJWeWRtbGpaWE1zDQpRMDQ5UTI5dVptbG5k +WEpoZEdsdmJpeEVRejFyWlhsbVlXTjBiM0lzUkVNOWJHRmlQMk5CUTJWeWRHbG1h +V05oDQpkR1UvWW1GelpUOXZZbXBsWTNSRGJHRnpjejFqWlhKMGFXWnBZMkYwYVc5 +dVFYVjBhRzl5YVhSNU1BNEdBMVVkDQpEd0VCL3dRRUF3SUZvREE5QmdrckJnRUVB +WUkzRlFjRU1EQXVCaVlyQmdFRUFZSTNGUWlEbWVSL2d1aXhNNGZaDQptUStCcTkx +RWgrQzNLZ3VGc3F4YmhyVFlWUUlCWkFJQkNUQVRCZ05WSFNVRUREQUtCZ2dyQmdF +RkJRY0RBVEFiDQpCZ2tyQmdFRUFZSTNGUW9FRGpBTU1Bb0dDQ3NHQVFVRkJ3TUJN +QTBHQ1NxR1NJYjNEUUVCQ3dVQUE0SUJBUUNBDQpqa1ZBTi9hL0NtVm5DTVV2RW1V +S0FuN1BhMFlpTmxxZVJwU2NIZ1dpYnZjc0NLM1Z1VTlSaENBdldpb1RBMytwDQpr +VXhYL0c4LzFlOXRlcWJnaElMZ2ZtemJuWndvZU1BTHo0aFZqYmtVYy83cGpaSVBr +ejA1cXRaT1ZSUzluaEVMDQpRM0xocEFtcmZXbzYxU0l3bHl3WEowV1YxU050UEtu +bUFvQUV2ZUIvSEpNSitkeTM1Q084Y2tOMFVidmk2OUhsDQoya1pIdE1LUWJsckk3 +ZXV2MHdnVERqWVIvdms3Yjl0UWlxSmE0YURvMnRsZmF2KzF4Tk40WVdxa3R2QUth +c3hsDQpBVW02bjdydVh5OEs4d005bEFVU2Rwb29iNzdQQ1lpTWhZRkF0ODUzQVlD +R1N0bU1nT21Pa0F1YVVEUHNET3pQDQplUXd1S25Hdy82WDJlUXltaU1BWQ0KLS0t +LS1FTkQgQ0VSVElGSUNBVEUtLS0tLQ0K +-----END CERTIFICATE----- +revocation_time 0 +``` ## Plugin command reference @@ -511,4 +557,5 @@ The following commands are supported by the Keyfactor Hashicorp Vault Secrets En ### Read CA chain -`vault read keyfactor/ca_chain` \ No newline at end of file +`vault read keyfactor/ca_chain` + diff --git a/Vault Secrets Engine Installation and Reference.pdf b/Vault Secrets Engine Installation and Reference.pdf deleted file mode 100644 index d81db39..0000000 Binary files a/Vault Secrets Engine Installation and Reference.pdf and /dev/null differ diff --git a/go.mod b/go.mod index e24572d..ccfbad8 100644 --- a/go.mod +++ b/go.mod @@ -1,6 +1,6 @@ module github.com/keyfactor/hashicorp-vault-secrets-engine -go 1.12 +go 1.20 require ( github.com/Keyfactor/keyfactor-go-client v1.2.0 @@ -8,7 +8,48 @@ require ( github.com/hashicorp/go-hclog v0.16.2 github.com/hashicorp/vault/api v1.1.1 github.com/hashicorp/vault/sdk v0.2.1 - github.com/ryanuber/go-glob v1.0.0 - golang.org/x/crypto v0.0.0-20220331220935-ae2d96664a29 - golang.org/x/net v0.0.0-20211112202133-69e39bad7dc2 +) + +require ( + github.com/armon/go-metrics v0.3.3 // indirect + github.com/armon/go-radix v1.0.0 // indirect + github.com/cenkalti/backoff/v3 v3.0.0 // indirect + github.com/fatih/color v1.7.0 // indirect + github.com/golang/protobuf v1.4.2 // indirect + github.com/golang/snappy v0.0.1 // indirect + github.com/hashicorp/go-cleanhttp v0.5.1 // indirect + github.com/hashicorp/go-immutable-radix v1.1.0 // indirect + github.com/hashicorp/go-kms-wrapping/entropy v0.1.0 // indirect + github.com/hashicorp/go-multierror v1.1.0 // indirect + github.com/hashicorp/go-plugin v1.0.1 // indirect + github.com/hashicorp/go-retryablehttp v0.6.6 // indirect + github.com/hashicorp/go-rootcerts v1.0.2 // indirect + github.com/hashicorp/go-sockaddr v1.0.2 // indirect + github.com/hashicorp/go-uuid v1.0.2 // indirect + github.com/hashicorp/go-version v1.2.0 // indirect + github.com/hashicorp/golang-lru v0.5.3 // indirect + github.com/hashicorp/hcl v1.0.0 // indirect + github.com/hashicorp/yamux v0.0.0-20180604194846-3520598351bb // indirect + github.com/mattn/go-colorable v0.1.6 // indirect + github.com/mattn/go-isatty v0.0.12 // indirect + github.com/mitchellh/copystructure v1.0.0 // indirect + github.com/mitchellh/go-homedir v1.1.0 // indirect + github.com/mitchellh/go-testing-interface v1.0.0 // indirect + github.com/mitchellh/mapstructure v1.3.2 // indirect + github.com/mitchellh/reflectwalk v1.0.0 // indirect + github.com/oklog/run v1.0.0 // indirect + github.com/pierrec/lz4 v2.5.2+incompatible // indirect + github.com/ryanuber/go-glob v1.0.0 // indirect + github.com/spbsoluble/go-pkcs12 v0.3.1 // indirect + go.mozilla.org/pkcs7 v0.0.0-20210826202110-33d05740a352 // indirect + go.uber.org/atomic v1.6.0 // indirect + golang.org/x/crypto v0.0.0-20220331220935-ae2d96664a29 // indirect + golang.org/x/net v0.0.0-20211112202133-69e39bad7dc2 // indirect + golang.org/x/sys v0.0.0-20210615035016-665e8c7367d1 // indirect + golang.org/x/text v0.3.6 // indirect + golang.org/x/time v0.0.0-20200416051211-89c76fbcd5d1 // indirect + google.golang.org/genproto v0.0.0-20200526211855-cb27e3aa2013 // indirect + google.golang.org/grpc v1.29.1 // indirect + google.golang.org/protobuf v1.25.0 // indirect + gopkg.in/square/go-jose.v2 v2.5.1 // indirect ) diff --git a/go.sum b/go.sum index 0994eae..6b3a253 100644 --- a/go.sum +++ b/go.sum @@ -3,7 +3,6 @@ cloud.google.com/go v0.26.0/go.mod h1:aQUYkXzVsufM+DwF1aE+0xfcU+56JwCaLick0ClmMT github.com/Azure/go-ansiterm v0.0.0-20170929234023-d6e3b3328b78/go.mod h1:LmzpDX56iTiv29bbRTIsUNlaFfuhWRQBWjQdVyAevI8= github.com/BurntSushi/toml v0.3.1/go.mod h1:xHWCNGjB5oqiDr8zfno3MHue2Ht5sIBksp03qcyfWMU= github.com/DataDog/datadog-go v3.2.0+incompatible/go.mod h1:LButxg5PwREeZtORoXG3tL4fMGNddJ+vMq1mwgfaqoQ= -github.com/Keyfactor/keyfactor-go-client v1.2.0-rc1/go.mod h1:u1M1AjcwiO/Tbvc7EsNl9YTy757hO5wmey1/W/7Qkbs= github.com/Keyfactor/keyfactor-go-client v1.2.0 h1:2gl9CMXoZ7H6mmssqQYUbrJNNyQ3wk2LZzqCiXykIiE= github.com/Keyfactor/keyfactor-go-client v1.2.0/go.mod h1:u1M1AjcwiO/Tbvc7EsNl9YTy757hO5wmey1/W/7Qkbs= github.com/Microsoft/go-winio v0.4.15-0.20190919025122-fc70bd9a86b5/go.mod h1:tTuCMEN+UleMWgg9dVx4Hu52b1bJo+59jBh3ajtinzw= @@ -274,7 +273,6 @@ golang.org/x/crypto v0.0.0-20171113213409-9f005a07e0d3/go.mod h1:6SG95UA2DQfeDnf golang.org/x/crypto v0.0.0-20180904163835-0709b304e793/go.mod h1:6SG95UA2DQfeDnfUPMdvaQW0Q7yPrPDi9nlGo2tz2b4= golang.org/x/crypto v0.0.0-20190308221718-c2843e01d9a2/go.mod h1:djNgcEr1/C05ACkg1iLfiJU5Ep61QUkGW8qpdssI0+w= golang.org/x/crypto v0.0.0-20190418165655-df01cb2cc480/go.mod h1:WFFai1msRO1wXaEeE5yQxYXgSfI8pQAWXbQop6sCtWE= -golang.org/x/crypto v0.0.0-20200604202706-70a84ac30bf9 h1:vEg9joUBmeBcK9iSJftGNf3coIG4HqZElCPehJsfAYM= golang.org/x/crypto v0.0.0-20200604202706-70a84ac30bf9/go.mod h1:LzIPMQfyMNhhGPhUkYOs5KpL4U8rLKemX1yGLhDgUto= golang.org/x/crypto v0.0.0-20220331220935-ae2d96664a29 h1:tkVvjkPTB7pnW3jnid7kNyAMPVWllTNOf/qKDze4p9o= golang.org/x/crypto v0.0.0-20220331220935-ae2d96664a29/go.mod h1:IxCIyHEi3zRg3s0A5j5BB6A9Jmi73HwBIUl50j+osU4= @@ -298,7 +296,6 @@ golang.org/x/net v0.0.0-20190620200207-3b0461eec859/go.mod h1:z5CRVTTTmAJ677TzLL golang.org/x/net v0.0.0-20190813141303-74dc4d7220e7/go.mod h1:z5CRVTTTmAJ677TzLLGU+0bjPO0LkuOLi4/5GtJWs/s= golang.org/x/net v0.0.0-20191004110552-13f9640d40b9/go.mod h1:z5CRVTTTmAJ677TzLLGU+0bjPO0LkuOLi4/5GtJWs/s= golang.org/x/net v0.0.0-20200202094626-16171245cfb2/go.mod h1:z5CRVTTTmAJ677TzLLGU+0bjPO0LkuOLi4/5GtJWs/s= -golang.org/x/net v0.0.0-20200602114024-627f9648deb9 h1:pNX+40auqi2JqRfOP1akLGtYcn15TUbkhwuCO3foqqM= golang.org/x/net v0.0.0-20200602114024-627f9648deb9/go.mod h1:qpuaurCH72eLCgpAm/N6yyVIVM9cpaDIP3A8BGJEC5A= golang.org/x/net v0.0.0-20211112202133-69e39bad7dc2 h1:CIJ76btIcR3eFI5EgSo6k1qKw9KJexJuRLI9G7Hp5wE= golang.org/x/net v0.0.0-20211112202133-69e39bad7dc2/go.mod h1:9nx3DQGgdP8bBQD5qxJ1jj9UTztislL4KSBs9R2vV5Y= @@ -328,7 +325,6 @@ golang.org/x/sys v0.0.0-20200116001909-b77594299b42/go.mod h1:h1NjWce9XRLGQEsW7w golang.org/x/sys v0.0.0-20200122134326-e047566fdf82/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs= golang.org/x/sys v0.0.0-20200223170610-d5e6a3e2c0ae/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs= golang.org/x/sys v0.0.0-20200323222414-85ca7c5b95cd/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs= -golang.org/x/sys v0.0.0-20200602225109-6fdc65e7d980 h1:OjiUf46hAmXblsZdnoSXsEUSKU8r1UEzcL5RVZ4gO9Y= golang.org/x/sys v0.0.0-20200602225109-6fdc65e7d980/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs= golang.org/x/sys v0.0.0-20201119102817-f84b799fce68/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs= golang.org/x/sys v0.0.0-20210423082822-04245dca01da/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs= @@ -336,7 +332,6 @@ golang.org/x/sys v0.0.0-20210615035016-665e8c7367d1 h1:SrN+KX8Art/Sf4HNj6Zcz06G7 golang.org/x/sys v0.0.0-20210615035016-665e8c7367d1/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg= golang.org/x/term v0.0.0-20201126162022-7de9c90e9dd1/go.mod h1:bj7SfCRtBDWHUb9snDiAeCFNEtKQo2Wmx5Cou7ajbmo= golang.org/x/text v0.3.0/go.mod h1:NqM8EUOU14njkJ3fqMW+pc6Ldnwhi/IjpwHt7yyuwOQ= -golang.org/x/text v0.3.2 h1:tW2bmiBqwgJj/UpqtC8EpXEZVYOwU0yG4iWbprSVAcs= golang.org/x/text v0.3.2/go.mod h1:bEr9sfX3Q8Zfm5fL9x+3itogRgK3+ptLWKqgva+5dAk= golang.org/x/text v0.3.6 h1:aRYxNxv6iGQlyVaZmk6ZgYEDa+Jg18DxebPSrd6bg1M= golang.org/x/text v0.3.6/go.mod h1:5Zoc/QRtKVWzQhOtBMvqHzDpF6irO9z98xDceosuGiQ= @@ -388,7 +383,6 @@ gopkg.in/airbrake/gobrake.v2 v2.0.9/go.mod h1:/h5ZAUhDkGaJfjzjKLSjv6zCL6O0LLBxU4 gopkg.in/alecthomas/kingpin.v2 v2.2.6/go.mod h1:FMv+mEhP44yOT+4EoQTLFTRgOQ1FBLkstjWtayDeSgw= gopkg.in/check.v1 v0.0.0-20161208181325-20d25e280405/go.mod h1:Co6ibVJAznAaIkqp8huTwlJQCZ016jof/cbN4VW5Yz0= gopkg.in/check.v1 v1.0.0-20180628173108-788fd7840127/go.mod h1:Co6ibVJAznAaIkqp8huTwlJQCZ016jof/cbN4VW5Yz0= -gopkg.in/check.v1 v1.0.0-20190902080502-41f04d3bba15 h1:YR8cESwS4TdDjEe65xsg0ogRM/Nc3DYOhEAlW+xobZo= gopkg.in/check.v1 v1.0.0-20190902080502-41f04d3bba15/go.mod h1:Co6ibVJAznAaIkqp8huTwlJQCZ016jof/cbN4VW5Yz0= gopkg.in/fsnotify.v1 v1.4.7/go.mod h1:Tz8NjZHkW78fSQdbUxIjBTcgA1z1m8ZHf0WmKUhAMys= gopkg.in/gemnasium/logrus-airbrake-hook.v2 v2.1.2/go.mod h1:Xk6kEKp8OKb+X14hQBKWaSkCsqBpgog8nAV2xsGOxlo= diff --git a/installation.txt b/installation.txt new file mode 100644 index 0000000..ab3a246 --- /dev/null +++ b/installation.txt @@ -0,0 +1,31 @@ +Note: The sha256 checksum for this build is provided along with the release. +Use this value for in the below steps. + +sha256 checksum: + +1) make sure the vault is unsealed + +2) make sure that $env:VAULT_ADDR is set appropriately + - VAULT_ADDR is the url for the instance of vault, example: http://127.0.0.1:8200 + +3) disable and deregister a previous version of the plugin (if installed) by running: + + > vault secrets disable ; vault plugin deregister secret + +4) run the following command to register the plugin: + + > vault plugin register -sha256= -command="keyfactor.exe" secret keyfactor + +** the "command" value should correspond to the name of the binary. For Windows, this will be "keyfactor.exe", for linux this will be "keyfactor". +** the last parameter ("keyfactor") corresponds to the name of the instance of the secrets engine and can be set to whatever identifier you choose. + +5) enable the keyfactor secrets engine by running: + + > vault secrets enable + +6) test the connection by requesting the ca + + > vault read /ca + + +where "keyfactor" is the name of the plugin instance \ No newline at end of file diff --git a/integration-manifest.json b/integration-manifest.json new file mode 100644 index 0000000..64f1b81 --- /dev/null +++ b/integration-manifest.json @@ -0,0 +1,10 @@ +{ + "$schema": "https://keyfactor.github.io/integration-manifest-schema.json", + "integration_type": "api-client", + "name": "keyfactor-vault-secrets-engine", + "status": "production", + "support_level": "community", + "link_github": false, + "update_catalog": false, + "description": "A Vault plugin that allows Vault to use Keyfactor Command as a CA and issue certificates." +} \ No newline at end of file diff --git a/launch-vault.sh b/launch-vault.sh deleted file mode 100644 index d8d8965..0000000 --- a/launch-vault.sh +++ /dev/null @@ -1,4 +0,0 @@ -#! -export VAULT_ADDR=http://vault.jdk.cms:8200 -export KF_CONF_PATH=/home/jdk/keyfactor/vault-guides/secrets/engine/vault/plugins/config.json -x-terminal-emulator -e vault server -config=/home/jdk/keyfactor/config.txt -log-level=TRACE diff --git a/path_certs.go b/path_certs.go index 8d5337d..a65b7ef 100644 --- a/path_certs.go +++ b/path_certs.go @@ -326,11 +326,25 @@ func (b *keyfactorBackend) pathIssueSignCert(ctx context.Context, req *logical.R //check role permissions var err_resp error - if strings.Contains(cn.(string), role.AllowedBaseDomain) && !role.AllowSubdomains { - err_resp = fmt.Errorf("sub-domains not allowed for role") + var valid bool + var hasSuffix bool + + // check the allowed domains for a match. + for _, v := range role.AllowedDomains { + b.Logger().Warn(v) + if strings.HasSuffix(cn.(string), v) { // if it has the suffix.. + hasSuffix = true + if cn.(string) == v || role.AllowSubdomains { // and there is an exact match, or subdomains are allowed.. + valid = true // then it is valid + } + } } - if role.AllowedBaseDomain == cn.(string) { - err_resp = fmt.Errorf("common name not allowed for provided role") + + if !valid { + err_resp = fmt.Errorf("common name not allowed for role") + } + if !valid && hasSuffix { + err_resp = fmt.Errorf("sub-domains not allowed for role") } if err_resp != nil { diff --git a/readme_source.md b/readme_source.md new file mode 100644 index 0000000..f85d417 --- /dev/null +++ b/readme_source.md @@ -0,0 +1,536 @@ +# Hashicorp Vault Secrets Engine + +Keyfactor enables DevOps teams to get seamless access to trusted internal and public certificates via native Vault API +calls and commands, while security teams maintain complete visibility and control over backend PKI operations. + +## About the Hashicorp Vault Secrets Engine plugin by Keyfactor + +The Keyfactor Secrets Engine provides a PKI backend for Vault to issue trusted certificates via the Keyfactor platform. It enables developers to use native Vault API calls and +commands to request certificates from Keyfactor and allows security teams to maintain visibility and control over all certificates issued to Vault instances. +This plugin connects Vault with trusted public, private, or cloud-hosted CAs configured in the Keyfactor platform. +Certificates are requested through Vault using standard Vault commands, and are then redirected to Keyfactor so that the certificates can be issued off of a trusted enterprise +certificate authority. After issuance, the certificate is then returned to Hashicorp Vault and stored within the Vault Secrets store to then be used in other applications. + +--- + +## Table of contents + +- [Overview](#overview) +- [Compatibility](#compatibility) +- [Installation Requirements](#installation-requirements) + - [Keyfactor Requirements](#keyfactor-requirements) + - [Hashicorp Vault Requirements](#hashicorp-vault-requirements) +- [Installation - Keyfactor](#installation---keyfactor) + - [Create the Active Directory service account](#create-the-active-directory-service-account) + - [Create a certificate template](#create-a-certificate-template) + - [Publish the template for the Certificate Authority](#publish-the-template-for-the-certificate-authority) +- [Installation - Vault](#installation---vault) + - [Check the Vault server status](#check-the-vault-server-status) + - [Install and register the plugin](#install-and-register-the-plugin) + - [Configure the plugin](#configure-the-plugin) + - [Adding Roles](#adding-roles) +- [Using the plugin](#using-the-plugin) + - [Issuing Certificates](#issuing-certificates) + - [Viewing Certificates](#viewing-certificates) +- [Command Reference](#plugin-command-reference) + - [Create/update configuration](#createupdate-configuration) + - [Read configuration](#read-configuration) + - [Create/update Roles](#createupdate-role) + - [List roles](#list-roles) + - [Read a role](#read-role) + - [Delete a role](#delete-role) + - [Request a certificate](#request-certificate) + - [List certificates](#list-certificates) + - [View a certificate](#read-certificate) + - [Revoke a certificate](#revoke-certificate) + - [Sign a CSR](#sign-csr) + - [View CA Certificate](#read-ca-cert) + - [View CA Certificate Chain](#read-ca-chain) + +## Overview + +The Keyfactor Secrets Engine for Hashicorp Vault is a Vault plugin that replicates Vault’s onboard PKI API and processes certificate enrollment requests through the Keyfactor Command or Keyfactor Control platform. In many cases the onboard PKI engine included with Vault can be swapped for the Keyfactor engine seamlessly, with no impact to Vault client applications. While the simplicity of the onboard PKI is attractive to developers who are trying to implement the simplest solution in order to meet encryption requirements, it presents other enterprise teams with some challenges when it comes to PKI operations and security: + +- The Vault infrastructure and root materials are not managed by PKI professionals and policies, but rather by DevOps teams that may not be trained in how to properly handle and manage an enterprise PKI. +- Lack of Certificate Lifecycle Management places organizations in a reactionary posture. If there are weaknesses in the organization processes, full visibility of the certificates is necessary in order to identify these risks prior to a security event or audit failure. +- All certificates are susceptible as an attack surface and should be managed and monitored, regardless of their lifetime, to ensure that issuance policies and certificate standards are followed. + +Keyfactor Command can provide the control and visibility needed for a Vault environment. Using the Keyfactor Secrets Engine plugin for Vault, PKI functionality is directed to your enterprise PKI environment, placing control back into the hands of the enterprise PKI admins, and allowing your PKI admins to stay in control of how and when certificates are issued. The Keyfactor Secrets Engine offers the following enterprise capabilities: + +- Issue certificates and place them into the Vault secrets store using your existing enterprise PKI. +- Eliminate the need for a standalone PKI within the vault environment. +- Gain complete visibility and management of certificates across all Vault instances and manage them through a single pane of glass. +- Reporting, alerting, automation, and auditing on the certificates within the environment. +- Easily identify and revoke non-compliant or rogue certificates. +- Integrate with SIEMs and ticketing systems for automated notifications. + + !["high-level-architecture"](images/arch-diagram.png) + +> [!IMPORTANT] +> The Keyfactor Vault Secrets Engine is designed to be a drop in replacement for the native +> Vault CA, and implements most of the functionality provided by the PKI secrets engine +> to enable enterprise grade certificate management for certificates requested via +> Vault. There are some important security differences when using the Keyfactor plugin, +> namely in how certificate issuance polices are enforced. The plugin only supports domain +> and subdomain restrictive role polices and defers to the Command infrastructure for it's +> issuance security model based on certificate templates. The only role parameters utilized +> by this secrets engine are "AllowedDomains" and "AllowSubDomains". Other parameters +> utilized by the Vault native PKI secrets engine, such as "TTL", "KeyType", "AllowIPSANs", +> etc. For reference, the full list of fields supported by the Vault PKI secrets engine can +> be found [here](https://developer.hashicorp.com/vault/api-docs/secret/pki#list-roles). +> When architecting a solution, consideration should be given to the +> native Vault policies, the roles implemented by the secrets engine plugin, and the template +> rules available in Command. + +## Compatibility + +This Vault Plugin has been tested against Hashicorp Vault version 1.10+ and the Keyfactor Platform 9.6+. We provide several pre-built binary files that correspond to various operating systems and processor architectures. If not building the plugin from source code, select the os/architecture combination that corresponds to your environment. + +## Installation Requirements + +The requirements for the plugin are relatively simple. It runs as a single executable on the Hashicorp Vault server. +There are no specific system requirements to install it, however there are a few general things that must be in place for +it to function properly. These requirements are listed below, and are then expanded in the details throughout this +document. + +### Keyfactor Requirements + +- A functional instance of Keyfactor Command +- An administrative user account to be used for configuring the Keyfactor options needed for the implementation +- A functional integrated certificate authority to be used for issuing the certificates +- A certificate template (or templates) defined to use for certificate issuance. +- A user account with permissions to connect to the Keyfactor API and submit certificate requests. This user account will require READ and ENROLL permissions on the certificate template that you will use for the Vault plugin. + +### Hashicorp Vault Requirements + +- A functional Hashicorp Vault Installation **version 1.10.xx or greater**. +- An administrative account with permission to login to the Hashicorp Vault server in order to make administrative changes. +- An adequate number of unseal keys to meet the minimum criteria to unseal the Hashicorp Vault +- A Hashicorp Vault login token + +## Installation - Keyfactor + +### Create the Active Directory service account + +For the purposes of this document, we will not go into the details of how to create an Active Directory user since this process can vary widely, however, here are a couple things to consider: + +- Ensure that the user does not have an expiring password, or if it does, ensure that the password resets are managed carefully. Expiration of this password could result in production outages with the plugin. +- Ensure that the user does not have logon time restrictions unless you only want the Hashicorp Vault plugin to function during specific timeframes. + +### Assign the user permissions in Keyfactor Command + +In order to be able to enroll for certificates through the Keyfactor Command API, it will be necessary to create the necessary role and delegate permissions within Keyfactor. It is not a requirement that this be a new role. If there is an existing role within your organization that allows for these basic permissions, that role can be used for this connection. If you do not have an existing role, and would like to create one, those steps are described later in this document. + +### Create a certificate template + +The first step to configuring Keyfactor is to create the certificate template that will be used for the enrollment and publish it into Keyfactor. + +**To create a new certificate template and import into Keyfactor:** + +1. Open up the Certificate Authority MMC console. + +1. Right Click on Certificate Templates, and select "Manage". This will open up the Certifcate Templates MMC +console. + +1. In the Certificate Templates MMC console, choose a template that you would like to use as a starting point for +your new Vault Plugin template, and duplicate it as a starting point. For standard SSL certificates, most companies will start with a template such as "Web Server" for a general template. In situations where you +need the certificate to do mutual TLS authentication, you may wish to choose the Computer template so that it will include both the Client Authentication and Server Authentication key usages. To duplicate the template, right click on the template and select "Duplicate Template". + +1. You should now see the properties for the new template you are creating, and you will need to customize the +template for use with the plugin. In most cases, there will be only a few minor changes that need made to the +template. + + 1. On the General tab, change the Template Display Name to represent the name that you want to have on the template. + + !["template1"](images/template1.png) + + 1. On the General tab, set the Validity Period and Renewal Period for the certificates that you are going to issue off of this template. + + !["template2"](images/template2.png) + + > Validity and Renewal period values depend on use case and organizational policy. + + 1. On the Request Handling tab, ensure that the option is selected for "Allow Private Keys to be Exported" + + !["template3"](images/template3.png) + + 1. Unless you are planning to implement an approval workflow process for the certificates issued through Hashicorp Vault, ensure that "CA Certificate Manager Approval" is not checked on the Issuance Requirements tab. + + !["template4"](images/template4.png) + + 1. On the Security tab, add the service account that was created earlier so that it has permissions to enroll certificates off of this template. Click Add to search for the user to add, and then grant the user READ and ENROLL permissions on the Template. + + !["template5"](images/template5.png) + + 1. Click OK to save the template. + +### Publish the template for the Certificate Authority + +It is now necessary to take the certificate template that you created and publish it so that it is an available template for issuance off of the CA. + +**To publish the template**: + +1. Open the Certificate Authority MMC console +1. Right-click on Certificate Templates in the left hand pane and select NEW – Certificate Template to Issue +!["template6"](images/template6.png) + +1. Select the template that was created in the previous step, and then click OK. +!["template7"](images/template7.png) + +### Import the new template into the Keyfactor console + +Now that the new certificate template has been created on the CA, we need to ensure that the template is available for issuance within the Keyfactor Command console. + +**To import the certificate template**: + +1. Log into the Keyfactor Command console as a user with administrative privileges + +1. Select "Locations" from the top menu bar, then select "Certificate Templates" +!["template8"](images/template8.png) + +1. Click the "Import Templates" button at the top of the screen +!["template9"](images/template9.png) + +1. Select the Active Directory Forest where you created the template, and then click "Import Templates" +!["template10"](images/template10.png) + +### Enable the template for CSR enrollment through Keyfactor + +Once the template has been imported into Keyfactor Command, it is then necessary to enable that template for PFX enrollment through the console. + +To enable CSR enrollment on the template: + +1. Select Locations from the top menu bar, then select "Certificate Templates" +!["template8"](images/template8.png) + +1. Look through the list to locate the certificate template that was created and previously imported into the Keyfactor console. Double Click on that template. +!["template11"](images/template11.png) + +1. On the properties tab for the template, enable CSR enrollment. Then click Save +!["template12"](images/template12.png) + +## Installation - Vault + +This document covers configuration of the Keyfactor Secrets Engine Plugin for Hashicorp Vault, and assumes that there is a running Vault environment in place. This document does not cover the steps necessary to do the initial install and configuration of Hashicorp Vault. + +On the server that will host the vault plugin, it will be necessary to setup the appropriate environment variables and +configuration files to enable the plugin to run and establish a connection back to Keyfactor Command. The specific syntax for setting environment variables will differ slightly between Windows and Linux distributions, but the approach is the same. + +### Check the Vault server status + +Hashicorp Vault must be installed and running to install and register the Keyfactor Secrets Plugin. To check the status of the Vault installation on the server being used, log into the Vault server with a logon account that has sufficient administrative privileges, and issue the following command: + +`vault status` + +The results returned should look something like this: + +!["vault1"](images/vault1.png) + +There are 2 key values to look for in these results: + +1. **Initialized** – Verify that the vault has been initialized and the status shows TRUE. If this value is FALSE, it means that this is a new instance of Vault that has not yet been initialed. You will need to go through a Vault initialization using the "vault operator init" command prior to proceeding. + +1. **Unsealed** – In order to perform operations against a vault instance, the vault must be unsealed with the unlock keys that were generated during the initialization process. Vault has a (m of n) key requirement… so for instance 3 of the 5 keys must be entered to unseal the vault. (This requirement can vary based on configuration) If the current status of the vault shows SEALED then it is necessary to enter these keys to unseal the vault. These keys can be entered individually (and potentially by different people or processes) + +``` +# vault operator unseal 3TGWPmQDdqkRsV9VamEYJ0tolsaEEo3u4kuwy2o6u6Om +# vault operator unseal Ja4AGQ4N8193/5O7hJPpRcncmqBpnH1mdjqcQSqDVq6v +# vault operator unseal cuE1X01NrNgeAU6ao5aNUFsjWAPhOgEPkgaW5Vl19XDg +``` + +or they can be all issued within a single command as illustrated below: + +``` +# vault operator unseal 3TGWPmQDdqkRsV9VamEYJ0tolsaEEo3u4kuwy2o6u6Om && vault operator unseal +Ja4AGQ4N8193/5O7hJPpRcncmqBpnH1mdjqcQSqDVq6v && vault operator unseal +cuE1X01NrNgeAU6ao5aNUFsjWAPhOgEPkgaW5Vl19XDg +``` + +Once the appropriate number of keys has been entered, the status should indicate "Unsealed = True" + +### Install and register the plugin + +To install and register the plugin on the Vault server, follow these steps: + +1. Copy the Keyfactor plugin binary into a directory on the Vault server using SFTP or another file copy process. The location of this file does not really matter, but typically would be in a Vault plugins directory. + + An example plugins path may look like this: + + `/usr/bin/vault/plugins` + +1. Set the file to be executable. + + `chmod +x keyfactor` + +1. The sha256 checksum should have been provided in the release zip file. + If you are building the plugin from scratch, you can run the following command to get this value: + + `sha256sum ./keyfactor` + + The result will show the sha256 value that will be needed in the next step. + +1. Registering the new secrets engine within Vault is done using a vault plugin command to register the plugin into the Vault secrets catalog. + + Linux: + + `# vault plugin register -sha256=47f549d44ab2abcb528aa45725b3a83334a9465bb487f3d1182add55e5580c36 secret ` + + Windows: + + `> vault plugin register -sha256=97a76ee45f8bbc3e852520cba38d16206f6a92ab0b8a2d2bbd7eaaae064ae9bf -command="keyfactor.exe" secret ` + + > Windows requires the binary to have a recognized executable extension, so we name the windows executable keyfactor.exe. + + The result should look like this: `Success! Registered plugin: ` + + > _For the rest of this document, we will assume that the instance of the plugin is named "keyfactor"._ + +1. Enable the plugin within Hashicorp Vault + Once the plugin is installed into Vault, it just needs to be enabled. As a part of this enable process, you must specify the endpoint name that will be used for the secrets engine. This name is arbitrary. For this example, we are using keyfactor as the enpoint name, but it can be named to match existing endpoints that you are looking to replace with a connection to Keyfactor if necessary. + + run the following command: + + `vault secrets enable keyfactor` + + if successful the output should look like this: + + `Success! Enabled the keyfactor secrets engine at: keyfactor/` + +1. Check the registered paths for the plugin + The Hashicorp vault plugin architecture generates endpoints for each plugin. Run the vault `path-help` command to view the registered paths. + + `vault path-help keyfactor` + + the output should look similar to the following: + +``` + +## DESCRIPTION + +The Keyfactor backend is a pki service that issues and manages certificates. + +## PATHS + +The following paths are supported by this backend. To view help for +any of the paths below, use the help command with any route matching +the path pattern. Note that depending on the policy of your auth token, +you may or may not be able to access certain paths. + + ^ca(/pem)?$ + Fetch a CA, CRL, CA Chain, or non-revoked certificate. + + ^ca_chain(/pem)?$ + Fetch a CA, CRL, CA Chain, or non-revoked certificate. + + ^cert/(?P[0-9A-Fa-f-:]+)$ + Fetch a CA, CRL, CA Chain, or non-revoked certificate. + + ^certs/?$ + Use with the "list" command to display the list of certificate serial numbers for certificates managed by this secrets engine. + + ^config$ + Configure the Keyfactor Secrets Engine backend. + + ^issue/(?P\w(([\w-.]+)?\w)?)$ + Request a certificate using a certain role with the provided details. + example: vault write keyfactor/issue/ common_name= dns_sans= + + ^revoke/(?P[0-9A-Fa-f-:]+)$ + Revoke a certificate by serial number. + + ^roles/(?P\w(([\w-.]+)?\w)?)$ + Manage the roles that can be created with this backend. + + ^roles/?$ + List the existing roles in this backend + + ^sign/(?P\w(([\w-.]+)?\w)?)$ + Request certificates using a certain role with the provided details. + example: vault write keyfactor/sign/ csr= + +``` + +### Configure the plugin + +Once the plugin has been successfully installed, the next step is to set the configuration values that will allow it to interact with the Keyfactor platform. + +The Keyfactor plugin implements a per-instance configuration which allows multiple instances of the plugin to exist simultaneously. This is useful in cases where you want to manage multiple certificate authorities or templates. + +To set a configuration value: + +`vault write /config =""` + +The values that will need to be set are the following: + +- url + - The url pointing to the keyfactor platform with no trailing slashes **(example: "https://kftrain.keyfactor.lab")** +- username + - The username of the account used for authenticating to the platform including the domain **(example: "KEYFACTOR\VaultUser")** +- password + - The password corresponding to the user account for authenticating to the platform. +- ca + - The certificate authority used when issuing certificates via the plugin **(example: kftrain.keyfactor.lab\\\\keyfactor-KFTRAIN-CA)** +- template + - The certificate template name to use when issuing certificates. It should be issuable by the CA + +Once you've set the configuration properties, run the command: +`vault read /config` +in order to view the configuration settings (see example below). + +!["configread"](images/configread.png) + +### Adding Roles + +Hashicorp Vault supports being able to add roles to control certificate issuance policies for allowed domains and allowing sub-domain certificates to be created. +To create a role, use the vault write command as in the below example. + +`vault write keyfactor/roles/hashiwebserver allowed_domains=kftrain.lab allow_subdomains=true` + +This will create a role called "hashiwebserver" that can be used to generate certificates for domains ending with "kftrain.lab". + +These properties can also be set in the certificate template. If they differ, the most restrictive setting is applied. + +## Using the plugin + +### Issuing Certificates + +When requesting a certificate using the Keyfactor plugin, the command is the same as if you were issuing the certificate through the vault integrated PKI. As a part of the write command you will specify the role name you would like to use, as well as the common name on the certificate. A typical certificate issuance command is listed below for the hashiwebserver role, and a CN of foo.kftrain.lab on the certificate. + +`vault write keyfactor/issue/hashiwebserver common_name=foo.kftrain.lab dns_sans=foo.kftrain.lab` + +The resulting response will show the certificate data response for the request. This certificate will also be stored in the Vault secrets store. + +!["vault3"](images/vault3.png) + +### Viewing Certificates + +After certificates are stored in the secrets store, you can then retrieve those certificates at a later time if necessary. To list the certificates that exist within the Vault store, use the LIST option with vault. The only parameter that you need to include is the secrets store name for the store that you would like to read. The system will then return a list of all of the serial numbers for certificates that are present in that secrets store. + +`vault list keyfactor/certs` + +The results of the command will be a list of serial numbers for the certificates in that store location: + +``` +Keys +---- +750000276546d818cbe70231b6000000002765 +750000276623facfaddb6c4ca1000000002766 +``` + +If you would like to retrieve a specific certificate from the store, you can do so by using the "vault read" command, and specifying the serial number of the certificate that you would like returned. The format for the command looks like this: + +`vault read keyfactor/cert/` + +example: + +`vault read keyfactor/cert/750000276546d818cbe70231b6000000002765` + +The response will show the value for that certificate. + +``` +Key Value +--- ----- +certificate -----BEGIN CERTIFICATE----- +LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tDQpNSUlGZXpDQ0JHT2dBd0lCQWdJ +VGRRQUFKMlZHMkJqTDV3SXh0Z0FBQUFBblpUQU5CZ2txaGtpRzl3MEJBUXNGDQpB +REJQTVJNd0VRWUtDWkltaVpQeUxHUUJHUllEYkdGaU1Sa3dGd1lLQ1pJbWlaUHlM +R1FCR1JZSmEyVjVabUZqDQpkRzl5TVIwd0d3WURWUVFERXhSclpYbG1ZV04wYjNJ +dFMwWlVVa0ZKVGkxRFFUQWVGdzB5TWpBME1qSXhOVE0xDQpNVGxhRncweU1qQTNN +akV4TlRNMU1UbGFNQm94R0RBV0JnTlZCQU1URDNWMWRTNXJablJ5WVdsdUxteGhZ +akNDDQpBU0l3RFFZSktvWklodmNOQVFFQkJRQURnZ0VQQURDQ0FRb0NnZ0VCQU9h +MmEwQzVoeWpvUHRWbWNqUGRVZlhuDQpKU3BvbkRyQ1dJT1ROcmxTcytkbWM3aFNw +SjdTanZvcCtSZUIrRFVQWWhXbFBETWZlOGFFSEkyUFAwMGg3dVd3DQpBaHJ6T2Jk +MmthUkhyOXZDU2h6dE1vYjBQd0JrTG9MK2JLUWRIK2xTM1RVMHpKQytidUV0WWJ3 +dHcvOGJSdFNFDQpIRWJaMXNrU1Y5RmJzWlBjb3I2WTVqcFV0ck85Y1dhbUs3d0Jw +dkFnVHEzYk44ZWt5ZUl4R1V6YVhjRHd2aEVnDQoxcG5xS1loY3NmOU03b2R1Ullv +Uytpcy9BTmlXZllSMDZBV29odE41VHlJVXBlcnVIZEh6WWpBYXJ4RXhzWEFrDQpR +d3BxVGF5dTFNUWU1cllYdWpyL1FEOG5EbGl5TXp6NjJINmNjRkRmWmhHNWZkVUJK +K25uRTlTbllabDRCcmNDDQpBd0VBQWFPQ0FvTXdnZ0ovTUJvR0ExVWRFUVFUTUJH +Q0QzVjFkUzVyWm5SeVlXbHVMbXhoWWpBZEJnTlZIUTRFDQpGZ1FVS0E0VkFhS3M5 +a2RjL3VXQXR3Sm5TSUJleVM4d0h3WURWUjBqQkJnd0ZvQVVjQlV6UFc3WlF1cVVN +UDNSDQpGVENiRFUxaFRHVXdnZFFHQTFVZEh3U0J6RENCeVRDQnhxQ0J3NkNCd0lh +QnZXeGtZWEE2THk4dlEwNDlhMlY1DQpabUZqZEc5eUxVdEdWRkpCU1U0dFEwRXNR +MDQ5UzBaVWNtRnBiaXhEVGoxRFJGQXNRMDQ5VUhWaWJHbGpKVEl3DQpTMlY1SlRJ +d1UyVnlkbWxqWlhNc1EwNDlVMlZ5ZG1salpYTXNRMDQ5UTI5dVptbG5kWEpoZEds +dmJpeEVRejFyDQpaWGxtWVdOMGIzSXNSRU05YkdGaVAyTmxjblJwWm1sallYUmxV +bVYyYjJOaGRHbHZia3hwYzNRL1ltRnpaVDl2DQpZbXBsWTNSRGJHRnpjejFqVWt4 +RWFYTjBjbWxpZFhScGIyNVFiMmx1ZERDQnlBWUlLd1lCQlFVSEFRRUVnYnN3DQpn +Ymd3Z2JVR0NDc0dBUVVGQnpBQ2hvR29iR1JoY0Rvdkx5OURUajFyWlhsbVlXTjBi +M0l0UzBaVVVrRkpUaTFEDQpRU3hEVGoxQlNVRXNRMDQ5VUhWaWJHbGpKVEl3UzJW +NUpUSXdVMlZ5ZG1salpYTXNRMDQ5VTJWeWRtbGpaWE1zDQpRMDQ5UTI5dVptbG5k +WEpoZEdsdmJpeEVRejFyWlhsbVlXTjBiM0lzUkVNOWJHRmlQMk5CUTJWeWRHbG1h +V05oDQpkR1UvWW1GelpUOXZZbXBsWTNSRGJHRnpjejFqWlhKMGFXWnBZMkYwYVc5 +dVFYVjBhRzl5YVhSNU1BNEdBMVVkDQpEd0VCL3dRRUF3SUZvREE5QmdrckJnRUVB +WUkzRlFjRU1EQXVCaVlyQmdFRUFZSTNGUWlEbWVSL2d1aXhNNGZaDQptUStCcTkx +RWgrQzNLZ3VGc3F4YmhyVFlWUUlCWkFJQkNUQVRCZ05WSFNVRUREQUtCZ2dyQmdF +RkJRY0RBVEFiDQpCZ2tyQmdFRUFZSTNGUW9FRGpBTU1Bb0dDQ3NHQVFVRkJ3TUJN +QTBHQ1NxR1NJYjNEUUVCQ3dVQUE0SUJBUUNBDQpqa1ZBTi9hL0NtVm5DTVV2RW1V +S0FuN1BhMFlpTmxxZVJwU2NIZ1dpYnZjc0NLM1Z1VTlSaENBdldpb1RBMytwDQpr +VXhYL0c4LzFlOXRlcWJnaElMZ2ZtemJuWndvZU1BTHo0aFZqYmtVYy83cGpaSVBr +ejA1cXRaT1ZSUzluaEVMDQpRM0xocEFtcmZXbzYxU0l3bHl3WEowV1YxU050UEtu +bUFvQUV2ZUIvSEpNSitkeTM1Q084Y2tOMFVidmk2OUhsDQoya1pIdE1LUWJsckk3 +ZXV2MHdnVERqWVIvdms3Yjl0UWlxSmE0YURvMnRsZmF2KzF4Tk40WVdxa3R2QUth +c3hsDQpBVW02bjdydVh5OEs4d005bEFVU2Rwb29iNzdQQ1lpTWhZRkF0ODUzQVlD +R1N0bU1nT21Pa0F1YVVEUHNET3pQDQplUXd1S25Hdy82WDJlUXltaU1BWQ0KLS0t +LS1FTkQgQ0VSVElGSUNBVEUtLS0tLQ0K +-----END CERTIFICATE----- +revocation_time 0 +``` + +## Plugin command reference + +The following commands are supported by the Keyfactor Hashicorp Vault Secrets Engine plugin. These examples assume the instance of the plugin is named "keyfactor". + +### Create/update configuration + +`vault write keyfactor/config =` + +### Read configuration + +`vault read keyfactor/config` + +### Create/update role + +`vault write keyfactor/roles/ allowed_domains=, allow_subdomains=true` + +### List roles + +`vault list keyfactor/roles` + +### Read role + +`vault read keyfactor/roles/` + +### Delete role + +`vault delete keyfactor/roles/` + +### Request certificate + +`vault write keyfactor/issue/ common_name= dns_sans=` + +### List certificates + +`vault list keyfactor/certs` + +### Read certificate + +`vault read keyfactor/cert/` + +> Note: Certificate serial numbers are provided in the output for enrollment and list commands + +### Revoke certificate + +`vault write keyfactor/revoke serial=` + +### Sign CSR + +`vault write keyfactor/sign/ csr=` + +### Read CA cert + +`vault read keyfactor/ca` + +### Read CA chain + +`vault read keyfactor/ca_chain` diff --git a/sample_config.json b/sample_config.json deleted file mode 100644 index 1563af6..0000000 --- a/sample_config.json +++ /dev/null @@ -1,7 +0,0 @@ -{ - "host":"xxx.xxx.xxx", - "creds":"S0VZRkFDVE9SXEFkbWluaXN0cmF0b3I6UGFzc3dvcmQx", - "template":"HashiCorpVaultServer", - "protocol":"https", - "CA":"kftrain.keyfactor.lab\\\\keyfactor-KFTRAIN-CA" - } \ No newline at end of file diff --git a/unseal.sh b/unseal.sh deleted file mode 100644 index 436e4b7..0000000 --- a/unseal.sh +++ /dev/null @@ -1,3 +0,0 @@ -#! -export VAULT_ADDR=http://127.0.0.1:8200 -vault operator unseal llTyznCImd8mMdAbKNOUHtkCn6kLMC5COJ+6sbCuJwqC && vault operator unseal TcWAJobiSBuNgRckPvu3jyILRaqZourQ6mwixSQktt+V && vault operator unseal ulHiSWHM8xV11nGbTdc3kHtWKKK0CxbqnOjJV3zXLXRI diff --git a/write.sh b/write.sh deleted file mode 100644 index 7205592..0000000 --- a/write.sh +++ /dev/null @@ -1,3 +0,0 @@ -#! -vault write keyfactor/roles/jdk allowed_domains=jdk.cms -vault write keyfactor/issue/jdk common_name=jd.jdk.cms