summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJohn Warren <jswarren@us.ibm.com>2014-08-05 21:00:14 +0000
committerJohn Warren <jswarren@us.ibm.com>2014-09-19 14:35:33 -0400
commit979aeb5fa14b305264138dab591123903c19d7a8 (patch)
tree2963e1bb6b0f94d8f564da0f2bc1c2a0c657d8a0
parentef26dce50c3995bfcf711e13145a1e83a36a48cd (diff)
Keep sensitive information out of node attributes
Sensitive information stored in data bags (such as passwords) should not be stored as node attributes, because they are persisted back to the server and can therefore be easily retrieved. Change-Id: I26c1fc1d49a86d8f9ccb6f1a80af90a781c1a80c
Notes
Notes (review): Verified+2: Jenkins Code-Review+2: Mark Vanderwiel <vanderwl@us.ibm.com> Workflow+1: JJ Asghar <jj@getchef.com> Submitted-by: Jenkins Submitted-at: Mon, 22 Sep 2014 18:44:48 +0000 Reviewed-on: https://review.openstack.org/112141 Project: stackforge/openstack-chef-specs Branch: refs/heads/master
-rw-r--r--specs/juno/common/no-secret-attributes.rst178
1 files changed, 178 insertions, 0 deletions
diff --git a/specs/juno/common/no-secret-attributes.rst b/specs/juno/common/no-secret-attributes.rst
new file mode 100644
index 0000000..04aea21
--- /dev/null
+++ b/specs/juno/common/no-secret-attributes.rst
@@ -0,0 +1,178 @@
1=================================================
2Keep sensitive information out of node attributes
3=================================================
4
5https://blueprints.launchpad.net/openstack-chef/+spec/no-secret-attributes
6
7Sensitive information such as passwords should not be stored as node
8attributes, because they are persisted back to the server and can therefore
9be easily retrieved.
10
11Problem description
12===================
13
14Wrapped recipes (e.g. mysql::server) use node attributes for retrieving
15sensitive information, such as passwords associated with privileged
16accounts. This type of information is specified via items in encrypted
17data bags, but because node attributes are involved, the security provided
18by the encryption mechanism can easily be defeated by simply retrieving the
19node attributes from the server.
20
21For example (from mysql-server):
22
23::
24
25 if node['openstack']['db']['root_user_use_databag']
26 super_password = get_password 'user', node['openstack']['db']['root_user_key']
27 node.set_unless['mysql']['server_root_password'] = super_password
28 else
29 super_password = node['mysql']['server_root_password']
30 end
31
32The password is retrieved from a (possibly encrypted) data bag and stored
33into a node attribute to be consumed downstream by the :code:`server`
34recipe in the :code:`mysql` cookbook. After the node is converged, all
35someone needs to do to retrieve the password as clear text is execute
36:code:`knife node edit NODE_NAME`, thereby defeating a data bag's encryption
37capabilities.
38
39Proposed change
40===============
41
42The proposed solution is to operate on server resources directly or use
43run_state to set passwords, depending on which is available for use in
44a given recipe.
45
46Again, using MySQL as an example (operating directly on resource):
47
48::
49
50 if node['openstack']['db']['root_user_use_databag']
51 super_password = get_password 'user', node['openstack']['db']['root_user_key']
52 else
53 super_password = node['mysql']['server_root_password']
54 end
55
56 mysql_service node['mysql']['service_name'] do
57 server_root_password super_password
58 ...
59 end
60
61The password is stored only in a local variable and directly assigned to the
62:code:`mysql_service` resource's :code:`server_root_password` attribute.
63The :code:`mysql::server` recipe is not invoked and all of the other resource
64attributes are set directly as well (indicated via :code:`...`). Since the
65password is never stored as a node attribute, it cannot be retrieved via
66:code:`knife node edit NODE_NAME`. Note that other resource attributes (for
67instance :code:`port`) can still be set to node-attribute values and thus
68their default values can still be specified in :code:`attributes/default.rb`.
69Also note that the above example shows that a node attribute can still be
70used to store password information, if that is what the user wants to do.
71This is done by leaving the :code:`['openstack']['db']['root_user_use_databag']`
72set to its default value of :code:`false`.
73
74Alternatives
75------------
76
77One alternative would be to have the wrapped recipes fall back to default
78attribute values and set the resource attributes directly, as described at
79https://sethvargo.com/changing-chef-resources-at-runtime/. However, this
80is arguably a non-strategic workaround.
81
82Data model impact
83-----------------
84
85none
86
87REST API impact
88---------------
89
90none
91
92Security impact
93---------------
94
95Security would be improved because passwords would no longer be accessible
96as node attributes.
97
98Notifications impact
99--------------------
100
101none
102
103Other end user impact
104---------------------
105
106None. The recipes would be backward compatible because the mechanisms for
107specifying the databag type (encrypted or standard) and name and related
108node attributes needed to use data bags would remain unchanged. The only
109thing changing would be the mechanics of how the data contained in data
110bags is populated into the resources created by the recipes. Note that
111end users would still have the option to not use data bags at all.
112
113Performance Impact
114------------------
115
116none
117
118Other deployer impact
119---------------------
120
121none
122
123Developer impact
124----------------
125
126none
127
128Implementation
129==============
130
131Assignee(s)
132-----------
133
134* jswarren
135
136Work Items
137----------
138
139The known impacted recipes are:
140
141* cookbook-openstack-ops-database::mysql-server
142* cookbook-openstack-ops-database::postgresql-server
143* cookbook-openstack-ops-messaging::rabbitmq-server
144
145Dependencies
146============
147
148The cookbooks involved in setting up the resources in question need to
149provide a mechanism for setting passwords either as a resource attribute
150that can be set directly or as a run_state attribute. Other mechanisms
151that do not expose passwords as node attributes should also be acceptable.
152
153
154Testing
155=======
156
157The cookbooks in question would need to be tested to ensure that when
158data bags are used to specify passwords that the password values are not
159reflected in the attributes (if any) used for setting passwords. In other
160words, a given referenced cookbook or recipe might still allow the use
161of node attributes to set passwords in addition to the above-mentioned
162possible alternatives. However, when node attributes are not used to
163specify passwords, the passwords must then not be stored as node
164attributes by the referenced recipes.
165
166
167Documentation Impact
168====================
169
170Documentation should not change, since the blackbox behavior of the recipes
171should remain unchanged. The documentation associated with the referenced
172resource recipes may need to change when accommodations are made for
173alternative means of setting passwords, but those changes are orthogonal to
174the work described here.
175
176References
177==========
178