update security section of docs

docs/architecture.md

@@ -8,6 +8,9 @@ environment).
 * The `caffeine` host provides the `/api/db` endpoints. This is because
   the root account of MySQL and PostgreSQL on caffeine can only be accessed
   locally.
+* The `cloud` host provides the `/api/cloud` endpoints. This is because the
+  NGINX vhost files need to be created on the host where the cloud NGINX
+  server is running.
 * All other endpoints are provided by `phosphoric-acid`. phosphoric-acid is the
   only host with the `ceod/admin` Kerberos key which means it is the only host
   which can create new principals and reset passwords.
@@ -41,13 +44,20 @@ not worth it if ceo is the only app which will use it.
 Therefore, we will use unconstrained delegation. The client essentially
 forwards their TGT to ceod, which uses it to access other services over GSSAPI
 on the client's behalf. We accomplish this using GSSAPI delegation (i.e. set
-the GSS_C_DELEG_FLAG when creating a security context).
+the GSS\_C\_DELEG\_FLAG when creating a security context).
 
 Since the client's credentials are used when interacting with LDAP, this means
 that most LDAP-related endpoints can actually be accessed from any host.
 Only the Kerberos-specific endpoints (e.g. resetting a password) truly need
 to be on phosphoric-acid.
 
+As of this writing, there are two endpoints where the ceod/admin credentials
+are used instead: creating new members, and renewing existing members. This
+is because office staff need to be able to use these endpoints, and allowing
+them to directly create new LDAP records would be a privilege escalation;
+allowing them to directly modify the shadowExpire field is undesirable as
+well because this could prevent syscom members from logging in.
+
 ### Authentication
 The REST API uses SPNEGO for authetication via the HTTP Negotiate
 Authentication scheme (https://www.ietf.org/rfc/rfc4559.txt). The API