As BOSH evolves, grows, and improves, it allows you to focus on making your deployments more secure. The addition of config server allows you to generate, store, and update credentials easily and securely for your deployments. It also allows you to share credentials between deployments, as it is possible to have hundreds for all components to talk to each other. It will also help prevent poor credential choices, which can create security breaches. This talk will go into details about how config server works, how credential generation and storage is handled, and how you can use the reference implementation to choose your own credential generation and storage strategy.

1. Title / Subtitle Here
Configuring
a
more
secure
BOSH
Core
Project
Updates
Saman
Alvi
&
Dale
Wick
-­‐
Core
BOSH
Contributors

2. • Saman Alvi
• salvi@pivotal.io
• @err_sage
• Dale Wick
• dwick@pivotal.io
• @hardhatpsp
Who are we?

3. What problems are we solving?
How does it work?
How do you use it?
Integration with legacy systems
Future
Securing your BOSH Deployments with Variables

4. Securing your BOSH Deployments with Variables
What problems are we solving?
How does it work?
How do you use it?
Integration with legacy systems
Future

5. Sensitive / secret information stored in manifests
Problem #1

6. Weak passwords, reused certificates
Problem #2

7. Static manifests for different staging environments
Test Dev Prod
Problem #3

8. Difficult and error prone to rotate sensitive information
Problem #4

9. No separation between credential and deployment management
Problem #5

10. config-server-api

11. What problems are we solving?
How does it work?
How do you use it?
Integration with legacy systems
Future

12. • Passwords, Properties
• A value you do not want in plain text
• A value that is subject to change
A variable is a named parameter that has a value
Variables

13. Variables can have a type
A type may require options (eg. certificate)
Variable Types

14. password: “s3cr3t!” password: password

15. At deploy time
3. Substitutes values into manifest
Operator
1. Specifies variables and values
cli
2. Parses variables
Director
Deployment Runtime Cloud Config
Variable values can be specified by the operator via CLI
Variable Values

16. At deploy time
2. request variable values
3. return generated or existing values
1. Parse variables
Director
Deployment Runtime Cloud Config
Variable values can be generated by the Config Server
Config Server
* stores generated values
Variable Values

17. What problems are we solving?
How does it work?
How do you use it?
Integration with legacy systems
Future

18. Latest BOSH release and new BOSH CLI
properties:
director:
config_server:
enabled: true
url: ...
uaa: ...
Config Server Release
How do you use it?

19. jobs:
- name: db:
release: postgres
properties:
username: “((db_user))”
password: “((db_password))“
- name: director:
release: bosh
properties:
ssl:
key: “((private_key))”
cert: “((certificate))”
The variable that will be substituted
goes inside the (( ))
Variable Values

20. $ bosh -e dev -d my_dep
-v internal_ip=192.168.50.6
-v max_conn=10
networks:
…
static: [((internal_ip))]
…
properties:
redis:
max_connections: “((max_conn))”
Specify variable values using command line flags
Variable Values

21. Generate variable values via the Config Server
bosh deploy
db_password
jobs:
- name: db:
release: postgres
properties:
username: “admin”
password: “((db_password))“
variables:
- name: db_password
type: password
Variable Values

22. Variables with nested values will require the use of a “.”
Certificates, SSH & RSA keys
Variable Values

23. Generate variables
bosh deploy
ssl
variables:
- name: ssl
type: certificate
jobs:
- name: director:
release: bosh
properties:
ssl:
key: “((ssl.private_key))”
cert: “((ssl.certificate))”
"id": "22",
"value": {
“certificate”: “CA Certificate…”,
"private_key": “Private Key…”,
“ca": “CA…”
}
options:
is_ca: true,
common_name: “bosh.io”
Variable Values

24. Generating certificates & certificate chaining
variables:
- name: default_ca
type: certificate
options:
is_ca: true
common_name: “bosh”
jobs:
- name: director:
release: bosh
properties:
ssl:
key: “((director_ssl.private_key))”
cert: “((director_ssl.certificate))”
bosh deploy
default_ca
director_ssl
- name: director_ssl
type: certificate
options:
ca: default_ca
common_name: ((internal_ip))
Variable Values

25. Share variables across deployments
name: deployment_1
jobs:
- name: datadog-agent:
release: datadog-agent
properties:
api_key: “((/dd_api_key))”
Variables beginning with ‘/’ can be shared across multiple deployments
name: deployment_2
jobs:
- name: datadog-agent:
release: datadog-agent
properties:
api_key: “((/dd_api_key))”
name: deployment_3
jobs:
- name: datadog-agent:
release: datadog-agent
properties:
api_key: “((/dd_api_key))”
Variable Values

26. Operator
$ bosh -e dev -d dep.yml --vars-store ./creds.yml
nats_password: qdbzr3marbv0x2jp6ihs
ssl:
ca: |
—-BEGIN CERTIFICATE ….
private_key: |
—-BEGIN RSA PRIVATE KEY …
certificate: |
—- BEGIN CERTIFICATE …
jobs:
- nats:
release: bosh
properties:
username: “admin”
password: “((nats_password))“
- director:
release: bosh
properties:
ssl.key: “((ssl.private_key))”
ssl.certificate: “((ssl.certificate))”
variables:
- name: nats_password
type: password
- name: ssl
type: certificate
vars-store - Your local Config Server

27. $ bosh create-env ~/workspace/bosh-deployment/bosh.yml
--state ./state.json
--vars-store ./creds.yml
-v director_name="Bosh Lite Director"
-v internal_ip=192.168.50.6
-v internal_gw=192.168.50.1
-v internal_cidr=192.168.50.0/24
-v outbound_network_name=NatNetwork
$ bosh create-env

28. $ bosh -e dev -d my_dep variables
ID Name
22 /director_name/deployment_name/variable_name
23 /director_name/deployment_name/variable_name2
* subject to change to guid in the future, do not rely on this format
Only variables referenced by Config Server show up in this list
Variables

29. What problems are we solving?
How does it work?
How do you use it?
Integration with legacy systems
Future

30. BOSH uses the Config Server API to communicate with Config Server
API
implements talks to
System Integrations

31. Credhub
• Recommended production implementation
• Implements Config Server API
• Encryption through HSM
Credhub

32. YOURS!
Credhub

33. What problems are we solving?
How does it work?
How do you use it?
Integration with legacy systems
Future

34. • String
• Number
• Object
• Array
• Boolean
• Null
1. Set validated types for variables
• Generated certificates belonging to jobs
will have their SANs and Common Name be
managed by BOSH
2. Certificate DNS names and jobs
Future
* releases as well

35. Credhub

36. Get started with…
Credhub
• github.com/cloudfoundry/config-server-release
• github.com/cloudfoundry/config-server/blob/master/docs/api.md
• bosh.io/docs/cli-int.html
• github.com/cloudfoundry/bosh-deployment
• github.com/cloudfoundry-incubator/credhub

37. In Conclusion…
variables =
s
+

38. DEMO

39. • Saman Alvi
• salvi@pivotal.io
• @err_sage
• Dale Wick
• dwick@pivotal.io
• @hardhatpsp
Questions?