Add upstream refresh related config to OIDCIdentityProvider CRD

Also update related docs.
This commit is contained in:
Ryan Richard
2021-10-14 15:49:44 -07:00
parent 9e05d175a7
commit ddb23bd2ed
26 changed files with 1364 additions and 248 deletions

View File

@@ -85,12 +85,20 @@ spec:
# Specify the upstream issuer URL (no trailing slash).
issuer: https://<dex-dns-record>
# Request any scopes other than "openid" for claims besides
# the default claims in your token. The "openid" scope is always
# included.
# Specify how to form authorization requests to Dex.
authorizationConfig:
# Request any scopes other than "openid" for claims besides
# the default claims in your token. The "openid" scope is always
# included.
additionalScopes: [groups, email]
# If you would also like to allow your end users to authenticate using
# a password grant, then change this to true.
# Password grants with Dex will only work in Dex versions that include
# this bug fix: https://github.com/dexidp/dex/pull/2234
allowPasswordGrant: false
# Specify how Dex claims are mapped to Kubernetes identities.
claims:
# Specify the name of the claim in your Dex ID token that will be mapped

View File

@@ -30,8 +30,14 @@ For example, to create a user-owned application:
1. Create a new application:
1. Enter a name for your application, such as "My Kubernetes Clusters".
1. Enter the redirect URI. This is the `spec.issuer` you configured in your `FederationDomain` appended with `/callback`.
1. Check the box saying that the application is _Confidential_.
1. Select scope `openid`. This provides access to the `nickname` (GitLab username) and `groups` (GitLab groups) claims.
1. Check the box saying that the application is _Confidential_. This is required and will cause GitLab to autogenerate
a client ID and client secret for your application.
1. Check the box saying to _Expire Access Tokens_ to cause refresh tokens to be returned to the Supervisor. This is
required starting in Pinniped v0.13.0.
1. Select scope `openid`. This is required to get ID tokens. Also, this provides access to the `nickname` (GitLab username)
and `groups` (GitLab groups) claims in the ID tokens.
1. Optionally select other scopes which might provide access to other claims that you might want to use to determine
the usernames of your users, for example `email`.
1. Save the application and make note of the _Application ID_ and _Secret_.
## Configure the Supervisor cluster
@@ -51,6 +57,19 @@ spec:
# Specify the upstream issuer URL.
issuer: https://gitlab.com
# Specify how to form authorization requests to GitLab.
authorizationConfig:
# GitLab is unusual among OIDC providers in that it returns an
# error if you request the "offline_access" scope during an
# authorization flow, so ask Pinniped to avoid requesting that
# scope when using GitLab.
doNotRequestOfflineAccess: true
# If you would also like to allow your end users to authenticate using
# a password grant, then change this to true.
allowPasswordGrant: false
# Specify how GitLab claims are mapped to Kubernetes identities.
claims:

View File

@@ -32,11 +32,18 @@ For example, to create an app:
1. Create a new app:
1. Click `Create App Integration`.
1. For `Sign-on method`, select `OIDC`.
1. For `Application type`, app `Web Application`, then click next.
1. For `Application type`, app `Web Application`, then click next. Only if you would like to offer the
password grant flow to your end users, then choose `Native Application` instead.
1. Enter a name for your app, such as "My Kubernetes Clusters".
1. If you chose to create a `Web Application` then in the General Settings section, choose Grant Types
`Authorization Code` and `Refresh Token`. Starting in Pinniped v0.13.0, the `Refresh Token` grant is required.
1. If you chose `Native Application` then in the General Settings section, choose Grant Types `Authorization Code`,
`Refresh Token`, and `Resource Owner Password`. Starting in Pinniped v0.13.0, the `Refresh Token` grant is required.
1. Enter the sign-in redirect URI. This is the `spec.issuer` you configured in your `FederationDomain` appended with `/callback`.
1. Optionally select `Limit access to selected groups` to restrict which Okta users can log in to Kubernetes using this integration.
1. Save the app and make note of the _Client ID_ and _Client secret_.
1. Save the app and make note of the _Client ID_ and _Client secret_. If you chose to create a `Native Application`
then there is an extra step required to get a client secret: after saving the app, in the
Client Credentials section click `Edit`, choose `Use Client Authentication`, and click `Save`.
1. Navigate to the _Sign On_ tab > _OpenID Connect ID Token_ and click `Edit`. Fill in the Groups claim filter.
For example, for all groups to be present under the claim name `groups`, fill in "groups" in the first box, then select "Matches regex" and ".*".
@@ -54,18 +61,26 @@ metadata:
name: okta
spec:
# Specify the upstream issuer URL (no trailing slash).
# Specify the upstream issuer URL (no trailing slash). Change this to be the
# actual issuer provided by your Okta account.
issuer: https://my-company.okta.com
# Request any scopes other than "openid" for claims besides
# the default claims in your token. The "openid" scope is always
# included.
#
# To learn more about how to customize the claims returned, see here:
# https://developer.okta.com/docs/guides/customize-tokens-returned-from-okta/overview/
# Specify how to form authorization requests to Okta.
authorizationConfig:
# Request any scopes other than "openid" for claims besides
# the default claims in your token. The "openid" scope is always
# included.
#
# To learn more about how to customize the claims returned, see here:
# https://developer.okta.com/docs/guides/customize-tokens-returned-from-okta/overview/
additionalScopes: [groups, email]
# If you would also like to allow your end users to authenticate using
# a password grant, then change this to true. Password grants only work
# with applications created in Okta as "Native Applications".
allowPasswordGrant: false
# Specify how Okta claims are mapped to Kubernetes identities.
claims: