Secrets in K8s with JHipster

[Matt Raible]

Hello everyone,

I have a microservices environment setup with OIDC values being read from GitHub.

https://github.com/mraible/reactive-java-ms-config/blob/main/config/application.yml

I think it’d be more secure if my GitHub repo was private, but since my secret is encrypted, I’m not too concerned.

I created this encrypted value by adding a .env file in my docker-compose directory with the following value:

ENCRYPT_KEY=asdfasdfa

Then, I modified my docker-compose.yml file for the JHipster Registry to read this value.

environment:

  ...
  - SPRING_CLOUD_CONFIG_SERVER_COMPOSITE_0_TYPE=git
  - SPRING_CLOUD_CONFIG_SERVER_COMPOSITE_0_URI=https://github.com/mraible/reactive-java-ms-config/
  - SPRING_CLOUD_CONFIG_SERVER_COMPOSITE_0_SEARCH_PATHS=config
  - SPRING_CLOUD_CONFIG_SERVER_COMPOSITE_0_LABEL=main
  - ENCRYPT_KEY=${ENCRYPT_KEY}

Now, I want to deploy everything with k8s. What’s the best way to set my ENCRYPT_KEY? I don’t want to do it in YAML files because I’ll likely check those in. 

I watched this talk from FOSDEM 2021 that seems to recommend sealed secrets.

https://fosdem.org/2021/schedule/event/kubernetes_secret_management/

https://github.com/bitnami-labs/sealed-secrets

I want to figure out the easiest, yet secure, way to store secrets for JHipster when running in k8s. Any advice is appreciated!

Thanks,

Matt

[Julien Dubois]

Hi Matt,

You can use k8s secrets. I put them in an "application.yml" file that I mount in the application's home folder, and that's picked up automatically by Spring Boot at startup. It's easy and secured, but not hugely practical, so it's mostly for secrets, not for all configuration properties.

Julien

--
You received this message because you are subscribed to the Google Groups "JHipster dev team" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jhipster-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jhipster-dev/BC089C8B-58D0-403D-9940-4BB12A4D995E%40raibledesigns.com.

--

Julien Dubois

Twitter: @juliendubois

[David Steiman]

Hey Matt,

AFAIK we do the same stuff for the ${jhipster-registry.password} in our k8s sub generator. You can check it out there, but in short, here is how it works:

        env:
            # ...
            - name: SPRING_SECURITY_USER_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: registry-secret
                  key: registry-admin-password

and then you just store a secret like this:

apiVersion: v1
kind: Secret
metadata:
  name: registry-secret
  namespace: kloud
type: Opaque
data:
  registry-admin-password: YWRtaW4= # base64 encoded "admin"

we use this approach also for database credentials.

Hope that helps

cheers

To view this discussion on the web visit https://groups.google.com/d/msgid/jhipster-dev/CADNXADHPyvw84yOzWM8KO6ABpK8z6whxAxsnCKnDP7deMdz9ZA%40mail.gmail.com.

[Matt Raible]

I've seen the existing secrets configuration, which doesn't seem secure at all. It's just base64 encoded strings. If I check in my K8s YAML files, it's pretty much the same as checking in plain text. 

I'd like a solution that actually encrypts the strings so there's no chance of others discovering my secrets when browsing my app's repo.

Maybe I'm missing something and being too paranoid?

On Apr 28, 2021, at 01:13, David Steiman <adina...@gmail.com> wrote:



[Pierre Besson]

Hello Matt,

This is a great question which I assume a lot of ops team are familiar with.

Sealed-secrets is a solution, however, in my experience, it is not very easy to use for developers. The way it works is that it will provision an encryption key in your kubernetes cluster as well as an operator that will convert your encrypted SealedSecret in a matching decrypted Secret. Last time I used it, it was cumbersome to use due to lack of tooling.

Another simple way to encrypt/decrypt secrets committed to your git repo is using sops (https://github.com/mozilla/sops). The tool can be used with your own gpg keys or a KMS service. The workflow with sops is the following : when the user is authenticated to their cloud provider KMS service, they are able to seamlessly encrypt/decrypt their secrets in their sops encrypted file by simply running: `sops my-secrets.yaml`. This will decrypt and open the file in a text editor and when they save it, it will encrypt it again and save it back to the disk. Then to deploy such an encrypted secret, you could do something like : `sops --decrypt my-k8s-secret | kubectl apply -f -`

Hope this helps.

Best regards,

Pierre

To view this discussion on the web visit https://groups.google.com/d/msgid/jhipster-dev/068B5FD3-8116-414B-BDE8-A2AAFA7F602E%40raibledesigns.com.

[Matt Raible]

Hello team,

I tried Sealed Secrets and found it worked quite well when used with the JHipster Registry and its encryption feature.

I just finished writing the first draft of a blog post on JHipster + K8s with HTTPS and secrets. If you have time, please checkout the PR (https://github.com/oktadev/okta-blog/pull/778) and preview (https://deploy-preview-778--okta-blog.netlify.app/blog/2021/05/18/reactive-java-kubernetes). Any comments or suggestions are most welcome!

In my next post, I hope to use something like Spinnaker (https://spinnaker.io/) to add continuous delivery to this project. It seems like we might be missing something like this in our CI/CD generator. If there’s a better solution for CD with K8s, please let me know.

Cheers,

Matt