DEV Community: Cole Arendt

Helm Intro and Cheatsheet

Cole Arendt — Tue, 11 Oct 2022 02:20:59 +0000

Below is an introduction to Helm! If you want to skip to the
cheatsheet, you can download it here.

What is Helm

According to its own docs, Helm is "the" package manager for Kubernetes. What does this mean?

It's a way of keeping track of all your Kubernetes stuff!

Helm as I describe it is a mechanism for packaging and parameterizing standard Kubernetes YAML files. It uses Go Templating for most of this mechanism, and adds a layer of version / metadata tracking as well. All of this packaged up into tarballs used by a client-side-only (as of helm v3) CLI.

So basically: Helm = YAML + Go Templating + Versioning + Tarballs.

Why use it?

Why use it? There are lots of alternatives out there, and many purported "Helm replacements," but Helm has yet to give up its throne, and I have not found anything better for my own use cases... yet. So what are Helm's strengths?

I will do my best not to wax poetic. I am biased and a big fan of Helm. As a layer of abstraction between an application and Kubernetes, I think it is a fantastic asset.

In particular, I think this is because:

No runtime dependency
Client-side only utility
Data stored server side for collaboration
output represents native Kubernetes objects (i.e. interoperable with other tools)
helm template gives rapid feedback on iterating and testing
plain text file output / diffs is very easy to parse

As a system administrator, it is nice because it offers:

Version pinning for reproducibility
Everything is open source tarballs, so dependencies are easy to track and introspect
application vendors will ideally maintain their own chart and good NEWS files

When to use it?

So that's what it is, and why it is desirable. But when is it useful?

I find that helm particularly shines in a handful of situations:

Managing an array of applications deployed on Kubernetes
Packaging your own application for use by customers
Encoding complex knowledge about "how to run an application" (to an extent, then you get to operators)
To set up easy "roll-back" policies for applications that support the behavior

Occasionally a wrapper like ArgoCD, Flux, helmfile, or pulumi will be useful to manage your helm deployments too, so that you don't have to keep track of a bunch of CLI commands.

When not to use it?

Helm can definitely be overkill in some "hello world" or very simple deployment situations. Unfortunately, it also does not have a great answer for CRDs yet. Moreover, it is only useful for Kubernetes, so if you are unfamiliar with Kubernetes, it will have limited utility for you.

The other case where it may not be useful is in some internal applications. Maintaining a helm chart for an application can end up being a sizable amount of work, and they do not allow arbitrary inputs, so if you miss some key (i.e. "imagePullSecrets,") you can end up spending a lot of time key-chasing across your charts. I have heard of folks using Kustomize in such a situation, although another option is to use a meta chart (one chart for many apps) or Functions-as-a-Service (FaaS) framework like Serverless, OpenFaas, Knative, etc.

Also, helm charts do have a complexity ceiling. Go Templating provides lots of flexibility, but being DRY is hard, and there are many parts of the process that are not optimal from a software development point of view. As
charts become more complex, an operator becomes increasingly beneficial as a mechanism to provide better software semantics to the application management process. However, the learning curve for operators can also be a bit steep.

Finally, helm charts unfortunately do not have hard-and-fast standards about how values are used across the ecosystem. As a result, you will often encounter wild variations in chart quality, value naming, and value behavior.

Hello World

Let's get started on a hello world example! First, you need to install kubectl, install helm, and have a kubernetes cluster available. Once those things are taken care of, a hello world example of a helm deployment is pretty straightforward!

For this example, we will use my generic chart, useful for deploying simple services with standard configuration or helm needs.

We are also going to use this hello-world container.

First, add the repository that houses our example chart:

helm repo add colearendt https://colearendt.github.io/helm/

You can look at the values available for the chart:

helm show values colearendt/generic

# I like to pipe it to a pager for search and such
helm show values colearendt/generic | less

Then create a YAML file called my-values.yaml to hold values:

my-values.yaml

image:
  repository: paulbouwer/hello-kubernetes
  tag: "1.10"
pod:
  port: 8080

Then template the output:

helm template hello-world colearendt/generic -f my-values.yaml

And install it into the Kubernetes cluster!

helm upgrade --install hello-world colearendt/generic -f my-values.yaml

Then you should be able to see the app deployed:

helm list
kubectl get pods

And view the service in your web browser at http://localhost:8080:

kubectl port-forward svc/hello-world-generic 8080:80

Clean Up

If you want to clean up after yourself:

# delete the helm release
helm delete hello-world

# delete the repository reference
helm repo remove colearendt

Unfortunately, I have not taken much time to dive into troubleshooting here! If you are hitting issues, please shoot me an email - I would love to have feedback on what to improve! Maybe someday I will take the time to set up comments 😅

Best Practices

