How to fix "Your JWT secret key is not set up, you will not be able to log into the JHipster" during the startup of jhipster-registry container - docker-compose

I am trying to launch a microservice application with Jhipster. Each of my services are run in docker containers. When jhipster-registry is starting up, I receive this error:
2019-06-18 18:58:39.066 INFO 1 --- [ main] i.g.j.r.security.jwt.TokenProvider : The JWT key used is not Base64-encoded. We recommend using the `jhipster.security.authentication.jwt.base64-secret` key for optimum security.
2019-06-18 18:58:39.067 ERROR 1 --- [ main] i.g.j.r.security.jwt.TokenProvider :
----------------------------------------------------------
Your JWT secret key is not set up, you will not be able to log into the JHipster.
Please read the documentation at https://www.jhipster.tech/jhipster-registry/
This causes the jhipster-registry service to exit with a code of 1.
However, my application.yml file currently contains a base-64 jwt secret key:
jhipster:
security:
authentication:
jwt:
base64-secret: MjNiZjdiNDk5MGM4MjE4ODI4YzRiNjZkOTRhNTU3YmNkMWRmMWYxMzkzYjAzMzI5OWI0MzNjNzVmZjg0ZDRkNDkwOTNkNjlmNjU4Zjc0NmEyYTQ3NzViMWIzZTliYjNkNjI5ZQ==
I am currently using the docker image jhipster/jhipster-registry:v5.0.1. I have tried using v5.0.2 and the error persists. I have also tried changing my application.yml to include an empty secret parameter like so, but this didn't result in any change.
secret:
base64-secret: MjNiZjdiNDk5MGM4MjE4ODI4YzRiNjZkOTRhNTU3YmNkMWRmMWYxMzkzYjAzMzI5OWI0MzNjNzVmZjg0ZDRkNDkwOTNkNjlmNjU4Zjc0NmEyYTQ3NzViMWIzZTliYjNkNjI5ZQ==
I also tried the solution suggested in How to fix Invalid JWT with JHipster Registry [Docker]?
and it did not work for me. My docker-compose.yml and application.yml are exactly the same as the other people on my team and the registry service launches fine for them. How do I resolve this error?
EDIT: This started happening after I changed my Windows password.

Probably your Docker hasn't acces to the Filesystem where the config lies.
In my case the Firewall was blocking the access.
Check your Docker Desktop installation:
Docker Desktop -> Settings -> Shared Drives -> Reset credentials -> re-enter your new data.

Go to your Docker Desktop settings and under Shared Drives see if you've selected the drives you want to share with Docker.

Related

Keycloak admin console not working internal it gives "Loading the admin console"

I am having keycloak installed and working in Prod and we are currently migrating to Kubernetes(EKS) so I used Bitnami chart and used the same config as in Prod but admin console not working internally I tried version 19.0.0 and 20.0.0
here is the keycloak config
KC_HTTPS_KEY_STORE_FILE: **
KC_PROXY: edge
KC_DB: postgres
KC_DB_URL_HOST: **
KC_DB_USERNAME: ***
KC_HOSTNAME: public_url
KEYCLOAK_ADMIN: admin
KEYCLOAK_HOSTNAME: public_url
PROXY_ADDRESS_FORWARDING: true
KK_TO_RMQ_URL: **
KK_TO_RMQ_USERNAME: **
KK_TO_RMQ_PASSWORD: **
KEYCLOAK_IDENTITY_URL: **
KC_HOSTNAME_STRICT: true
KC_HOSTNAME_ADMIN: internal_url
in the Docker file I give start --proxy edge
here is the error that comes in the browser
Timeout when waiting for 3rd party check iframe message.
Error: A listener indicated an asynchronous response by returning true, but the message channel closed before a response was received
I am trying to get keycloak admin console to work internally but it keeps loading forever without opening the admin dashboard
I also tried the fix on the thread Keycloak admin console loading indefinitely
but it didn't help
I am able to fix the issue, and here is the solution explained:
I removed the admin console internal connection configuration to dig more
I was using Bitnami chart for keycloak in the Bitnami chart there is a config like that
containerSecurityContext:
enabled: true
runAsUser: 1001
runAsNonRoot: false
as keycloak needs to create tmp folder for caching the css and js files it was not able to create it
KC-SERVICES0075: Failed to get theme request: java.lang.RuntimeException: Temporary directory /opt/keycloak/bin/../data/tmp does not exist and it was not possible to create it
so I disabled this feature in bitnami
containerSecurityContext:
enabled: false
set the user in the image as keycloak or any other privileged user
and that's it, now working as a charm.

Keycloak development instance: broken authentication configuration

I'm running a local h2 based development instance of keycloak (quarks one). I've been trying to add another custom means of login and I seem to have broken it.
I've changed the First Broker Login Flow and disabled the Review Profile(review profile config). I cannot login anymore. I get his error in the keycloak instance console when going into the login screen:
WARN [org.keycloak.authentication.DefaultAuthenticationFlow] (executor-thread-12) REQUIRED and ALTERNATIVE elements at same level! Those alternative executions will be ignored: [auth-cookie, null]
2022-09-25 10:50:38,131 WARN [org.keycloak.services] (executor-thread-12) KC-SERVICES0013: Failed authentication: org.keycloak.authentication.AuthenticationFlowException
Is there a way to revert this change through some config file / h2? Or do I just have to delete keycloak and start from scratch?
Thanks in advance
You can delete h2 related files from data/h2 directory. Though you will lose the configuration which you have done.

Does Server -dev mode store the data in windows

I tried running the vault server in local with dev mode option. I got a root token which i exported to the environment variables. But once I stopped the server and started it it said *Invalid Request, Unable to start the server with the token my token.
Also does the in-memory vault server store its secrets?
If so where does it store secrets in my windows machine? I have exported VAULT_DEV_ROOT_TOKEN_ID to my environment variables with value s.WC4LYVf6oOyllP6HjR0A3nvo
I tried restarting the server several times
C:\Users\user>vault server -dev
==> Vault server configuration:
Api Address: http://127.0.0.1:8200
Cgo: disabled
Cluster Address: https://127.0.0.1:8201
Listener 1: tcp (addr: "127.0.0.1:8200", cluster address: "127.0.0.1:8201", max_request_duration: "1m30s", max_request_size: "33554432", tls: "disabled")
Log Level: info
Mlock: supported: false, enabled: false
Storage: inmem
Version: Vault v1.2.2
Error initializing Dev mode: failed to create root token with ID "s.WC4LYVf6oOyllP6HjR0A3nvo": 1 error occurred:
* invalid request
The problem here was when ever we start a the vault server in dev mode in windows it generates a root access token. If we export the VAULT_DEV_ROOT_TOKEN_ID to the environment variables, it tries to start the server with that token. But since the token was previously used by vault it the server is not allowed to start.
Because you are running on the dev mode you'll need to unset the token, because whenever you restart the server it generates a new token, and invalidates the previous one. This is how to get it done on MacOS, specifically Big Sur.
Do these:
Open the .zshrc file. Issue this command in the terminal open ~/.zshrc to open it.
In the previous setup, the vault url and token has been added to .zshrc, comment these lines out. These are the lines:
export VAULT_ADDR='http://127.0.0.1:8200
export VAULT_DEV_ROOT_TOKEN_ID=s.a009oZnrl78a9h1vlRw1kGqL
Issue the startup command on the terminal again - vault server -dev
This time around it'll generate a new token, copy it, paste, and replace the previous token. This is the one to edit and replace -
export VAULT_DEV_ROOT_TOKEN_ID=s.a009oZnrl78a9h1vlRw1kGqL.
Once you've added it, uncomment these vault values in the .zshrc file.
Save the file and close, then on your terminal issue this command - source ~/.zshrc to refresh/update the .zshrc file.

Node-red in IBM Bluemix crashes while starting after sleeping (lite account)

