Bug 2184987

Summary: To be able to read the VAULT_TOKEN from a file
Product: [Red Hat Storage] Red Hat OpenShift Data Foundation Reporter: Amrita Mahapatra <ammahapa>
Component: rookAssignee: Santosh Pillai <sapillai>
Status: CLOSED WONTFIX QA Contact: Neha Berry <nberry>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 4.12CC: odf-bz-bot, tnielsen
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-08-15 15:30:28 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Amrita Mahapatra 2023-04-06 12:05:59 UTC
Description of problem (please be detailed as possible and provide log
snippests): We may be able to read the VAULT_TOKEN from a file. This bug is opened as per the discussion,https://bugzilla.redhat.com/show_bug.cgi?id=2144067#c19

The following output was observed in odf-operator.v4.12.2-4 build.

KMS:

----
> rook-ceph-osd-2-59cd6766-5lsxk
> 
>     name: ROOK_CEPH_MON_HOST
          valueFrom:
            secretKeyRef:
              name: rook-ceph-config
              key: mon_host
        - name: CEPH_ARGS
          value: '-m $(ROOK_CEPH_MON_HOST)'
        - name: ROOK_BLOCK_PATH
          value: >-
            /dev/mapper/ceph-f3f8dcc8-af16-4248-9e6e-5c8b4b67c3a7-sdc-block-dmcrypt
> --
>     - name: VAULT_SECRET_ENGINE
          value: kv
        - name: VAULT_TLS_SERVER_NAME
        - name: VAULT_TOKEN
          valueFrom:
            secretKeyRef:
              name: ocs-kms-token
              key: token
>     image:
> quay.io/rhceph-dev/odf4-rook-ceph-rhel8-operator@sha256:61195766bf12f6f3a7bd9b6fb13ca3d3f3f08dff2b20dd9f38720f613f5c65a2 

Version of all relevant components (if applicable):
ODF version: 4.12.2-4
OCS verion: 4.12.0-0.nightly-2023-04-06-023554


Does this issue impact your ability to continue to work with the product
(please explain in detail what is the user impact)? No


Is there any workaround available to the best of your knowledge? NA


Rate from 1 - 5 the complexity of the scenario you performed that caused this
bug (1 - very simple, 5 - very complex)?
1

Can this issue reproducible? Yes


Can this issue reproduce from the UI? NA


If this is a regression, please provide more details to justify this:


Steps to Reproduce:
1.
2.
3.


Actual results:


Expected results:


Additional info:

Comment 2 Travis Nielsen 2023-04-06 20:50:06 UTC
Based on the discussion here: https://bugzilla.redhat.com/show_bug.cgi?id=2144067#c19
The purpose of this BZ would be to investigate if there are any KMS-related sensitive keys that we are loading as environment variables, which should instead be loaded from a file in the pod. Reading a file from inside the pod will be better from a security view because environment variables are sometimes logged unintentionally. 

If the secret were mounted as a file inside the pod, rook would need to read it from a file instead of with the environment variable. 
The change could be similar in nature as PR https://github.com/rook/rook/pull/11434 where some mon secrets were changed from an env var to be read from a file.
@Santosh, please investigate if it is feasible to change this implementation, but for 4.14 should be sufficient.
Or if it is too big of a change we should consider closing this since the security risk is only theoretical.