Skip to content

Commit 3878a4c

Browse files
day0heroday0hero
authored
htpass + hcp oauth config (#404)
* blog for htpasswd + hcp config * made updates to blog
1 parent b25ab5b commit 3878a4c

File tree

1 file changed

+130
-0
lines changed

1 file changed

+130
-0
lines changed

‎content/blog/2024-02-07-hcp-htpasswd-config.md‎

Lines changed: 130 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,130 @@
1+
---
2+
date: 2024-02-07
3+
title: Adding htpasswd oAuth provider to HCP clusters
4+
summary: How-to - Add htpasswd authentication to hosted controlplane clusters
5+
author: Jonny Rickard
6+
blog_tags:
7+
- patterns
8+
- how-to
9+
---
10+
11+
# Configure HTPasswd OAuth provider for hosted clusters
12+
13+
## Overview
14+
15+
In this blog, we're going to configure our hosted cluster to use `htpasswd` as its authentication provider.
16+
17+
There are several reasons that we would want to do this, but usually it comes down to understanding that the kubeadmin/root users aren't the right way to do things. HTPasswd is a simple but effective way to centrally manage users and provide access to cluster resources when bound to the proper RBAC. In a traditional OpenShift deployment the configuration of the htpasswd oauth is well documented, but with hosted control planes we have to dig a little bit for the answer. This blog walks through the configuration of the oauth provider, and also provids ways that you can verify the configuration works as intended.
18+
19+
### Assumptions
20+
> The procedures in this blog have been tested against OpenShift `4.13` and `4.14` hostedclusters.
21+
22+
This blog assumes that you have the following binaries installed on your machine:
23+
24+
- **hcp** <tab> | Creating and managing hosted clusters
25+
- **htpasswd** <tab> | Creating and managing htpasswd configurations
26+
- **oc** <tab> | Interacting with your OpenShift cluster
27+
28+
> **Warning:** When you add an idp configuration the kubeadmin password is no longer available. So if you forget the password that you created or you want that level of permissions you will need to generate and use the kubeconfig:
29+
30+
## Getting Started
31+
32+
> **NOTE:** The following steps should be performed on the HyperShift management cluster
33+
34+
### Create the kubeconfig for the hosted cluster
35+
36+
```shell
37+
hcp create kubeconfig –name <clusterName> > /tmp/<clusterName>.kube
38+
39+
export KUBECONFIG=/tmp/<cluserName>.kube
40+
```
41+
42+
First, using the `htpasswd` cli we need to create an htpasswd configuration with our users and their passwords.
43+
44+
`htpasswd -Bbc htpasswd.users admin password`
45+
46+
We're creating a file called htpasswd.users and adding a user called `admin` with the password of `password`.
47+
48+
Next, we need to create a secret in the same namespace as the hostedcluster resource.
49+
50+
> The default namespace is `clusters`
51+
52+
There is no required naming convention. However, for the sake of future you and others on your team that may be configuring their clusters with htpasswd appending the cluster name to the end of the secret is a simple and effective way to associate the secret to the hostedcluster.
53+
54+
### Create the secret for your hostedcluster
55+
56+
`oc create secret generic htpasswd-<clusterName> –from-file=htpasswd=./htpaaswd.users -n clusters`
57+
58+
Now we need to update the hostedcluster resource with the htpasswd OAuth provider:
59+
60+
### Apply OAuth configuration to hostedcluster resource
61+
62+
`oc edit hostedcluster <clustername> -n clusters`
63+
64+
Add the following to the hostedcluster resource:
65+
66+
```yaml
67+
spec:
68+
configuration:
69+
oauth:
70+
identityProviders:
71+
- htpasswd:
72+
fileData:
73+
name: htpasswd-<clusterName> #secret name
74+
mappingMethod: claim
75+
name: htpasswd #name of the oAuth entry
76+
type: HTPasswd
77+
```
78+
79+
You can verify that the configuration is picking up the change correctly by looking at the pod status in clusters-<clustername>
80+
81+
Notice the time that the pods have been running, if you see that they have recently been restarted and are without error then this is a good indication that the configuration has been applied correctly.
82+
83+
```shell
84+
oc get pods -n clusters-demo
85+
86+
oauth-openshift-54bc55789b-5j854 2/2 Running 0 58s
87+
oauth-openshift-54bc55789b-g6bls 1/2 Running 0 26s
88+
oauth-openshift-54bc55789b-jtf5m 2/2 Running 0 91s
89+
```
90+
91+
## Verification
92+
93+
> **WARNING:** The following steps are to be performed on the hostedcluster
94+
95+
Login using the credentials we created earlier. You can either login to the hosted cluster openshift console or to the api server.
96+
97+
> Something to be aware of: When using the openshfit console the `htpasswd` provider will not be presented as a choice for logging in. This is because the `kubeadmin` user/password is removed when the IDP is updated.
98+
99+
### api server login example:
100+
101+
```shell
102+
hcp create kubeconfig –name <clusterName> > /tmp/<clusterName>.kube
103+
104+
export KUBECONFIG=/tmp/<clusterName>.kube
105+
106+
oc login $(oc whoami –show-server) -u admin -p password
107+
```
108+
109+
### Apply RBAC to configured user(s)
110+
111+
You may notice that your user doesn't really have any permissions to the cluster. You will need to grant permissions to the user by applying a Role or ClusterRole. In this example, we are giving our adming user the `cluster-admin` clusterRole.
112+
113+
> **NOTE:** You will likely not have admin access to your cluster so you will need to create and export the `kubeconfig` for your hosted cluster to apply the RBAC to your user
114+
115+
`oc adm policy add-cluster-role-to-user cluster-admin admin`
116+
117+
Once you have logged in using the htpasswd idp you can view the users and identities that OpenShift is aware of:
118+
119+
```shell
120+
oc get identity,users
121+
NAME IDP NAME IDP USER NAME USER NAME USER UID
122+
identity.user.openshift.io/htpasswd:admin htpasswd admin admin 25dfddc5-66b4-47c2-8ba2-7b54b72eda04
123+
124+
NAME UID FULL NAME IDENTITIES
125+
user.user.openshift.io/admin 25dfddc5-66b4-47c2-8ba2-7b54b72eda04 htpasswd:admin
126+
```
127+
128+
## Summary
129+
130+
That's it! We took our out of the box hostedcluster and applied an HTPasswd OAuth provider and then applied a clusterRole to it. This is a simple approach for you and your team to share a cluster without having to share the kubeadmin username. Alternatively, if you wanted to use other OIDC authenticators like GitHub, Google ..etc you could follow along with the flow from this blog to accomplish.

0 commit comments

Comments
 (0)