Search code examples
node.jsgithubopenshiftapp-secret

Read secrets inside of Redhat OpenShift online?

I have gotten a Redhat OpenShift online starter vps, for hosting my discord bot. I've uploaded it to github, minus my discord token and other API keys, of course :^)

How would I get OpenShift to use store and read client secrets? I'm using the nodejs8 framework if that helps.

Solution

  • Secrets have no place in a source version control hosting service like GitHub.

    Regarding OpenShift, it includes Secrets, an encoded-64 configmap in which you can inject confidential information.

    But that long-term confidential information storage (to be injected in OpenShift secrets) ought to be stored in a proper Vault.

    Like, for instance, the Hashicorp Vault, as described by the article "Managing Secrets on OpenShift – Vault Integration"

    The rest describes that solution, but even if you don't use that particular host, the general idea (an external vault-type storage) remains:

    https://i2.wp.com/blog.openshift.com/wp-content/uploads/vault-1.png?w=1486&ssl=1

    1. An Init Container (run before the main container of a pod is started) requests a wrapped token from the Vault Controller over an encrypted connection.
      Wrapped credentials allow you to pass credentials around without any of the intermediaries having to actually see the credentials.
    2. The Vault Controller retrieves the pod details from the Kubernetes API server.
    3. If the pod exists and contains the vaultproject.io/policies annotation, the Vault Controller calls Vault and generates a unique wrapped token with access to the Vault policies mentioned in the annotation. This step requires trust on pod author to have used to right policies. The generated token has a configurable TTL.
    4. The Vault Controller “calls back” the Init Container using the pod IP obtained from the Kubernetes API over an encrypted connection and delivers it the newly created wrapped token. Notice that the Vault Controller does not trust the pod, it only trusts the master API.
    5. The Init Container unwraps the token to obtain a the Vault token that will allow access to the credentials.
    6. The Vault token is written to a well-known location in a volume shared between the two containers (emptyDir) and the Init Container exits.
    7. The main container reads the token from the token file. Now the main container can use the token to retrieve all the secrets allowed by the policies considered when the token was created.
    8. If needed, the main container renews the token to keep it from expiring.