Figgy manages the confidentiality of configurations in two main ways.
- Access control
With Figgy you can create as many arbitrary user types as you'd like. We recommend you consider the different user stories you have in your organization first before defining them. In most cases, you'll have at least three or four:
- Ops / Devops
- Super Admins
Other common roles:
- Data Scientist
- Data Engineer
With user types (also known as
roles), you can carve up access however you like and across as many fig trees as you want. In
an example basic configuration, access looks like this:
- Developers: - `/app/*` - `/shared/*` - DevOps - `/app/*` - `/shared/*` - `/devops/*` - DBAs - `/app/*` - `/shared/*` - `/dba/*` - Super Admins - `/app/*` - `/shared/*` - `/devops/*` - `/dba/*`
Within these roles, each type may have access to leverage 1 or more KMS keys for encrypting their secrets. For demonstrative purposes, here are some minimum recommended default encryption keys:
- devops / ops
As you can see, in this minimum example, each key maps to a single user-group. It's easy, tidy, and adds an extra layer of security on top of access-control. But the magic is with the replication key.
The replication key#
The replication key is a special key used by Figgy that enables the secure sharing of secrets between secret-owners and the applications who need them.
Here is an example of how it is used. Suppose Jim, our
message-fetcher developer needs access to our super-secret
RabbitMQ password but doesn't have access to it. Mariah, our glorious DevOps engineer, has the user
and password Jim needs. First Mariah stores the values in the
/devops namespace and encrypts the values with the
devops KMS key.
Mariah stores these values
Store the value#
Next Mariah will share the value directly to Jim's
message-fetcher service. Jim will not have access to this
secret in higher environments, but the
Share the value#
The secret will now be shared
When Figgy performs the share, the parameter is decrypted and re-encrypted with the
Access to the replication key should only be given to services consuming these secrets.
In this example, Jim, the developer, does not have access to the replication key in production. We have now successfully shared a secret directly with the interested party and cut-out the middle-man. For IAM policy examples to support this example, see the IAM Cookbook