<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Secrets on Support Tools</title><link>https://support.tools/tags/secrets/</link><description>Recent content in Secrets on Support Tools</description><generator>Hugo</generator><language>en-US</language><lastBuildDate>Tue, 27 Oct 2026 00:00:00 -0500</lastBuildDate><atom:link href="https://support.tools/tags/secrets/index.xml" rel="self" type="application/rss+xml"/><item><title>10 Practical Tips to Tame Kubernetes</title><link>https://support.tools/kubernetes-practical-tips/</link><pubDate>Tue, 01 Jul 2025 00:00:00 -0500</pubDate><guid>https://support.tools/kubernetes-practical-tips/</guid><description>&lt;p&gt;Kubernetes is a powerful tool for managing containerized workloads—but with great power comes great complexity. Whether you&amp;rsquo;re just starting with Kubernetes or looking to tighten up your production clusters, these &lt;strong&gt;10 practical tips (plus a bonus)&lt;/strong&gt; will help you reduce pain, improve resilience, and simplify day-to-day operations.&lt;/p&gt;</description></item><item><title>GitHub Actions Secrets: OIDC, Environments, SHA Pins</title><link>https://support.tools/post/enterprise-github-actions-security-secret-management-guide-2025/</link><pubDate>Sun, 25 May 2025 16:34:42 -0500</pubDate><guid>https://support.tools/post/enterprise-github-actions-security-secret-management-guide-2025/</guid><description>&lt;p&gt;Most GitHub Actions secret leaks are not clever. A long-lived AWS key sits in repository secrets for three years, a &lt;code&gt;pull_request_target&lt;/code&gt; workflow checks out a fork and runs its &lt;code&gt;npm install&lt;/code&gt; with that key in the environment, or a tag on a popular action gets repointed to malicious code. This guide fixes each of those with concrete workflow YAML, in the order that removes the most risk first.&lt;/p&gt;</description></item><item><title>Extract a Kubernetes Secret From an etcd Snapshot</title><link>https://support.tools/pulling-data-etcd-backup-extract-secret/</link><pubDate>Fri, 18 Oct 2024 19:26:00 -0500</pubDate><guid>https://support.tools/pulling-data-etcd-backup-extract-secret/</guid><description>&lt;p&gt;Someone deleted a Secret, or overwrote it, and the only copy left is in an etcd snapshot. Restoring the whole cluster to get one object back would roll every other resource back too. This guide restores the snapshot into a scratch etcd that has nothing to do with the live cluster, reads the one key you need, and decodes it into normal Secret YAML.&lt;/p&gt;</description></item><item><title>Helm: Create a Secret Only If It Does Not Exist (lookup)</title><link>https://support.tools/reusing-kubernetes-secrets-helm-templates/</link><pubDate>Mon, 07 Oct 2024 19:26:00 -0500</pubDate><guid>https://support.tools/reusing-kubernetes-secrets-helm-templates/</guid><description>&lt;p&gt;Kubernetes Secrets are an essential part of securing sensitive information such as passwords, API keys, and certificates. When using Helm to manage your Kubernetes deployments, there are often cases where you need to reuse existing Secrets rather than creating new ones. This is a common requirement in scenarios where Secrets are managed externally or shared across multiple applications.&lt;/p&gt;&#10;&lt;p&gt;In this post, we will explore how to reuse existing Kubernetes Secrets within your Helm templates, ensuring efficient management and security for your workloads.&lt;/p&gt;</description></item><item><title>Decrypt One Secret From an RKE2 etcd Snapshot</title><link>https://support.tools/post/extracting-decrypting-secret-etcd-snapshot-rke2/</link><pubDate>Wed, 04 Sep 2024 04:48:35 -0500</pubDate><guid>https://support.tools/post/extracting-decrypting-secret-etcd-snapshot-rke2/</guid><description>&lt;p&gt;Someone deleted a Secret, or rotated a credential and lost the old value, and the only copy left is in last night&amp;rsquo;s RKE2 etcd snapshot. Restoring the whole cluster to get one object back is out of the question. This guide restores the snapshot into a scratch etcd that has nothing to do with the live cluster, reads the one key you need, and decrypts it, because on RKE2 every Secret in etcd is encrypted at rest.&lt;/p&gt;</description></item></channel></rss>