These are chat archives for spring-cloud/spring-cloud

30th
Oct 2018
Anders Engström
@andersenleo
Oct 30 2018 16:04
Howdy all! In the process of upgrading some code to Finchley.SR2 and is running into an issue with spring-cloud-consul-discovery.. Trying to start an app with service registration only (with spring.cloud.consul.discovery.register=true and spring.cloud.consul.discovery.enabled=false), but this fails. The only (?) way to get it to register the service is to set spring.cloud.consul.discovery.enabled=true (but then it tries to lookup other services which is not what we want). This worked before the upgrade (Finchley.SR1). Should also mention that we’re bumping SpringBoot from 2.0.4 to 2.1.0.
Any ideas? :point_up:
Spencer Gibb
@spencergibb
Oct 30 2018 19:56
@andersenleo spring cloud doesn't support boot 2.1.0 yet
Eric Deandrea
@edeandrea
Oct 30 2018 20:16
What about spring-cloud-starter-config? will that work with boot 2.1.0?
springroll12
@springroll12
Oct 30 2018 20:32
Other than having multiple configuration sources available, are there any downsides to using spring-cloud-vault over spring-cloud-config? If you want to use a vault back end for spring cloud config for secrets it seems like a no-brainer.
Eric Deandrea
@edeandrea
Oct 30 2018 20:34
the main difference with spring-cloud-vault is that each and every client has to have their own token within vault and that token has to be sent via the X-Config-Token header with each request to vault, whereas with config server you can look at property values in a browser without any kinds of headers necessary from the client
config server makes it really easy to serve configuration properties for even non-spring boot clients
plus with config server you can store/serve non-property file/yml formats (http://cloud.spring.io/spring-cloud-static/Finchley.SR2/single/spring-cloud.html#_serving_plain_text)
just my opinion - better to keep just secrets in vault since it has far greater control over who has read/write access to those secrets…better to keep everything else in config server
springroll12
@springroll12
Oct 30 2018 20:43
I don't see the benefits you are describing. Vault has an api, so it can expose secrets/configuration to any client as well. The fact that vault has token/approle authentication for configuration seems like a benefit to me as well.
(Any client that can read json)
Eric Deandrea
@edeandrea
Oct 30 2018 20:45
does every single property you need externalized in all your applications require that level of security?
springroll12
@springroll12
Oct 30 2018 20:45
No, definitely not.
Eric Deandrea
@edeandrea
Oct 30 2018 20:46
we use config server a ton for infrastructure configuration (apache/nginx config files, server configuration, etc)
springroll12
@springroll12
Oct 30 2018 20:46
Don't really need to protect feature toggles, but if I am running a vault server anyway...
How do you store secrets?
Eric Deandrea
@edeandrea
Oct 30 2018 20:48
we store secrets in vault
and non-secrets in config server
up until recently we were storing secrets in config server as well using encryption
until we had a stable vault environment

the things we store in vault are controlled by a level above the development teams…one set of teams have access to write, while applications have access to read (1 app can’t read another app’s secrets)

but config server is open to the developers (for non-prod). Dev teams can independently modify what is there

if everything was in vault there would be a huge bottleneck trying to get things put into vault
since it has a different set of ownership
Eric Deandrea
@edeandrea
Oct 30 2018 20:56
so for us its about process as well…each tool has a different process & set of actors playing different roles around it
springroll12
@springroll12
Oct 30 2018 21:14
How do you populate secrets in your cluster from ci/CD? I assume the vault instance is inside your cluster? How did initial/condig-service-update-time secrets/config population work when using spring cloud config encryption?