Bug 2184987 - To be able to read the VAULT_TOKEN from a file
Summary: To be able to read the VAULT_TOKEN from a file
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat OpenShift Data Foundation
Classification: Red Hat Storage
Component: rook
Version: 4.12
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
: ---
Assignee: Santosh Pillai
QA Contact: Neha Berry
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-04-06 12:05 UTC by Amrita Mahapatra
Modified: 2023-08-15 15:30 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-08-15 15:30:28 UTC
Embargoed:


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.