<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Openshift on 404 Code Not Found</title><link>https://www.404-code-not-found.com/tags/openshift/</link><description>Recent content in Openshift on 404 Code Not Found</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Thu, 11 Jun 2026 08:00:00 -0600</lastBuildDate><atom:link href="https://www.404-code-not-found.com/tags/openshift/index.xml" rel="self" type="application/rss+xml"/><item><title>Running Vault on OpenShift with HCP Vault Auto-Unseal: Lessons Learned</title><link>https://www.404-code-not-found.com/posts/vault-on-openshift-hcp-autounseal/</link><pubDate>Thu, 11 Jun 2026 08:00:00 -0600</pubDate><guid>https://www.404-code-not-found.com/posts/vault-on-openshift-hcp-autounseal/</guid><description>&lt;h2 id="introduction">Introduction&lt;/h2>
&lt;p>I recently set up a three-node Vault Enterprise HA cluster on OpenShift, using
HCP Vault as the auto-unseal provider via the transit secrets engine. On paper
this is a straightforward combination of well-documented features. In practice,
it was a series of traps — some subtle, some spectacular — that took multiple
sessions to fully work through.&lt;/p>
&lt;p>This post covers the four main challenge areas I hit: getting &lt;code>IPC_LOCK&lt;/code> right
on OpenShift, wiring up the auto-unseal token flow securely, managing Raft
quorum safely during rolling updates, and working around a reconciliation bug in
Vault Secrets Operator. I&amp;rsquo;ll focus on what caught me off guard and what the
correct solution looks like.&lt;/p></description></item></channel></rss>