Pushing an Authentication Policy in Advanced Cluster Management for Kubernetes (Part 4)
In part 4 of this series, I am going to show a practical example of pushing a policy in ACM. Many customers ask for a way to control the authentication provider(s) that are supported by OCP. In this example, an htpasswd oauth provider will be created as well as a central secret (for those password credentials). This same method can be used to push an LDAP/Active Directory mechanism as well.
A sample Git repo is located at https://github.com/kcalliga/acm-demos/blob/master/oauth-policy
As you may recall from part 3 of this series, an ACM policy is just an embedded object definition. This example will show an oauth configuration and a centralized htpasswd file being pushed through ACM.
First, I'm going to show you how to create an oauth policy within the Openshift web console. One is already created in the Github repo but I want to show how we can take the template from a regular OCP object (IE: oauth policy) and put that into an ACM policy. You can skip up to step 6 but it is helpful to understand what is happening when an ACM policy is created.
- Go to Administration --> Cluster Settings --> Global Configuration --> Oauth
2. In the "Identity Providers" section, there is an option to add a variety of different providers. Choose "htpasswd"
3. This will bring up a wizard which will let us upload an htpasswd file.
To generate an htpasswd file, do the following on a Linux command-line:
htpasswd -c <nameoffiletocreate> <username>
In this example, I am making the username "user1" with a password of "password"
4. Now, let's upload this file through the OCP web console. Choose the file we want to upload (htpasswd.file) and click "Add"
5. In the "Oauth" details screen, you will see the htpasswd provider was added.
6. Click on the YAML tab to see the resulting YAML definition for the Oauth configuration.
A custom resource definition called "oauth" is created. This is not namespaced meaning you can run an "oc get oauth" command from any project/namespace in the cluster to see it. The name for this global configuration is called cluster. The kind is oauth and name is cluster.
The resulting htpasswd file is put in the etcd database as a secret called htpasswd-bnkw5 in the openshift-config namespace/project.
Take note of the spec section of the oauth YAML definition. This will be embedded into the ACM policy definition.
7. Let's look at my Github repo at the ACM policy definition. This policy contains the oauth/cluster object as well as the htpasswd secret.
ACM Policy for Oauth configuration and HTPASSWD
I will provide a high-level overview of what this file contains. For more information on the ACM policy objects, see my previous blog post.
Line 1: apiversion is policy.open-cluster-management (open-cluster-management is upstream name for ACM)
Line 2: CRD is kind Policy
Line 4: The name of the policy object is called "policy-push-all-htpasswd"
Line 5: The namespace-based subscription is stored in the hub cluster in the "default" namespace.
The other lines are explained in my previous blog post. I didn't change the annotations on the template. It is just a copy/paste from another YAML definition and may not be accurate if we are tracking security policies.
Notice on line 29, we start with defining the objectDefinition (inside the object-template). This object definition is indented two spaces but is the same content as the OAUTH configuration I showed in the OCP GUI.
At the bottom of this YAML file (starting at line 42) is the object definition for the htpasswd file.
As was mentioned previously, this secret is stored in the "openshift-config" namespace/project. Since we are making this htpasswd file portable (by including it automatically in a policy), it needs to be converted to a base64 string (see line 65).
8. To do this, just run the following command:
cat htpasswd.file |base64 -w0
This will return the base64 decoded string on the command-line.
9. Take the base64 decoded contents and put them on line 65 after htpasswd: as shown below.
What we have accomplished is embedding an htpasswd oauth configuration in an ACM policy that can be pushed to any cluster (even clusters that are created by ACM). In this example, the policy is created and the secret (meaning same htpasswd credential file) is pushed. I only have a local cluster for demo purposes but this concept is the same if pushing to multiple clusters.
Let's see this in action. Remember we set the username/password as "user1/password" earlier.
I hope you enjoyed the blog post and found it useful. Much more to come.