After sleeping (in lite account type) node-red, created by node-red starter kit, crashes while starting. It is possible to login in editor for a few seconds and then it crashes with error code "an instance of the app crashed: APP/PROC/WEB: Exite with status 1 (out of memory)". Dashboard (node-red-dashboard) was installed before sleeping and worked correctly.
I tried to restart Node-RED, Stop and Start.
I solved this problem. The problem may be due to the memory overflow in the container Garden. Taking into account that the content is stored in the cache, the application cannot start after the restart process, it issues an Exit status 1 (out of memory) error.
The cache is updated only by pushing the application into the cloud.
An option that was checked for application recovery:
View the name of the database for NodeRED (which stores all information about the Node-RED) in Cloudant, for example, "nodered."
Install to PC Cloud Foundry Command Line Interface - CLI https://docs.cloudfoundry.org/cf-cli/install-go-cli.html
Download from github and unarchive the application's code bluemix-starter https://github.com/knolleary/node-red-bluemix-starter (clone or download -> download zip)
In the downloaded folder add a record to a manifest file (manifest.yml) in the env section, in which set the database name (for example, nodered) in Cloudant to environment variable NODE_RED_STORAGE_DB_NAME. Four spaces must be made before NODE_RED_STORAGE_DB_NAME. It is better to make changes using the Notepad ++ editor.
---
applications:
- memory: 256M
env:
OPTIMIZE_MEMORY: true
NODE_RED_STORAGE_DB_NAME: nodered
command: node index.js --settings ./bluemix-settings.js –v
Save the file after changing.
Run the command line (cmd) and then:
a. go to a folder with a downloaded project, such as Windows
cd c:/node-red-bluemix-starter
b. specify the api endpoint where the application is located, in our case:
cf api https://api.eu-gb.bluemix.net
c. send a registration command in the cloud
cf login
d. specify the mail and password (password is entered without explicit character display)
e. pushing the project by specifying the name of your instance Node-RED, for example NameApp
cf push NameApp

Securing a REST call to Vault Secrets management

Been trying to figure out how to do this for awhile. Essentially, Vault does not have a secure option for its REST calls. I want to make these rest calls encrypted from as close between point a and b as possible. My thoughts have been the following:
Use an SSH tunnel
Use a TLS tunnel like Stunnel
I currently have Vault in a Docker container, so that’s something else to mention. Has anyone encountered this situation, and how did you deal with it?
UPDATE: So, using the Python API (HVAC), I am getting the following error:
requests.exceptions.SSLError: HTTPSConnectionPool(host='0.0.0.0',
port=8200): Max retries exceeded with url: /v1/secret (Caused by
SSLError(SSLError("bad handshake: Error([('SSL routines', 'ssl3_get_record',
'wrong version number')],)",),))
Using the following commands:
import os
import hvac
client = hvac.Client(url='https://0.0.0.0:8200', token='my-token-here')
Vault has TLS enabled by default, thus all your REST calls are encrypted already. If you are having trouble using https, have a look at the documentation of VAULT_CACERT and VAULT_CAPATH environment variables.
from vault's documentation.
VAULT_CACERT
Path to a PEM-encoded CA certificate file on the local disk. This file
is used to verify the Vault server's SSL certificate. This environment
variable takes precedence over VAULT_CAPATH.
VAULT_CAPATH Path to a directory of PEM-encoded CA certificate files
on the local disk. These certificates are used to verify the Vault
server's SSL certificate.
You can use tools like tcpdump or wireshark to make sure that your requests are indeed encrypted.
To elaborate for Vault running in a container, you need to create a configuration file for Vault that contains something similar to this this (Chef/Ruby code):
config_content = %(
"storage": {
...
},
"default_lease_ttl": "768h",
"max_lease_ttl": "8766h",
"listener": [
{"tcp": {
"address": "0.0.0.0:8200",
"tls_disable": 0,
"tls_cert_file": "/vault/certs/my-cert-combined.pem",
"tls_key_file": "/vault/certs/my-cert.key"
}}],
"log_level": "info"
)
Especially the listener portion. Make your backend storage whatever you want to use (not the Dev default of in-memory!).
Note you will need to get a valid certificate and its private key also in the volume bound into the container.
Store this configuration file in a directory that gets bound inside the container to the path /vault/config. I use /var/vault/config on my host. For example (more Ruby/Chef):
docker_container 'vault' do
container_name 'vault'
tag 'latest'
port '8200:8200'
cap_add ['IPC_LOCK']
restart_policy 'always'
volumes ['/var/vault:/vault']
command 'vault server -config /vault/config'
action :run_if_missing
end
That command tells Vault to look in /vault/config and it should find your config file there, with a .json extension. Note it is important to have the config file listener->tcp->address be 0.0.0.0, rather than 127.0.0.1, because Vault will not resolve external accesses properly.
Then Vault will startup with TLS encryption on all transactions. Define VAULT_ADDR to have https://your-host.com:8200 and away you go.
In my case, I've been testing it on my local environment. So instead of calling the secured https: https://localhost:8200, I called regular http: http://localhost:8200.
This solved the error.