Hide Forgot
1. Proposed title of this feature request RFE: Prevent showing encoded secret data from command(or API) access 3. What is the nature and description of the request? Currently OpenShift secret values are encoded by base64. We can get them by "oc get secrets mySecret -o yaml" and decode the data very easily. The customer wants to prevent showing the (encoded) secret data from any API access. 4. Why does the customer need this? (List the business requirements here) One of the customers want to run payment applications on OpenShift and they don't want to protect database passwords strictly. 7. Is there already an existing RFE upstream or in Red Hat Bugzilla? It is not same bz, but we filed bz#1400841 to encrypt data. That is same goal for us to use secret data securely. 8. Does the customer have any specific timeline dependencies and which release would they like to target (i.e. RHEL5, RHEL6)? The customer requested 1Q 2017.
Are you asking not to show the value in its encoded state? Or just to not show the value in its decoded state? https://bugzilla.redhat.com/show_bug.cgi?id=1400841 will already cover not showing the value in its decoded state unless you are in the container.
> Are you asking not to show the value in its encoded state? Yes, I am asking the value in its encoded state. And yes, bz#1400841 can cover this RFE, but there are two reasons why I asked: 1. Even "oc get secrets" and "oc describe secrets/<SECRET_NAME>" hides the contents like output below, I don't understand why "oc get pod secret -o yaml" output the secret so easily? - k8s's doc says "This is to protect the secret from being exposed accidentally to someone looking or from being stored in a terminal log."[1], then "oc get secrets -o yaml" also should hide them. $ oc describe secret mysecret ... Data ==== password: 11 bytes username: 9 bytes 2. The customer needs this feature or bz#1400841 by 1Q 2017 (that's tight schedule). So, I thought that this ticket(bz#1400847) can be easily implemented rather than bz#1400841 [1] http://kubernetes.io/docs/user-guide/secrets/#creating-a-secret-using-kubectl-create-secret
So we can't do anything about direct API access like oc get secret -o yaml or the "Edit YAML" option in the console, unless the API itself does not return the secret content. This is not something that can or should be solved on the clients. If in the short term there were no API changes, I have a question for the mgmt console. In the mgmt console you must explicitly choose to reveal the contents of the secret, are you saying you would want to prevent a user from being able to reveal the secret? Keep in mind there is nothing stopping someone from going into the browser network traffic and looking at the content, or from using the Edit YAML action to view the content.
Actually I thought "Edit YAML" option in the console is also not a secure way, and wanted you to be fixed. Even though any general web sites/services are using password masking to protect a user from shoulder surfing or some accidents, OpenShift Console are showing the secret data with only base64 encoding. We are saying that database password should be stored as a secret data, aren't we?
The API is returning the data. There is nothing we can do about that from the clients. If the concern is the ability of people to find ways to get to that base64 encoded data, then the ONLY answer is to change the APIs. If that is what you are asking for, this request has to be transferred to a different team.
Sending to Platform mgmt
We can't hide the secrets in CLI (the content is not displayed anyway unless you pipe it trough base64 -d). Also there is no effective way to hide the secrets entirely (there will always be a way to see them) unless you have external secret store (but that won't help you either, just make the job to gaining access to secrets harder).