cloudfoundry-community / vault-boshrelease Goto Github PK

Just noting here in case others run into this nasty issue caused by a bug in the aws-sdk: hashicorp/vault#4721

It's fixed in master right now but until 0.10.3 gets released it's probably best to downgrade back to the 1.0.0 bosh release.

I am opening this as a separate issue from #58 .

The reason release 1.0.0 gets the ssl error (but was fine 0.8.3) is due to the code vault_addr=p("vault.address", "") now always returns "", and therefore VAULT_SKIP_VERIFY will not be set.

While this can be considered as bug since it breaks behavior from 0.8.3, I would argue the original feature was a bad idea of ignoring SSL check. So it can be handled multiple ways.

• Update the readme requiring SAN IP be included in the cert (that works as I verified). This would be my recommendation.
• Or update the file to be backward compatible. This can be cheated by requiring the config to include a dumb property like "address: https" to fool the script and having VAULT_SKIP_VERIFY to be set. The parameter would have no other purpose as well. The more you think about this, the more you feel it is a bad idea.

https://www.hashicorp.com/blog/vault-0.5.html

How can I enable and configure LDAP Auth Method to vault-boshrelease ?

cd vault-boshrelease
./templates/make_manifest aws-ec2 fails as it requires the additional property to set the blobstore

/var/vcap/jobs/vault/data/unseal_keys
include 3 kays and one empty line

- azs:
  - AZ1
  - AZ1
  - AZ3
  instances: 3
  jobs:
  - name: consul
    release: consul
  - name: vault
    properties:
      tls:
      - cert: cert
      - key: key
        name: vault
      vault:
        config: |
          storage "consul" {
            path = "vault/"
            check_timeout = "5s"
            max_parallel = "128"
          }
          listener "tcp" {
            address = "0.0.0.0:8200"
            tls_cert_file = "/var/vcap/jobs/vault/tls/vault/cert.pem"
            tls_key_file  = "/var/vcap/jobs/vault/tls/vault/key.pem"
            tls_min_version = "tls12"
          }
          api_addr = "http://(ip):8200"
          cluster_addr = "https://(ip):8201"
        update:
          unseal_keys:
          - key1
          - key2
          - key3

deployment pass without failed but vault was not unseal

i try to run script by root

vault/f592421b-3aec-4cf1-915b-c6e19725e0c6:/var/vcap/jobs/vault/bin# ./post-start 
+ source /var/vcap/jobs/vault/helpers/ctl_setup.sh vault
++ set -e
++ set -u
++ JOB_NAME=vault
++ output_label=vault
++ export JOB_DIR=/var/vcap/jobs/vault
++ JOB_DIR=/var/vcap/jobs/vault
++ chmod 755 /var/vcap/jobs/vault
++ source /var/vcap/jobs/vault/data/properties.sh
+++ export NAME=vault
+++ NAME=vault
+++ export JOB_INDEX=2
+++ JOB_INDEX=2
+++ export JOB_FULL=vault/2
+++ JOB_FULL=vault/2
+++ export VAULT_ADDR=https://127.0.0.1:8200
+++ VAULT_ADDR=https://127.0.0.1:8200
+++ export VAULT_TOKEN=
+++ VAULT_TOKEN=
++ source /var/vcap/jobs/vault/helpers/ctl_utils.sh
++ redirect_output vault
++ SCRIPT=vault
++ mkdir -p /var/vcap/sys/log/monit
++ exec
++ exec
vault/f592421b-3aec-4cf1-915b-c6e19725e0c6:/var/vcap/jobs/vault/bin# 

Some PRs, e.g. #41, generously provide more operator files. It would be awesome if the submitters could include changes to ci/settings.yml to add more testflight jobs.

See https://github.com/cloudfoundry-community/docker-boshrelease/blob/master/ci/settings.yml for an example.

This is probably mostly a documentation + examples implementation.

Sorry to keep bugging 😄

https://github.com/hashicorp/vault/blob/master/CHANGELOG.md#101-december-14th-2018

https://www.vaultproject.io/downloads.html

This will give us a chance to test out the new pipeline for Vault as well...

Hi. We are using vault cluster with consul.
When we try to unbind the consul, it's failing with below messages. Can I know why and how can I debug?

