Fernet keys should not be hardcoded
Bug #1651392 reported by
Boris Bobrov
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
fuel-ccp |
Fix Committed
|
High
|
Dmitry Klenov |
Bug Description
Fernet keys are now hardcoded like this: https:/
information type: | Private Security → Public Security |
Changed in fuel-ccp: | |
assignee: | nobody → Dmitry Klenov (dklenov) |
status: | New → Triaged |
importance: | Undecided → High |
Changed in fuel-ccp: | |
status: | In Progress → Fix Committed |
To post a comment you must log in.
Basing on various customers input we should consider more generic security requirements:
1. Keys, passwords and secrets should never be tied to the Fuel CCP source code
2. Fuel CCP or k8s is able to utilise a HSM to store secrets
However Fuel CCP, Keystone nor Kubernetes don't use HSM currently. Reasonable solution is to propose a compensating control and store secrets encrypted on local disk. To further protect secrets from compromisation utilize multiple encryptions approach as described in OWASP methodology.
The proposed solution is to store Fernet keys and all other qualifying secrets on LUKS encrypted drive. This satisfies DEK and KEK security requirement. In case customer requests additional hardening this allows to store LUKS KEK on security validated key, e.g. Yubico.
Summary:
- Store Fernet DEK key on LUKS encrypted drive
- Store LUKS KEK key locally, which is good enough for Dev and POC purposes
- For production deployments store LUKS KEK in locally attached Yubico or at least passphrase protected key
References: /www.owasp. org/index. php/Cryptograph ic_Storage_ Cheat_Sheet /www.howtoforge .com/automatica lly-unlock- luks-encrypted- drives- with-a- keyfile# howto-automatic ally-unlock- luks-encrypted- drives- with-a- keyfile /www.howtoforge .com/ubuntu- two-factor- authentication- with-yubikey- for-harddisk- encryption- with-luks
https:/
https:/
https:/