A DevOps team may be accessing multiple applications and tools in a single product environment in support of their DevOps processes such as CI/CD server, Centralized log, Kubernetes dashboard, Monitoring software, Artifact repositories, Admin tools, etc. All of these tools will require authentication mechanisms for security purposes, and for a user to maintain and remember their authentication credentials on so many software can quickly become cumbersome. And in the event of lost credentials, it can be a tedious process for both users and admins to recover the required credentials.
Instead of having individual authentication on various tools, a more effective strategy is to use single sign-on for all tools, i.e. a centralized authentication mechanism that can allow or reject access to a set of tools based on a single set of credentials per user. Additionally, some tools may not have authentication built into them at all and may be reliant on an external authentication server in any case. An external authentication server with single sign-on capability can therefore prove to be the way to go in such a situation.
Single Sign-On
Single Sign-On (SSO) allows users to log in using a single set of credentials, e.g. username and password, so they can easily access a set of applications. SSO. SSO saves time and energy for users because they do not have to repeatedly log into multiple applications. This provides a smooth user experience and makes it less likely to have access problems because of lost or forgotten credentials, locked-out accounts, etc.
Keycloak
Keycloak is an Open Source Identity and Access Management solution. It provides an easy way to add authentication including Single Sign-on to applications and services with minimum effort. Keycloak handles persistence and user authentication all out of the box.
Instead of having to log in to individual applications, users authenticate with Keycloak rather than individual applications. This means that the individual applications don’t have to implement their own login forms, authentication, and storage of users and sessions. Once logged in to Keycloak, users don’t have to log in again to access a different application. And similarly once logged out from Keycloak, users don’t have to log out of individual applications. Enabling login with social networks is also easy. The configuration for these can be added via Keycloak’s admin console. No code or changes are required to individual applications.
Keycloak supports OpenID Connect and SAML protocols. OpenID Connect (OIDC) is an extension of the OAuth 2 authentication protocol. While OAuth 2.0 is a framework for building authorization protocols, and OIDC is the full implementation of an authentication and authorization protocol. SAML 2.0 is similar to OIDC but a lot older and consequently more mature. It has its roots in SOAP and works by exchanging XML documents between the authentication server and the application, so it tends to be a bit more verbose than OIDC. In most cases OIDC is recommended by Keycloak.
OpenID Connect
OIDC uses the Json Web Token (JWT) set of standards. There are really two types of use cases when using OIDC. Our relevant use case is where the application asks the Keycloak server to authenticate a user for them. After a successful login, the application will receive an identity token and an access token. The identity token contains information about the user such as username, email, and other profile information. The access token is digitally signed by the realm and contains access information, e.g. user roles, that the application can use to determine what resources the user is allowed to access on the application.
Keycloak setup
A stable chart for keycloak is available in the official public helm chart repository. The chart deploys a StatefulSet for Keycloak and also includes a deployment of PostgreSQL which it uses as the database for Keycloak. The chart can also be configured to use an external instance of PostgreSQL instead of the bundled deployment, such as AWS RDS.
Going by the philosophy of GitOps and maintaining all our configuration in code, we use a json file to configure our keycloak realm and import it into keycloak at deployment time. Following is an example configuration of the Keycloak chart. While the standalone operating mode is not recommended for a production setup as it becomes a single point of failure for applications, the example is show for a standalone operating mode to keep things simple while introducing the rest of the required configuration. The realm json is loaded into a configmap and then referenced in the Keycloak chart through the configmap.
replicas: 1image:
repository: jboss/keycloak
tag: 4.8.3.Final
pullPolicy: IfNotPresentpersistence:
# If true, the Postgres chart is deployed
deployPostgres: false# The database vendor. Can be either "postgres", "mysql", "mariadb", or "h2"
dbVendor: postgres## The following values only apply if "deployPostgres" is set to "false"# Specifies an existing secret to be used for the database password
existingSecret: "keycloak-secrets"
# The key in the existing secret that stores the password
existingSecretKey: database.passworddbName: kc-database
dbHost: keycloak-postgresql.rds
dbPort: 5432
dbUser: keycloakextraArgs: >
-Djgroups.bind_addr=global
-Dkeycloak.migration.action=import
-Dkeycloak.migration.provider=singleFile
-Dkeycloak.migration.file=/opt/jboss/keycloak/standalone/configuration/import/realm.json
-Dkeycloak.migration.strategy=IGNORE_EXISTING## Allows the specification of additional environment variables for Keycloak
extraEnv: |
- name: OPERATING_MODE
value: standalone## Add additional volumes and mounts, e. g. for custom themes
extraVolumes: |
- name: keycloak-config
configMap:
name: keycloak-configmap
items:
- key: realm.json
path: realm.json
extraVolumeMounts: |
- name: keycloak-config
mountPath: /opt/jboss/keycloak/standalone/configuration/import/realm.json
subPath: realm.jsonpodAnnotations:
fluentdConfiguration: >
[
{
"containers":
[
{
"expression": "/^\\S*\\s-\\s-\\s\\[(?<time>\\S*)[\\S\\s]*\\]\\s(?<message>[\\S\\s]*)/",
"expressionFirstLine": "/^\\:\\:f{4}:[0-9]+.[0-9]+\\.[0-9]+\\.[0-9]+/",
"timeFormat": "%d/%b/%Y:%H:%M:%S",
"containerName": "keycloak"
}
]
}
]service:
labels:
expose: "true"
port: 80
annotations:
xposer.stakater.com/annotations: |-
kubernetes.io/ingress.class: external-ingress
ingress.kubernetes.io/force-ssl-redirect: true
forecastle.stakater.com/expose: true
forecastle.stakater.com/icon: https://www.keycloak.org/resources/images/keycloak_logo_480x108.png
forecastle.stakater.com/appName: keycloak
exposeIngressUrl: globally
config.xposer.stakater.com/Domain: company.com
config.xposer.stakater.com/IngressNameTemplate: '{{.Service}}'
config.xposer.stakater.com/IngressURLTemplate: 'keycloak.{{.Namespace}}.{{.Domain}}'The postgresql details are provided in the persistence section including the server details, database username and password (referenced from a Kubernetes secret).
The realm json is loaded from the configmap into a volume, under extraVolumeMounts, which is mounted in Keycloak. In the extraArgs of the Keycloak container we specify the path of the mounted realm json which we want to import.
keycloak-configmap:
ConfigMapName: "keycloak-configmap"
Data:
realm.json: |-
{
"realm": "stakater",
"enabled": true,
"loginTheme": "keycloak",
"sslRequired": "external",
...
}The operating mode is specified with the environment variables under extraEnv of the container.
It is necessary to create or obtain a client configuration for any application to be able to use Keycloak. You usually configure a new client for each new application hosted on a unique host name. When an application interacts with Keycloak, the application identifies itself with a client ID so Keycloak can provide a login page, single sign-on (SSO) session management, and other services.
The traditional method in the OAuth2 specification for authentication is to use a client id and secret. The client has a secret, which needs to be known to both the application and the Keycloak server. You can generate the secret for a particular client in the Keycloak administration console or then specify the secret in the keycloak realm json.
Keycloak Gatekeeper
Keycloak Gatekeeper is an adapter that integrates with the Keycloak authentication service. We deploy it on a per-application instance basis. So usually this will be a sidecar container deployed with the application container on the Kubernetes pod. We configure the Kubernetes service of the application so that it points to the gatekeeper rather than the application itself, so that the gatekeeper can act as a proxy for incoming requests. The gatekeeper then verifies from the Keycloak server if an active authenticated session exists or not. If not, it redirects the client to the Keycloak login page. If the session exists, it allows the incoming request to pass through to the application container.
Using the Keycloak Gatekeeper allows us to have zero authentication configuration within the application itself. The session verification, redirection to Keycloak in case of an invalid session, and pass-through to the application in case of a valid session, are all handled by the gatekeeper.
Stakater Proxy Injector
Deploying a sidecar container for Keycloak Gatekeeper with all our applications can be a hassle. So we want to automatically inject a keycloak gatekeeper container in a pod, for any deployment that requires to connect to keycloak, instead of manually adding a sidecar container with each deployment. This Proxy Injector controller will continuously watch deployments in specific or all namespaces, and automatically add a sidecar container for keycloak gatekeeper. Configuration for the keycloak gatekeeper is done through annotations of the respective deployment or with ConfigMap of the ProxyInjector.
You can explore securing your Kubernetes infrastructure more and learn about the comprehensive services offered by Stakater.
Some common configuration can either be added to the proxy injector config.yaml in the ConfigMap, or can be overridden at the application deployment level using annotations on the target deployments. Following are the core configuration properties
listen: this is the interface the gatekeeper should be listening on e.g. "0.0.0.0:80" to listen on the localhost pod.upstream-url: url for the upstream endpoint you wish to proxyresources: list of resources to proxy uri, methods, rolesclient-id: client id used to authenticate to the oauth serviceclient-secret: client secret used to authenticate to the oauth serviceAll of the available Gatekeeper configuration can also be specified on ProxyInjector annotations.
If you're looking for expert guidance on your Kubernetes journey, explore our Kubernetes consultancy services, which provide tailored solutions to enhance your Kubernetes deployments.
Comments