Merge pull request #208 from Phantom-Intruder/auth

Auth101

README.md

@@ -269,6 +269,7 @@ A Curated List of Kubernetes Labs and Tutorials
 ## Security101
 - [What is DevSecOps?](./Security101/devsecops.md)
 - [Securing your cluster](./Security101/kubernetes-security.md)
+- [OIDC auth with Keycloak](./Security101/auth-intro.md)
 
 ## GitOps101
 - [What is GitOps](./GitOps101/what-is-gitops.md)

Security101/auth-intro.md

@@ -0,0 +1,86 @@
+# Authentication
+
+This section will cover running authentication tools inside your cluster. In particular, we will be focusing on the use of Keycloak to act as an OIDC provider. This provider can then be used to authenticate your internal tools running within Kubernetes as well as outside Kubernetes (as long as it is inside the same VPC).
+
+Most organization have their own VPN which can be used to access resources within their private VPC. This is standard practice when managing your internal resources since you want to minimize your attack surface as much as possible. This means severely reducing the amount of internet-facing services you have that can be susceptible to vulnerabilities. So while well-established providers such as Google SSO exist, your services need to be internet-facing for those providers to work. This is where running your OIDC provider within your VPC comes in handy. If both your provider and the tools that use the provider are in the same VPC, there is no issue.
+
+For this example, we will be setting up Keycloak, and then using it to authenticate Devtron, which is a CI/CD & cluster operations tool. To learn more about it, head to the [observability section](../Observability101/observability.md). We will set up both tools with Helm, which you are already familiar with. You will also need to have a Kubernetes cluster either running locally on your machine or on a cloud platform.
+
+## Keycloak installation
+
+Bitnami has an official Keycloak chart present, but this chart has some unresolved issues around its database configuration, so we will be using a different Keycloak chart from codecentric instead. We will be using all the default values since they work fine for our use case, so install the chart with the following:
+
+```
+helm install keycloak codecentric/keycloak
+```
+
+Once the pods are ready, you can use port forwarding to access the Keycloak dashboard:
+
+```
+kubectl port-forward svc/keycloak-http 80:80 -n keycloak
+```
+
+You could also use a load balancer to access the resource by editing the service and setting the type to load balancer. Make sure you also set the annotation:
+
+```
+service.beta.kubernetes.io/aws-load-balancer-internal: true
+```
+
+This will make sure your LB is internal instead of internet-facing.
+
+## Devtron installation
+
+Now that Keycloak is up, let's focus on setting up Devtron. We will set it up without any additional integrations:
+
+```
+helm repo add devtron https://helm.devtron.ai
+helm repo update devtron
+helm install devtron devtron/devtron-operator \
+--create-namespace --namespace devtroncd
+```
+
+Exposing this is similar to exposing Keycloak. Either use port forwarding or edit the `devtron-service` inside the `devtroncd` namespace the same way as before. Once you have done that, log in to the Keycloak dashboard.
+
+## Managing the realm
+
+Keycloak allows you to separate your clients into various realms. For this exercise, you can use the default master realm used by Keycloak, or you could create your own realm to put the clients under. In any case, all you need to do here is to go to Realm settings > General, and click on "OpenID Endpoint Configuration". This will open up a JSON page. Take note of the first item in the block `issuer`. You will need this for the next part.
+
+## Creating the Devtron client
+
+Since Keycloak is the provider, Devtron will be the client that requests the authentication service. In the same way, if you had a different service that required authentication with Keycloak, that would be another client. 
+
+From the left pane, go to clients > Create.
+
+Here, set the client ID to `devtron`, and the name to `Devtron`. Make sure the client protocol is openid-connect and the access type is confidential. Under "Valid Redirect URIs", you will set the redirect URL you get from Devtron in the next step. You will use the same URL for "logout redirect URIs" and "web origins". Save the client and head to the `credentials` tab at the top of the page where you can get the client secret. 
+
+## Setting up Devtron to use Keycloak
+
+Start up Devtron and log in as admin. Go to Global Configurations → SSO Login Services → OIDC. There will be a callback URL generated by Devtron (`/api/dex/callback`), we will be using this to redirect the URL of Keycloak that was mentioned in the previous step. In the config itself, set everything as follows:
+
+Set `issuer` to the issuer URL you got from the previous step.
+Set `clientID` to `devtron`.
+Set `clientSecret` to the client secret from the previous step.
+Set `redirectURL` to the callback URL.
+
+With that, you are done setting up auth from both the Devtron and Keycloak side. Now, it's time to create users.
+
+## Creating users
+### Keycloak
+
+First, you will create users from Keycloak and assign them to the Devtron client. These are SSO users which you can use for other clients as well. For example, if you were also setting up SSO for ArgoCD, the users you create here would be able to log in to both Devtron & ArgoCD using the same account (provided you have given them those permissions). Creating a user is very simple, just head over to the user's section from the left pane, add a Username, email, and Name, and create the user. Next, go to the credentials tab and assign a user a new password, then select the `change password` option. This will make sure that the user has to use the password you give to log in for the first time, after which they are forced to change their password before they can go any further. You can also create user groups and assign users to them, which is useful if you are controlling users at an RBAC level. But since Devtron provides its own role-based auth, you can skip that.
+
+### Devtron
+
+Once the user is created from Keycloak, take the user's email and head over to Devtron. Go to the user management section and create a user from the Devtron UI. Here, make sure to set the email to exactly the same one you took from Keycloak. There is no additional configuration needed from the users' end here since Devtron will match the user using the email and get the rest of the required information.
+
+## Creating roles
+
+Now, set the user roles and permissions. In Devtron, you can create permission groups and specify granularly what kind of access each user has to each Kubernetes resource. Once you have assigned all the permissions your user will need, assign the permission group to the user. You can assign multiple permission groups to each user, increasing their level of access with each one, or you could directly give super admin privileges.
+
+In tools like [ArgoCD](../GitOps101/argocd.md), you must create Kubernetes roles, assign permission to these roles, and then assign these roles to individual users. Or you could create a user group in Keycloak, add Keycloak users to these user groups, and then assign roles to these user groups instead of individual users. You can read more about cluster roles and role bindings in the [RBAC section](../RBAC101/README.md)
+
+This is all you need to do to set up OIDC auth with Keycloak. Now, when users come to your Devtron page, they will see an option to "log in with OIDC." Selecting this option will redirect them to the Keycloak login page, which allows them to log in. Any other tools configured with Keycloak will have the same auth flow.
+
+## Conclusion
+
+There are a lot more features available in Keycloak besides just creating users and user groups. Consult their official documentation if you need these features. Here, we just used the basic set of the properties required to set up OIDC with Keycloak for Devtron in the simplest manner possible, all without exposing a single service outside your VPC of added security and compliance measures.

Security101/kubernetes-security.md

@@ -155,3 +155,7 @@ To make your life easier, K10 additionally allows you to restore your system to
 ## Other measures
 
 The above list is in no way the most extensive list of security options that are available to protect your Kubernetes clusters. There is always a new exploit being found, and it's best to assume that someday, your cluster will be attacked. The fundamental problem here is that an attacker only needs to find a single weak spot in your security system to break in, whereas a cluster-admin needs to ensure that there are zero weak spots in any of the resources to achieve complete safety. So if you are planning on being a cluster admin or have to maintain security in a cluster, then there is a lot more in this field that you need to consider. However, if you are a normal developer, then the above steps should help you code securely, regardless of the size of your organization.
+
+Before we finish, let's swing things around and take a look at how you can provide proper authentication using tools running on your cluster.
+
+[Next: Authentication](./auth-intro.md)