<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Workload-Identity on Andrea Cervesato</title><link>https://cervesato.it/tags/workload-identity/</link><description>Recent content in Workload-Identity on Andrea Cervesato</description><generator>Hugo</generator><language>en</language><copyright>Andrea Cervesato</copyright><lastBuildDate>Sun, 15 Dec 2024 00:00:00 +0000</lastBuildDate><atom:link href="https://cervesato.it/tags/workload-identity/index.xml" rel="self" type="application/rss+xml"/><item><title>Kill Your Service Account Keys: Secure GitLab CI/CD on Google Cloud</title><link>https://cervesato.it/posts/killing-service-account-keys/</link><pubDate>Sun, 15 Dec 2024 00:00:00 +0000</pubDate><guid>https://cervesato.it/posts/killing-service-account-keys/</guid><description>&lt;p&gt;If your CI/CD pipeline authenticates to Google Cloud with a service account key stored in a CI variable, you have a problem. You might not know it yet, but you have a problem.&lt;/p&gt;
&lt;p&gt;That JSON key file is a static credential. It doesn&amp;rsquo;t expire (unless you rotate it, which you don&amp;rsquo;t). It has no context about &lt;em&gt;who&lt;/em&gt; or &lt;em&gt;what&lt;/em&gt; is using it. If it leaks — and CI variables leak more often than anyone admits — an attacker gets the same access your pipeline has. Forever, or until someone notices.&lt;/p&gt;
&lt;p&gt;So I built a POC to try the alternative: a keyless, signed, vulnerability-gated pipeline from GitLab to Google Cloud. No service account keys. No stored secrets.&lt;/p&gt;</description></item></channel></rss>