2017/09/21 11:55:45 [unbind ea9e3158-eb34-4e72-9e52-6e8c7efaca1d / 8dde40c2-8dda-43fc-8def-3b2225017e1f] unbinding service
2017/09/21 11:55:45 [unbind ea9e3158-eb34-4e72-9e52-6e8c7efaca1d / 8dde40c2-8dda-43fc-8def-3b2225017e1f] using vault at https://SECRET
2017/09/21 11:55:45 [unbind ea9e3158-eb34-4e72-9e52-6e8c7efaca1d / 8dde40c2-8dda-43fc-8def-3b2225017e1f] retrieving access token
2017/09/21 11:55:45 [unbind ea9e3158-eb34-4e72-9e52-6e8c7efaca1d / 8dde40c2-8dda-43fc-8def-3b2225017e1f] revoking token '9SECRETb'
2017/09/21 11:55:45 [unbind ea9e3158-eb34-4e72-9e52-6e8c7efaca1d / 8dde40c2-8dda-43fc-8def-3b2225017e1f] error: vault returned a 200 OK

There is no error messages at vault and consul also.
CF api return message is
"error_details": {
"description": "Service instance vault-svc: Service broker error: Received 200 OK from Vault",
"error_code": "CF-ServiceBrokerBadResponse",
"code": 10001,
"http": {
"uri": "https://SECRET/v2/service_instances/ea9e31588-eb34-4e72-9e52-6e8c7efaca1d/service_bindings/8dde40c2-8dda-43fc-8def-3b2225017e1f",
"method": "DELETE",
"status": 500
}

• Broker's Revoke return message seems like this
  {"request_id":"96acdd59-30d2-6f5e-8652-64ea70a0b5eb","lease_id":"","renewable":false,"lease_duration":0,"data":null,"wrap_info":null,"warnings":["Using a token in the path is unsafe as the token can be logged in many places. Please use POST or PUT with the token passed in via the "token" parameter."],"auth":null}

Hi,

Can you please cut some releases for vault 0.11.1 and vault 0.11.2?

Thanks,

To reproduce:

1. Create a deployment with the sample manifest
   bosh -d vault deploy manifests/vault.yml --vars-store vars.yml
2. Copy CA certificate from vars.yml to a pem file, and export VAULT_CACERT=<path_to_ca_file>
3. Issue a vault command (e.g. vault status)
   Result: Error checking seal status: Get https://vault.pcip.cf:8200/v1/sys/seal-status: x509: certificate signed by unknown authority

The sample manifest has a variable vault-ca used to sign vault-tls, but vault-ca.certificate is not appended to vault-tls.certificate in vault's job properties properties.tls.cert

While we're at it, drop the older blobs and remove the stupid glob in the package spec.

Hashicorp person gave me a JSON endpoint that returns list of available versions; so I think we could now create a hashicorp-release-resource and detect new releases:

$ curl -s https://releases.hashicorp.com/vault/index.json | jq -r '.versions[].builds[].url' | grep linux_amd64 | tail -n1
https://releases.hashicorp.com/vault/0.8.1/vault_0.8.1_linux_amd64.zip

From the sample templates included here, I'm not sure how / whether you recommend setting up service discovery and health checks so that clients don't hit sealed vault instances. For example, the vault consul backend adds a vault service with active and standby tags, so that clients using consul dns can access active.vault.service.consul. Or clients can hit vault via a load balancer that uses the vault health check endpoint, as in https://github.com/hashicorp/vault/blob/master/terraform/aws/main.tf#L76-L107. This might be out of scope for this release, but I think adding recommendations for health checks of some kind would be useful. WDYT?

Hi,

Is there a way to hide the vault's versioning information from all the possible "public" vault's places, like the versioning information in the UI (at the bottom there is a banner like © 2021 HashiCorp Vault 1.4.0 Upgrade to Vault Enterprise Documentation) or from the API endpoints /v1/sys/health and /v1/sys/seal-status which also return a "version" key.

Impact
The disclosure of version or system information allows an attacker to conduct a selective search in vulnerability databases. The obtained information can then be used as a basis for attacks.
Recommendation
It is recommended not to disclose any information about the system or available services. Such information should be removed from banners.

Thanks a lot,

Vault process is now invoked by root. However, administrator may need to execute vault as normal user when writing to NFS backend. It also increases security overall.

This issue started with 1.0.0 bosh release. All was working on 0.8.0 release. The post-start job seems to be the same, did the vault binary itself change to cause the behavioral difference? The change is not necessarily a bad thing, but should be documented so the CSR can be generated properly.

vault-server/76005e04-f753-4c40-9bc7-d61808e8ea8c:/var/vcap/packages/vault/bin# ./vault unseal <key redacted>
WARNING! The "vault unseal" command is deprecated. Please use "vault operator
unseal" instead. This command will be removed in Vault 0.11 (or later).

Error unsealing: Put https://127.0.0.1:8200/v1/sys/unseal: x509: cannot validate certificate for 127.0.0.1 because it doesn't contain any IP SANs

Thanks
Yansheng

Step-down script hardcodes port 8200 instead of using value in variable
vault.listener.tcp.port

https://github.com/hashicorp/vault/blob/master/CHANGELOG.md#0115-november-12th-2018

Do we also want to push a 1.0.0 beta2 release version?

When this commit was added:

8b6213e

The templates/infrastructure-aws-ec2.yml file doesn't actually account for the backend at all (not even as a parameter), so now ./templates/make_manifest aws-ec2 just completely fails with:

1 error(s) detected:

• $.jobs.vault.properties.vault.backend: Specify a backend for the vault to be stored in

instead of actually asking for the parameter.

The new release of vault is out. Should be upgraded along with jumpbox to keep the vault versions syncrhonized

i have 3 nodes with vault with s3 backend, with static ips:

vault/46ed57a5-e09d-4037-aaf3-783f4c291067 running az2 101.35.96.73
vault/6ef5fbf7-d4d7-438a-bdfd-b4d67453ab87 running az1 101.35.96.71 (master node)
vault/c382f314-9af1-4204-bb9c-91bac745eac0 running az3 101.35.96.72

but the client has only one record:
export VAULT_ADDR=https://vault-dev.net:8200
vault-dev.net - 101.35.96.71 (master node)
How to configure HA correctly?

e.g:
if vault/6ef5fbf7-d4d7-438a-bdfd-b4d67453ab87 running DC10P1 101.35.96.71
will down how it will works ?

If the master node goes down, there is no automatic failover/load balancing. Because the DNS is pointing at a specific node.

Hi I am trying to implement vault HA .I don't see ha_backend ,advertise_addr properties in erb file.

https://www.vaultproject.io/docs/config/#ha_backend

Hi Guys,

would it be possible to create a new release with this property?

Thanks,
Pawel

The sample manifest uses file storage in /var/vcap/jobs/vault, which is ephemeral storage. Additionally, the sample manifest deploys 3 instances. Targeting a different instance won't maintain data consistency.

Hi all,

New to Vault, still trying to wrap my head around it. As I understand it, Vault automatically seals itself on restart as it doesn't persist the unseal keys. While more secure, this seems like a rough match for the BOSH deployment process as bumping a stemcell results in Vault downtime until a human or multiple humans run vault unseal.

Any thoughts on adding automatic unsealing to this release to allow a more usual BOSH workflow or would that be sacrificing a valuable security feature? Related thread on Vault GH here: hashicorp/vault#72.

Please create a new release with Vault binary in version 0.6.2. Right now it is 0.6.0

Reading the 1.0.0 release, and need some help to piece the config together.

The storage "consul" example shows "cluster_address", I think it should be "cluster_addr", based on the documentation.

Thanks
Yansheng

Add a new property to the vault job, vault.ha.name that defaults to vault-(index). The new property will be evaluated on a per-job basis, replacing the following:

• (deployment) becomes the deployment name
• (job) becomes the job name
• (index) becomes the instance index

Set the VAULT_ADVERTISE_ADDR to the final value, for HA backends to use for redirection.

This will allow sites with HA configured to handle redirection after a change in leadership.

For example, in a 3-node Vault cluster with a vault.ha.name of vault-(index).example.com, users can access vault-0.example.com, and be transparently redirected to vault-2.example.com

Introduce a new property, config that contains a big long string of HCL to inject into the config.

This will allow us to retire 80% of the properties in this BOSH release, while allowing tinkerers to tinker to their tinkering hearts' content. People who want a stable, curated Vault should look at the safe BOSH release (https://github.com/cloudfoundry-community/safe-boshrelease).

Once we have a release with the config support, that people can migrate via, we'll deprecate the old custom backend properties, bump major version and cut a new release.

Hi team,

This BOSH release is still in use on a project I'm currently work on and we'd really benefit from support for Vault 1.13. Are there any plans to support this version?

Many thanks!

Could you cut a new release?
I would like to use the official release instead of my fork with google cloud support.. :)

Time to release #51.

• Write / Review Release Notes
• Write / Review migration process in README
• Fix CI
• Bump Major Version
• Announce in #vault channel

thoughts on pushing a release for it?

Consider VMs have to be deployed in different availability zones with each VM have a static IP assigned. In this case the deployment fails.
Also, There can be a sample "working" manifest.

Hi there,

We're using this bosh release and would like to upgrade to the most recent version of vault. Is this project still maintained? I don't have any experience with bosh releases myself, so I am a bit lost with this.

Thanks a bunch!