Designing for Operations - The Practice of Cloud System Administration - page 37

Case Study: ACLs at Google
Google's Remote Procedure Call (RPC) protocol, used by all internal APIs, has a
powerful ACL system. Connections are authenticated via a PKI so that the service
is assured of the client's identity and knows which groups that client is a member
of. Identity and groups are globally defined and represent products and services as
opposed to individual external customers. The ACLs specify the access allowed
for that individual or group: permit, deny, or permit with a rate limit. Teams nego-
tiate QPS rates for accessing a service as part of the service's capacity planning.
Teams that have not negotiated rates get access but at a very low rate limit. This
enables all teams to try out new services and eliminates the need for the service
team to expend effort negotiating hundreds of lightweight or casual use requests.
2.1.12 Data Import Controls
If a service periodically imports data, mechanisms should be established that permit opera-
tions staff to control which data is accepted, rejected, or replaced.
The quality of incoming data varies, and the system importing the data needs a way to
restrictwhatisactuallyimportedsothatknownbaddatacanbedisregarded.Ifabadrecord
causesaproblemwiththesystem,onemustbeabletoblockitviaconfigurationratherthan
waiting for a software update.
Such a system uses the same whitelist/blacklist terminology we saw earlier. A blacklist
is a way of specifying input that is to be rejected, with the assumption that all other data is
accepted. Awhitelist isusedtospecifydatathatistobeaccepted; allotherdataisrejected.
In addition to control the incoming data stream, we need a way to augment an imported
data source with locally provided data. This is accomplished using an augmentation file of
data to import.
Establishing a change limit can also prevent problems. For example, if a weekly data
import typically changes less than 20 percent of all records, one might want to require
manual approval if the change will affect 30 or more percent of all records. This can pre-
vent a disaster caused by a software bug or a bad batch of new data.