So now you have a "Hello World" deployment under your belt. However, it also helps to keep in mind some best practices as you keep improving. Below is a handful of helm chart conventions that may be unfamiliar if you are new to the community:

Make sure to pin helm chart versions with the --version flag
Maintain a NEWS.md file (or read the NEWS.md file) to keep track of changes between versions
Keep an eye out for "upgrading directions" in the README.md or elsewhere
Use helm show values to see the default values (and comment strings associated). Ideally these are presented or discussed in a README as well.
Avoid sub-charts if you can. It is tempting as a DRY software principle, but turns out to be a pretty advanced topic with lots of tricky edge cases. In particular, namespaces can be painful.

Cheat Sheet

I took the time to arrange a "cheat sheet" of my favorite helm commands and the contexts in which they are useful. It was inspired by RStudio's array of excellent cheat sheets for the R community.

A hit-list of some of the most useful commands:

helm show values chartrepo/chartname
helm template releasename chartrepo/chartname
helm upgrade --install releasename chartrepo/chartname
helm repo add https://repourl
helm repo list
helm search repo
helm info
helm list

And the cheat-sheet itself can be downloaded here.

What's Next?

The helm project is an open source project. There is much that could be improved, and many applications that need helm charts or need
improved helm charts. You can make a difference! If you are interested in learning more, check out the helm tag on this blog to see other writing on
the topic, and start poking around on ArtifactHub, where lots of charts are centralized for easier searching!

Photo by william william on Unsplash

Using sssd in a Playground Without TLS

Cole Arendt — Sat, 01 Oct 2022 23:59:50 +0000

sssd has established itself as the most common way to provision system accounts via LDAP or Active Directory on linux servers across all linux distributions. However, working with it can be tricky!

TL;DR;

We show an example of using sssd to contact an LDAP server that is listening on port 389 (in plaintext / no TLS). This is NOT a good idea in any production environment. However, it can be important and helpful in playgrounds, learning, or other experiments. The magic configuration is ldap_auth_disable_tls_never_use_in_production = true.

Why

It is quite straightforward to stand up an LDAP server listening in plaintext. My favorite mechanism is using the openldap container, although there are other options.

docker run -it --rm -p 389:389 osixia/openldap:latest

However, if you have a toy linux container running sssd, this is unfortunately not an obvious option! Why, you ask? This is all just a dev playground!? Right. Well the sssd maintainers want to be very careful about not creating security vulnerabilities or letting their users get hacked. This means you have to work hard to open yourself up to this type of vulnerability in your playground.

Specifically, we will use the ldap_auth_disable_tls_never_use_in_production setting.

NOTE: Do not use this setting in any "real" environment with "real" users, passwords, sensitive data, etc.

Give it a Shot

Create Users

First, we need to create and populate our LDAP server. Let's go ahead and do that. It is easiest if we create a file with users first. For a more advanced LDIF file, check out the repository associated with this post:

users.ldif

version: 1

## Entry 1: dc=angl,dc=dev
#dn: dc=angl,dc=dev
#dc: angl
#o: Angl Dev
#objectclass: top
#objectclass: dcObject
#objectclass: organization
#
## Entry 2: cn=admin,dc=angl,dc=dev
#dn: cn=admin,dc=angl,dc=dev
#cn: admin
#description: LDAP administrator
#objectclass: simpleSecurityObject
#objectclass: organizationalRole
#userpassword: {SSHA}+FquX8RcwTtBPo7mu2pgSvjaQYX9HpCL
#
#
# Entry 3: cn=engineering_group,dc=angl,dc=dev
dn: cn=engineering_group,dc=angl,dc=dev
cn: engineering_group
gidnumber: 500
memberuid: joe
memberuid: julie
objectclass: posixGroup
objectclass: top

# Entry 4: dc=engineering,dc=angl,dc=dev
dn: dc=engineering,dc=angl,dc=dev
dc: engineering
description: The Engineering Department
o: Engineering
objectclass: dcObject
objectclass: organization
objectclass: top


# Entry 5: cn=joe,dc=engineering,dc=angl,dc=dev
dn: cn=joe,dc=engineering,dc=angl,dc=dev
cn: joe
gidnumber: 500
givenname: Joe
homedirectory: /home/joe
loginshell: /bin/sh
mail: joe@angl.dev
objectclass: inetOrgPerson
objectclass: posixAccount
objectclass: top
sn: Golly
uid: joe
uidnumber: 1000
userpassword: {MD5}j/MkifkvM0FmlL6P3C1MIg==

# Entry 9: cn=julie,dc=engineering,dc=angl,dc=dev
dn: cn=julie,dc=engineering,dc=angl,dc=dev
cn: julie
gidnumber: 500
givenname: Julie
homedirectory: /home/julie
loginshell: /bin/sh
mail: julie@angl.dev
objectclass: inetOrgPerson
objectclass: posixAccount
objectclass: top
sn: Jolly
uid: julie
uidnumber: 1001
userpassword: {MD5}FvEvXoN54ivpleUF6/wbhA==

