TROUBLESHOOTING HASHICORP VAULT KUBERNETES AUTH ERROR

 We were trying to integrate Spring Cloud Gateway (SCG) on Kubernetes with HashiCorp. We followed the steps mentioned in vault documentation. We were able to bring up vault and vault injector but SCG pods were stuck in init state. Found following error in SCG application pod vault-agent-init container logs:

NAME READY STATUS RESTARTS AGE
scg-0 0/2 Init:0/1 0 9h
vault-0 1/1 Running 0 10h
vault-agent-injector-5c89c7dfc5-n2v6v 1/1 Running 0 20h

                 Cgo: disabled
           Log Level: info
             Version: Vault v1.8.4
         Version Sha: 925bc650ad1d997e84fbb832f302a6bfe0105bbb
2022-09-30T16:24:28.007Z [INFO] sink.server: starting sink server
2022-09-30T16:24:28.007Z INFO creating watcher
2022-09-30T16:25:28.008Z [ERROR] auth.handler: error authenticating: error="context deadline exceeded" backoff=1s

To verify that vault injector was connecting to right vault instance, we verified init agent config using below kubectl command:

kubectl exec -it scg-0 -c vault-agent-init cat /home/vault/config.json

Config was pointing to a different vault than what we created. As we are using shared Kubernetes cluster, we checked with our cluster admin if there was any other vault injector running in the cluster. They confirmed that there was another one running. As the old was not in use, we requested to delete it. Post that vault init container was connecting to correct vault but still the error was not gone.

We tried few things but could not find out the issue. Finally, vault troubleshooting guide came to our rescue. We have enabled audit raw logs as mentioned in the document. Regular audit logs write hashed strings so we couldn’t see what tokens and roles are sent from our application. But after enabling raw logs, we could see the actual token being passed as part of the authentication process.

vault audit enable -path=file_raw file file_path=/vault/audit-raw.log log_raw=true

After inspecting decrypted jwt token (There are lot of online tools to decrypt), we found that token we used in creating auth/kubernetes/config and auth/kubernetes/role were different than what SCG application uses. SCG uses by default service-account-scg service account to authenticate to vault. After making corrections to Kubernetes authentication method and application role, SCG application pod came up and was in ready state.

Comments

Post a Comment

Popular posts from this blog

HOW WE REDUCED SOA OSB PROVISIONING FROM 4 DAYS TO 4 HOURS

 In our organization, we’ve undertaken the task of upgrading both SOA and OSB from version 12.2.1.3 to 12.2.1.4. This involves an out-of-place migration approach, wherein we create a new environment and switch traffic during the cutover. As you know, this process typically requires several days we opt for manual provisioing. A very significant amount of automation work was previously accomplished for 12.2.1.3 by our predecessors. Despite these efforts, the process still used to take lot of time due to following factors: Bugs in existing automation. For example, SOA composite deployments is not stable which warrants lot of manual work Import of 10s of TLS Certificates into KSS Manual retiring and shutting down of services Monitoring setup Miscellaneous: Increasing Log file count, enabling GC logging, changing heap parameters, bash profile changes While our current automation initiatives have yielded substantial savings, we aimed to capitalize on this upgrade activity to enable end-t...
Read more

NOT ABLE TO START RABBITMQ CLUSTER: CANNOT DECLARE A QUEUE ‘~S’ ON NODE ‘~S’: ~255P

We have 7 node rabbitmq cluster and we are using sharding queues. We have shutdown all non prod rabbitmq nodes as part of VM patching. As it was non prod, we thought of shutting down all together instead of rolling patching. We couldn’t start the any of the rabbitmq post patching. All of nodes were failing to start with the below error: 2022-06-23 05:13:10.104845-07:00 [error] <0.647.0> “Cannot declare a queue ‘~s’ on node ‘~s’: ~255p”, 2022-06-23 05:13:10.104845-07:00 [error] <0.647.0> [“queue ‘sharding: shard.my.queue – rabbit@rabbit1’ in vhost ‘my_vhost'” This is a known issue in some old versions of rabbitmq. rabbitmq node fails to come up with above error. Work around for this is to disable sharding policy for the problematic sharding queue. It can be done either from command line or from rabbitmq admin page. It requires to connect a running node. But as all the nodes were down, we could not disable sharding policy. Luckily, rabbitmq allows disabling sharding pulgi...
Read more

SOA SUITE 12.2.1.4 INSTALLATION: GOT EXCEPTION WHEN AUTO CONFIGURING THE SCHEMA COMPONENT(S) WITH DATA OBTAINED FROM SHADOW TABLE

  We planned to do out of place upgrade from soa suite 12.2.1.3 to 12.2.1.4. As part of this, we planned to automate end to end provisioning. While executing domain configuration using ansible and python scripts, we got following error in domain creation step. Got exception when auto configuring the schema component(s) with data obtained from shadow table. Failed to build JDBC Connection object: com.oracle.cie.domain.script.jython.CommandExceptionHandler. exception. Quick internet search gave few solutions like deleting domain-registry.xml file, verifying dehydration store password supplied to script etc. But none of them helped. After trying several options, I thought I might have done some stupid error prior to domain creation step. To track down the issue, though of checking what getDatabaseDefaults actually doing. I tried to grep for the getDatabaseDefaults function call inside oracle home. But couldn’t find the source code for the python function. As a final resort, thought of...
Read more