<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Harbor on Build. Run. Repeat.</title><link>https://buildrunrepeat.com/categories/harbor/</link><description>Recent content in Harbor on Build. Run. Repeat.</description><generator>Hugo</generator><language>en</language><lastBuildDate>Fri, 01 Nov 2024 09:00:00 -0400</lastBuildDate><atom:link href="https://buildrunrepeat.com/categories/harbor/index.xml" rel="self" type="application/rss+xml"/><item><title>Harbor Registry - Automating LDAP/S Configuration - Part 1</title><link>https://buildrunrepeat.com/posts/harbor-registry-automating-ldap-configuration-part-1/</link><pubDate>Fri, 01 Nov 2024 09:00:00 -0400</pubDate><guid>https://buildrunrepeat.com/posts/harbor-registry-automating-ldap-configuration-part-1/</guid><description>&lt;p&gt;The Harbor Registry is involved in many of my Kubernetes implementations in the field, and in almost every implementation I am asked about the options to configure LDAP/S authentication for the registry. Unfortuntely, neither the community Helm chart nor the Tanzu Harbor package provides native inputs for this setup. Fortunately, the Harbor REST API enables LDAP configuration programmatically. Automating this process ensures consistency across environments, faster deployments, and reduced chances of human error.&lt;/p&gt;</description></item><item><title>Harbor Registry – Automating LDAP/S Configuration – Part 2</title><link>https://buildrunrepeat.com/posts/harbor-registry-automating-ldap-configuration-part-2/</link><pubDate>Sun, 01 Jan 2023 09:00:00 -0400</pubDate><guid>https://buildrunrepeat.com/posts/harbor-registry-automating-ldap-configuration-part-2/</guid><description>&lt;p&gt;This post continues our two-part series on automating LDAP configuration for Harbor Registry. In the &lt;a href="https://buildrunrepeat.com/posts/harbor-registry-automating-ldap-configuration-part-1/"&gt;previous post&lt;/a&gt;, we demonstrated how to achieve this using Ansible, running externally. However, external automation has its challenges, such as firewall restrictions or limited API access in some cases/environments.&lt;/p&gt;
&lt;p&gt;Note: make sure you review the previous post as it provides a lot of additional background and clarifications on this process, LDAPS configuration, and more.&lt;/p&gt;
&lt;p&gt;Here, we explore an alternative approach using Terraform, running the automation directly inside the Kubernetes cluster hosting Harbor.
This method leverages native Kubernetes scheduling capabilities for running the configuration job in a fully declarative approach and does not require any network access to Harbor from the machine running the job.&lt;/p&gt;</description></item><item><title>Getting Harbor to trust your LDAPS certificate in TKG</title><link>https://buildrunrepeat.com/posts/getting-harbor-to-trust-your-ldaps-certificate-in-tkg/</link><pubDate>Mon, 01 Aug 2022 09:00:00 -0400</pubDate><guid>https://buildrunrepeat.com/posts/getting-harbor-to-trust-your-ldaps-certificate-in-tkg/</guid><description>&lt;p&gt;In a recent TKG implementation, it was required to configure Harbor with LDAPS rather than LDAP.&lt;/p&gt;
&lt;p&gt;I deployed the Harbor package on the TKG shared services cluster and configured LDAP. However, when testing the connection, I received an error message that was not informative at all:&lt;/p&gt;
&lt;pre tabindex="0"&gt;&lt;code&gt;Failed to verify LDAP server with error: error: ldap server network timeout.
&lt;/code&gt;&lt;/pre&gt;&lt;p&gt;
&lt;a href="https://buildrunrepeat.com/posts/getting-harbor-to-trust-your-ldaps-certificate-in-tkg/images/001.png" data-dimbox data-dimbox-caption="Screenshot"&gt;
 &lt;img alt="Screenshot" src="https://buildrunrepeat.com/posts/getting-harbor-to-trust-your-ldaps-certificate-in-tkg/images/001.png"/&gt;
&lt;/a&gt;
&lt;/p&gt;
&lt;p&gt;Although the error message doesn&amp;rsquo;t explicitly say there&amp;rsquo;s a certificate issue and there is nothing in the &lt;code&gt;harbor-core&lt;/code&gt; container logs, it immediately made sense to me that the &lt;code&gt;harbor-core&lt;/code&gt; container didn&amp;rsquo;t trust my LDAPS/CA certificate, so I started investigating how the certificate could be injected somehow into Harbor. The Harbor package doesn&amp;rsquo;t have any input for the LDAPS/CA certificate in its data values file, so I knew I had to create &lt;a href="https://github.com/itaytalmi/vmware-tkg/blob/main/ytt-overlays/tkg-packages/harbor/ldaps-overlay/overlay-harbor-ldaps-cert.yaml"&gt;my own YTT overlay&lt;/a&gt;.&lt;/p&gt;</description></item><item><title>Harbor Registry: is your LDAP user unique?</title><link>https://buildrunrepeat.com/posts/harbor-registry-is-your-ldap-user-unique/</link><pubDate>Mon, 01 Aug 2022 09:00:00 -0400</pubDate><guid>https://buildrunrepeat.com/posts/harbor-registry-is-your-ldap-user-unique/</guid><description>&lt;p&gt;A recent project I was working on required granting different levels of permissions for several Active Directory service accounts on Harbor registry so that some can only pull images from the registry, and others can also push, etc.&lt;/p&gt;
&lt;p&gt;On the Harbor project, I had the following configuration for my users:&lt;/p&gt;
&lt;p&gt;
&lt;a href="https://buildrunrepeat.com/posts/harbor-registry-is-your-ldap-user-unique/images/001.png" data-dimbox data-dimbox-caption="Screenshot"&gt;
 &lt;img alt="Screenshot" src="https://buildrunrepeat.com/posts/harbor-registry-is-your-ldap-user-unique/images/001.png"/&gt;
&lt;/a&gt;
&lt;/p&gt;
&lt;p&gt;The &lt;code&gt;harbor-group-01&lt;/code&gt; group contains an Active Directory user named &lt;code&gt;harbor-user-01&lt;/code&gt; and &lt;code&gt;harbor-group-02&lt;/code&gt; contains &lt;code&gt;harbor-user-02&lt;/code&gt;.&lt;/p&gt;
&lt;p&gt;From the command line, I was able to log in to Harbor with &lt;code&gt;harbor-user-01&lt;/code&gt;:&lt;/p&gt;</description></item></channel></rss>