You will notice that the first two entries are commented out. They are included to represent a complete LDIF file. However, the osixia/docker-openldap container help us by provisioning these automatically.

Further, you will notice that passwords are included. This makes things easier for our playground, but is definitely a bad idea in real life / production applications.

Create LDAP Server

Now let's create the server itself!

docker network create playground-network
docker run \
  -d --name openldap --rm \
  -p 389:389 \
  --network playground-network \
  -v $(pwd)/users.ldif:/container/service/slapd/assets/config/bootstrap/ldif/50-bootstrap.ldif \
  -e LDAP_TLS=false \
  -e LDAP_DOMAIN="angl.dev" \
  -e LDAP_ADMIN_PASSWORD="admin" \
  osixia/openldap:1.5.0 \
  --copy-service --loglevel debug

And check that it is working

docker exec -it openldap ldapsearch -D cn=admin,dc=angl,dc=dev -b dc=angl,dc=dev -w admin cn
docker exec -it openldap ldapsearch -D cn=admin,dc=angl,dc=dev -b dc=angl,dc=dev -w admin cn=julie \*

If you look carefully, you will notice that:

We created a persistent network for our containers to share
We provisioned users from our ldif file
We disabled TLS on the service
We bumped up the logging verbosity for debugging purposes

These are all useful tidbits to dig into if you are not familiar!

Configure sssd Server

It is possible to run sssd in a fairly vanilla ubuntu:jammy container.

docker run -it --name sssd --rm --network playground-network ubuntu:jammy bash

apt update && apt install -y sssd ldap-utils vim

Then you need to create your sssd.conf file. Notice our magic option ldap_auth_disable_tls_never_use_in_production=true. This will be the magic that makes things work for us!

cat << EOF > /etc/sssd/sssd.conf
[sssd]
config_file_version = 2
services = nss, pam
domains = LDAP

[nss]
filter_users = root,named,avahi,haldaemon,dbus,radiusd,news,nscd
filter_groups =

[pam]

[domain/LDAP]
id_provider = ldap
auth_provider = ldap
chpass_provider = ldap
sudo_provider = ldap
enumerate = true
# ignore_group_members = true
cache_credentials = false
ldap_schema = rfc2307
ldap_uri = ldap://openldap:389
ldap_search_base = dc=angl,dc=dev
ldap_user_search_base = dc=angl,dc=dev
ldap_user_object_class = posixAccount
ldap_user_name = uid

ldap_group_search_base = dc=angl,dc=dev
ldap_group_object_class = posixGroup
ldap_group_name = cn
ldap_id_use_start_tls = false
ldap_tls_reqcert = never
ldap_tls_cacert = /etc/ssl/certs/ca-certificates.crt
ldap_default_bind_dn = cn=admin,dc=angl,dc=dev
ldap_default_authtok = admin
access_provider = ldap
ldap_access_filter = (objectClass=posixAccount)
min_id = 1
max_id = 0
ldap_user_uuid = entryUUID
ldap_user_shell = loginShell
ldap_user_home_directory = homeDirectory
ldap_user_uid_number = uidNumber
ldap_user_gid_number = gidNumber
ldap_group_gid_number = gidNumber
ldap_group_uuid = entryUUID
ldap_group_member = memberUid
ldap_auth_disable_tls_never_use_in_production = true
use_fully_qualified_names = false
ldap_access_order = filter
debug_level=6
EOF
chmod 600 /etc/sssd/sssd.conf

Now let's start the sssd service

sssd -i
# should see some log messages that suggest things are happening!

Be sure it works!

Now let's make sure that this works by starting another shell in our jammy container.

docker exec -it sssd bash

id joe
# uid=1000(joe) gid=500(engineering_group) groups=500(engineering_group)
id julie
# uid=1001(julie) gid=500(engineering_group) groups=500(engineering_group)

Using `docker-compose`

For playground environments like this, docker-compose makes this setup much easier to architect and reuse. You can use my example compose setup in lieu of the above if you prefer.

cd compose/
docker network create playground-network
NETWORK=playground-network docker-compose -f ldap.yml -f sssd.yml -f network.yml up -d
docker exec -it compose_sssd_1 bash

sssd -i >/tmp/sssd.log 2>&1 &
id joe

Review

Well done! You have successfully started your own sssd container. Although this is very much a toy, it is a great "jumping off point" to learn and understand how sssd works in more detail!

Any time you need a toy LDAP server for sssd, just remember: ldap_auth_disable_tls_never_use_in_production = true.

Photo by Jacek Dylag on Unsplash