Published on 00/00/0000
Last updated on 00/00/0000
Published on 00/00/0000
Last updated on 00/00/0000
Share
Share
7 min read
Share
authn/autz
across the Pipeline platform and our own Kubernetes distribution, regardless of where it is runOpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.Dex also helped us to replace our user filtering code with a few lines of YAML, since it supports organization level (and also team level) filtering out-of-the-box:
connectors:
- type: github
id: github
name: GitHub
config:
clientID: "ourGitHubOauthClientID"
clientSecret: "ourGitHubOauthClientSecret"
redirectURI: https://some.banzai.server.dev/dex/callback
loadAllGroups: true
orgs:
- name: banzaicloud
authz
and authn
are currently only configurable via API server startup parameters. Some implementations have reached PR status, but there still exists no generic webhook-based authentication. This can cause a lot of headaches on a cloud provider-managed Kubernetes distribution, but in our PKE distribution we have full control over - and use of - API server flags.
Since Pipeline is already deployed with Dex, we can also use the Kubernetes OIDC plugin to authenticate users into the Kubernetes clusters provisioned by Pipeline.
In the PKE distribution, API Servers are started with the following parameters:
kube-apiserver \
--oidc-issuer-url=https://some.banzai.server.dev/dex/callback \
--oidc-client-id=clustersDexClientID \
--oidc-username-claim=email \
--oidc-username-prefix=oidc: \
--oidc-groups-claim=groups \
--oidc-groups-prefix=oidc: \
...
kubectl create clusterrolebinding banzaiers-are-admins \
--clusterrole cluster-admin \
--group banzaicloud
groups
claim of the OIDC ID Token, users must be part of at least one group, otherwise bindings can only be made with a User
subject (and have to be made individually for every user and to be kept in sync for all members of a group) and not with a Group
subject. To read more about subjects and bindings see the official Kubernetes documentation.
users:
- name: malkovich
user:
auth-provider:
name: oidc
config:
client-id: kubernetes-cluster-123
client-secret: 1db158f6-177d-4d9c-8a8b-d36869918ec5
id-token: eyJraWQiOiJDTj1vaWRjaWRwLnRyZW1vbG8ubGFuLCBPVT1EZW1vLCBPPVRybWVvbG8gU2VjdXJpdHksIEw9QXJsaW5ndG9uLCBTVD1WaXJnaW5pYSwgQz1VUy1DTj1rdWJlLWNhLTEyMDIxNDc5MjEwMzYwNzMyMTUyIiwiYWxnIjoiUlMyNTYifQ.eyJpc3MiOiJodHRwczovL29pZGNpZHAudHJlbW9sby5sYW46ODQ0My9hdXRoL2lkcC9PaWRjSWRQIiwiYXVkIjoia3ViZXJuZXRlcyIsImV4cCI6MTQ4MzU0OTUxMSwianRpIjoiMm96US15TXdFcHV4WDlHZUhQdy1hZyIsImlhdCI6MTQ4MzU0OTQ1MSwibmJmIjoxNDgzNTQ5MzMxLCJzdWIiOiI0YWViMzdiYS1iNjQ1LTQ4ZmQtYWIzMC0xYTAxZWU0MWUyMTgifQ.w6p4J_6qQ1HzTG9nrEOrubxIMb9K5hzcMPxc9IxPx2K4xO9l-oFiUw93daH3m5pluP6K7eOE6txBuRVfEcpJSwlelsOsW8gb8VJcnzMS9EnZpeA0tW_p-mnkFc3VcfyXuhe5R3G7aa5d8uHv70yJ9Y3-UhjiN9EhpMdfPAoEB9fYKKkJRzF7utTTIPGrSaSU6d2pcpfYKaxIwePzEkT4DfcQthoZdy9ucNvvLoi1DIC-UocFD8HLs8LYKEqSxQvOcvnThbObJ9af71EwmuE21fO5KzMW20KtAeget1gnldOosPtz1G5EwvaQ401-RPQzPGMVBld0_zMCAwZttJ4knw
idp-issuer-url: https://some.banzai.server.dev/dex
refresh-token: q1bKLFOyUiosTfawzA93TzZIDzH2TNa2SMm0zEiPKTUwME6BkEo6Sql5yUWVBSWpKUGphaWpxSVAfekBOZbBhaEW+VlFUeVRGcluyVF5JT4+haZmPsluFoFu5XkpXk5BXq
Pipeline supports generating this configuration for your clusters, individually for every user within your organization. Since each cluster has its own client-id
and client-secret
, setting up an authentication flow client is bit more tricky. Tricky, because we prepare N different authentication callback handlers for all the client-ids, or we create one handler which will handle the preparation of those OAuth configs dynamically. We don't really want to maintain state, since Pipeline is a distributed application and can be run in HA mode, so we chose the latter option.
The OAuth state parameter helps us through this process; it has two roles: one of them is to maintain state between the request and callback. cluster-id
and the client-id
is going to be encoded into it as a JWT signed by Pipeline and is valid only for 1 minute so we can make sure that the client who requests login credentials for a Kubernetes cluster is entitled to get it. The second role of the OAuth state parameter is to prevent XRSF, which we get for "free".
The code implementing this feature into Pipeline is a work-in-progress, but you can check it out on this branch.
Note: The Pipeline CI/CD module mentioned in this post is outdated and not available anymore. You can integrate Pipeline to your CI/CD solution using the Pipeline API. Contact us for details.If you're looking to experiment with any of the above, or are interested in our unified authn/autz solution from control plane to K8s clusters and/or deployments, try Pipeline.
Get emerging insights on emerging technology straight to your inbox.
Discover why security teams rely on Panoptica's graph-based technology to navigate and prioritize risks across multi-cloud landscapes, enhancing accuracy and resilience in safeguarding diverse ecosystems.
The Shift is Outshift’s exclusive newsletter.
Get the latest news and updates on generative AI, quantum computing, and other groundbreaking innovations shaping the future of technology.