Also:
- fix github teams query: fix bug and sort/unique the results
- add IDP display name to github downstream subject
- fix error types returned by LoginFromCallback
- add trace logs to github API results
- update e2e test
- implement placeholder version of refresh for github
- Carefully note the rfc27732 design for IPv6 in URLs, while also clarifying the handling of IPv6 in Golang.
Co-authored-by: Ryan Richard <richardry@vmware.com>
- Add test to verify timestamps are particularly updated
- Improve diff output in tests for actions
- Make jwtauthenticator status tests parallel
- Update copyright headers in multiple files
- "Ready" condition & supporting conditions
- Legacy "Phase" for convenience
- Refactor newCachedJWTAuthenticator() func
to improve ability to provide additional conditions
- Update JWTAuthenticator.Status type
- Update RBAC for SA to get/watch/update JWTAuthenticator.Status
- Update logger to plog, add tests for logs & statuses
- update Sync() to reduce enqueue when error is config/user managed, perhaps remove validateJWKSResponse()
See deprecation of v2 message in README.md at
https://github.com/github/codeql-action
Added setup-go because codeql code scanning stopped working and gave
this error message:
The go.mod file requires version v1.21.3 of Go, but version v1.20.14 is installed. Consider adding an actions/setup-go step to your workflow.
This fixes a small mistake in PR #1864. When the "pinniped login oidc"
CLI command is deciding if the RFC8693 token exchange is needed, it
should not look at the expiry of the ID token. This mistake would cause
the RFC8693 token exchange to happen when the OIDC provider is not
a Pinniped Supervisor, which would fail because most other providers
do not support that type of token exchange.
It does not matter if the current ID token is close to expiring when
deciding if the RFC8693 token exchange is needed, because the token
exchange is going to yield a new ID token anyway. It does matter if the
current ID token is close to expiring if the CLI decides that it is
not going to perform the token exchange, and this commit does not change
that logic.
Background: For dynamic clients, the groups scope is not always allowed
and/or requested by the client, so it will not always be granted by the
Supervisor for an authorization request.
Previously, when the groups scope was not granted, we would skip
searching for upstream groups in some scenarios.
This commit changes the behavior of authorization flows so that even
when the groups scope is not granted we still search for the upstream
group memberships as configured, and we pass the upstream group
memberships into any configured identity transformations. The identity
transformations could potentially reject the user's authentication based
on their upstream group membership.
When the groups scope is not granted, we don't include the groups in
the final Supervisor-issued ID token. This behavior is not changed.
Each endpoint handler is now responsible for applying the identity
transformations and creating most of the session data, rather than each
implementation of the upstream IDP interface. This shares code better,
and reduces the responsibilities of the implementations of the IDP
interface by letting them focus more on the upstream stuff.
Also refactor the parameters and return types of the IDP interfaces to
make them more clear, and because they can be more focused on upstream
identities (pre-identity transformation). This clarifies the
responsibilities of the implementations of the IDP interface.
Create an interface to abstract the upstream IDP from the
authorize, IDP discovery, callback, choose IDP, and login
endpoints. This commit does not refactor the token endpoint,
which will be refactored in a similar way in the next commit.
- continued refactoring the auth handler to share more code between
the two supported browserless flows: OIDC and LDAP/AD
- the upstreamldap package should not know about the concept of
OIDC granted scopes, so refactored it to be a skipGroups bool
- Simplify the error handling in the authorize endpoint by making the
private helper functions return fosite-style errors, and having
one place that writes those errors to the response.
- Some types of errors were previously returned as regular http-style
errors. Those have all been converted to be returned as oauth-style
errors (which can be redirects to the client), except for http method
not found errors. This is a change in behavior from the client's point
of view, but only when those unexpected errors happen. These types of
errors are more consistent with RFC6749 section 4.1.2.1.
- Avoids using the httperr package for error handling.
- Create a struct for the handler as a first step toward making smaller
functions with fewer parameters.
In the RFC8693 token exchange, the CLI sends your access token and
receives in exchange a new cluster-scoped ID token.
Fix a bug in the CLI. Whenever the "pinniped login oidc" command was
planning to perform the RFC8693 token exchange, it failed to check if
the cached access token was still valid before performing the exchange,
which sends the access token. It instead checked if the cached ID token
was still valid, but that it not relevant in this situation because the
ID token is not going to be used for anything (instead the new ID token
returned by the RFC8693 token exchange will be used for auth).
This bug doesn't actually matter today, because the Supervisor-issued
access and ID tokens always both have the same 2-minute lifetimes.
However, future enhancements may cause them to have different lifetimes
in certain circumstances. Fixing this CLI bug now to prepare for those
potential future enhancements.
Goboring only allows TLS 1.2.
The next goboring will allow both TLS 1.2 and TLS 1.3. We got a preview
of this when the Go team upgraded goboring in Go 1.21.6, but then
downgraded it again in the next Go releases.
When the Go team eventually upgrades goboring again, then we can
revert this commit to bring back TLS 1.3 support in FIPS mode.
- Current goboring only allows TLS 1.2.
- The next goboring will allow TLS 1.2 and TLS 1.3. We got a preview
of this when the Go team upgraded goboring in Go 1.21.6, but then
downgraded it again in the next Go releases.
The release of Go 1.21.6 includes the new boring crypto when compiling
with FIPS enabled. See https://go.dev/doc/devel/release#go1.21.0 and
https://github.com/golang/go/issues/64717.
This new version of boring crypto allows the use of TLS v1.3 for the
first time, so we changed the Pinniped code to use TLS v1.3 where
appropriate when compiled with the FIPS compiler. It also changed the
allowed TLS v1.2 ciphers, so we updated those as well.
After this commit, the project must be compiled by at least Go v1.21.6
when compiling in fips mode. The hack/Dockerfile_fips was already
updated to use that version of Go in a previous commit.
Co-authored-by: Benjamin A. Petersen <ben@benjaminapetersen.me>
A small part of the session storage changed type in the latest version
of fosite compared to the old version of fosite that we were using.
Just to be safe, update our session storage version to invalidate
any pre-existing sessions upon upgrade of Pinniped.
Made the switch wherever possible, but since fosite still uses the old
gopkg.in/square/go-jose.v2 there was one test where we still need to use
it as a direct dependency.
- update kind config to include local registry
- configure kind cluster to talk to local registry
- docker build & push pinniped dev code to local registry
- deploy dev code of the following via the local registry:
- concierge
- supervisor
- local-user-authenticator
- Update values.yaml for supervisor,concierge to schema files
- Update values.yaml for local-user-authenticator to schema file
- Add ytt openapi-v3 generation to build carvel package script
- Add supervisor carvel package files
- Add concierge carvel package files
- Add local-user-authenticator carvel package files
- Add hack script to build openapi-v3 files
- add --post-install to hack/prepare-for-integration-tests.sh
- cleanup local registry in kind-down.sh
- webhook_ca_bundle moved in hack script
- adjust were to call post-install script
- deploy/{}/values.yml image_pull_dockerconfigjson type change to base64 string
- Add PINNIPED_USE_LOCAL_KIND_REGISTRY env var
- ensures regular use of hack/prepare-for-integration-tests.sh
- PINNIPED_USE_LOCAL_KIND_REGISTRY=1 ./hack/prepare-for-integration-tests.sh --clean --alternate-deploy ./hack/noop.sh --post-install ./hack/build-carvel-packages.sh
- ./hack/prepare-for-integration-tests.sh --clean
- if PINNIPED_USE_LOCAL_KIND_REGISTRY for kind-down.sh in hack/prepare-for-integration-tests.sh
- Split carvel build & deploy scripts, add --pre-install flag
- add pre-install flag to hack/prepare-for-integration-tests.sh
- split /hack/build-carvel-packages.sh and
/hack/deploy-carvel-packages.sh
- Remove --alternate-deploy-* flags from hack script
- Move scripts to hack/lib/carvel_packages
- Split build.sh deploy.sh
- Separate template files from install artifacts
- Generate all install artifacts in $root/deploy_carvel
- remove $root/deploy_carvel from git
- Extract ytt values to file in hack/prepare-for-integration-tests.sh
- pass registry/repo to carvel build scripts
The unused-parameter linter became stricter, so we adjust it to
allow unused params that start with underscore. It can be nice to keep
unused param names when implementing an interface sometimes, to help
readers understand why it is unused in that particular implementation.
Skip showing the banner when the CLI does not know the IDP name
from the CLI args (which are typically encoded in the kubeconfig).
Co-authored-by: Joshua Casey <joshuatcasey@gmail.com>
Using Contour for ingress allows us to avoid using the hacky proxy
server approach. This makes it easy to use any web browser to complete
the login process, since there is no need to configure the proxy server
for the browser.
Before this fix, the deadlock would prevent the leader pod from giving
up its lease, which would make it take several minutes for new pods to
be allowed to elect a new leader. During that time, no Pinniped
controllers could write to the Kube API, so important resources were not
being updated during that window. It would also make pod shutdown take
about 1 minute.
After this fix, the leader gives up its lease immediately, and pod
shutdown takes about 1 second. This improves restart/upgrade time and
also fixes the problem where there was no leader for several minutes
after a restart/upgrade.
The deadlock was between the post-start hook and the pre-shutdown hook.
The pre-shutdown hook blocked until a certain background goroutine in
the post-start hook finished, but that goroutine could not finish until
the pre-shutdown hook finished. Thus, they were both blocked, waiting
for each other infinitely. Eventually the process would be externally
killed.
This deadlock was most likely introduced by some change in Kube's
generic api server package related to how the many complex channels used
during server shutdown interact with each other, and was not noticed
when we upgraded to the version which introduced the change.
These extra timeout contexts were only in the new multiple IDPs e2e
test. Remove this possible cause of test cleanup flakes where the test
runs slow enough in CI that this timeout context has already expired
and then the cleanup function fails with context deadline exceeded
errors.
To make the subject of the downstream ID token more unique when
there are multiple IDPs. It is possible to define two IDPs in a
FederationDomain using the same identity provider CR, in which
case the only thing that would make the subject claim different
is adding the IDP display name into the values of the subject claim.
- Remove that validation from the controller since the CRD already
validates it during creates and updates.
- Also finish the supervisor_federationdomain_status_test.go by adding
more tests for both controller validations and CRD validations
- Also fix small bug in controller where it used Sprintf wrong
- Rename WaitForTestFederationDomainStatus test helper to
WaitForFederationDomainStatusPhase
Also changes the transformation pipeline code to sort and uniq
the transformed group names at the end of the pipeline. This makes
the results more predicable without changing the semantics.
- Avoid a possible race condition where the status says "Ready" but
the endpoints take another moment to become available, potentially
casing a fast client to get a 404 after observing that the status
is "Ready" and then immediately trying to use the endpoints.
Co-authored-by: Benjamin A. Petersen <ben@benjaminapetersen.me>
- Refactor testlib.CreateTestFederationDomain helper
- Call testlib.WaitForTestFederationDomainStatus after each integration
test creates an IDP and expects the FederationDomain to become ready
- Create an IDP for some tests which want the FederationDomain to be
ready but were previously not creating any IDP
- Expect the new FederationDomain condition type
"IdentityProvidersFound" in those tests where it is needed
Co-authored-by: Joshua Casey <joshuatcasey@gmail.com>
- adds the truthy condition
- TODOs for falsy conditions
- addiional notes for other conditions
- tests updated to pass with the new condition
Co-authored-by: Ryan Richard <richardry@vmware.com>
- move pushd/popd inside if statements for alternative-deploy methods
- add specific alternative-deploy vars for individual components
- supervisor
- concierge
- local-user-authenticator
while preserving the current alternative-deploy for all three
- doc that equals for flags does not work
--foo=bar is invalid
--foo bar is valid
Used this as an opportunity to refactor how some tests were
making assertions about error strings.
New test helpers make it easy for an error string to be expected as an
exact string, as a string built using sprintf, as a regexp, or as a
string built to include the platform-specific x509 error string.
All of these helpers can be used in a single `wantErr` field of a test
table. They can be used for both unit tests and integration tests.
Co-authored-by: Benjamin A. Petersen <ben@benjaminapetersen.me>
- Specify mappings on OIDCIdentityProvider.spec.claims.additionalClaimMappings
- Advertise additionalClaims in the OIDC discovery endpoint under claims_supported
Co-authored-by: Ryan Richard <richardry@vmware.com>
Co-authored-by: Joshua Casey <joshuatcasey@gmail.com>
Also increase the timeout in an integration test because it is flaking
on one of the GKE environments sometimes, probably because the
Concierge controllers aren't ready fast enough before the integration
tests start.
The fuzzed value depends on which Go compiler is used. This breaks
the fips tests in CI as long as the fips compiler is a version behind
(we are still waiting for the 1.19 fips compiler to come out).
The fuzzing is still being tested by a separate unit test, so we are
not losing fuzzing test coverage.
- Upgrade Go used in CI from 1.19.0 to 1.19.1
- Upgrade all go.mod direct dependencies to latest available versions
- Upgrade distroless base image to latest available version
- Upgrade Go fips compiler to to latest available version
Note that upgrading the go-oidc library changed an error message
returned by that library, so update the places where tests were
expecting that error message.
When oidcclientsecretstorage.Set() wants to update the contents of the
storage Secret, it also wants to keep the original ownerRef of the
storage Secret, so it needs the middleware to rewrite the API group
of the ownerRef again during the update (just like it had initially done
during the create of the Secret).
Sets the Name, Namespace, CreationTimestamp fields in the object meta
of the return value.
Co-authored-by: Ryan Richard <richardry@vmware.com>
Co-authored-by: Benjamin A. Petersen <ben@benjaminapetersen.me>
- Change update-codegen.sh script to also generated openapi code for the
aggregated API types
- Update both aggregated API servers' configuration to make them serve
the openapi docs for the aggregated APIs
- Add new integration test which runs `kubectl explain` for all Pinniped
API resources, and all fields and subfields of those resources
- Update some the comments on the API structs
- Change some names of the tmpl files to make the filename better match
the struct names
This commit is a WIP commit because it doesn't include many tests
for the new feature.
Co-authored-by: Ryan Richard <richardry@vmware.com>
Co-authored-by: Benjamin A. Petersen <ben@benjaminapetersen.me>
Where possible, use securityContext settings which will work with the
most restrictive Pod Security Admission policy level (as of Kube 1.25).
Where privileged containers are needed, use the namespace-level
annotation to allow them.
Also adjust some integration tests to make similar changes to allow the
integration tests to pass on test clusters which use restricted PSAs.
This test is a little flaky in slow Kubernetes clusters. Try giving a
little more time for things to update before failing the test, to
hopefully make this test a little more reliable.
It seems that google changed it from "the gcp auth plugin is deprecated
in v1.22+, unavailable in v1.25+; use gcloud instead" to instead say
"unavailable in v1.26+". Make the matcher in category_test.go more loose
to allow both to match.
Also fix some tests that were broken by bumping golang and dependencies
in the previous commits.
Note that in addition to changes made to satisfy the linter which do not
impact the behavior of the code, this commit also adds ReadHeaderTimeout
to all usages of http.Server to satisfy the linter (and because it
seemed like a good suggestion).
Add the new `username` scope to the Supervisor and exclude usernames from dynamic clients which are not granted the scope, and other dynamic client related changes
When the token exchange grant type is used to get a cluster-scoped
ID token, the returned token has a new audience value. The client ID
of the client which performed the authorization was lost. This didn't
matter before, since the only client was `pinniped-cli`, but now that
dynamic clients can be registered, the information would be lost in the
cluster-scoped ID token. It could be useful for logging, tracing, or
auditing, so preserve the information by putting the client ID into the
`azp` claim in every ID token (authcode exchange, clsuter-scoped, and
refreshed ID tokens).
- For backwards compatibility with older Pinniped CLIs, the pinniped-cli
client does not need to request the username or groups scopes for them
to be granted. For dynamic clients, the usual OAuth2 rules apply:
the client must be allowed to request the scopes according to its
configuration, and the client must actually request the scopes in the
authorization request.
- If the username scope was not granted, then there will be no username
in the ID token, and the cluster-scoped token exchange will fail since
there would be no username in the resulting cluster-scoped ID token.
- The OIDC well-known discovery endpoint lists the username and groups
scopes in the scopes_supported list, and lists the username and groups
claims in the claims_supported list.
- Add username and groups scopes to the default list of scopes
put into kubeconfig files by "pinniped get kubeconfig" CLI command,
and the default list of scopes used by "pinniped login oidc" when
no list of scopes is specified in the kubeconfig file
- The warning header about group memberships changing during upstream
refresh will only be sent to the pinniped-cli client, since it is
only intended for kubectl and it could leak the username to the
client (which may not have the username scope granted) through the
warning message text.
- Add the user's username to the session storage as a new field, so that
during upstream refresh we can compare the original username from the
initial authorization to the refreshed username, even in the case when
the username scope was not granted (and therefore the username is not
stored in the ID token claims of the session storage)
- Bump the Supervisor session storage format version from 2 to 3
due to the username field being added to the session struct
- Extract commonly used string constants related to OIDC flows to api
package.
- Change some import names to make them consistent:
- Always import github.com/coreos/go-oidc/v3/oidc as "coreosoidc"
- Always import go.pinniped.dev/generated/latest/apis/supervisor/oidc
as "oidcapi"
- Always import go.pinniped.dev/internal/oidc as "oidc"
- Add dynamic client unit tests for the upstream OIDC callback and
POST login endpoints.
- Enhance a few log statements to print the full fosite error messages
into the logs where they were previously only printing the name of
the error type.
- Enhance the token exchange to check that the same client is used
compared to the client used during the original authorization and
token requests, and also check that the client has the token-exchange
grant type allowed in its configuration.
- Reduce the minimum required bcrypt cost for OIDCClient secrets
because 15 is too slow for real-life use, especially considering
that every login and every refresh flow will require two client auths.
- In unit tests, use bcrypt hashes with a cost of 4, because bcrypt
slows down by 13x when run with the race detector, and we run our
tests with the race detector enabled, causing the tests to be
unacceptably slow. The production code uses a higher minimum cost.
- Centralize all pre-computed bcrypt hashes used by unit tests to a
single place. Also extract some other useful test helpers for
unit tests related to OIDCClients.
- Add tons of unit tests for the token endpoint related to dynamic
clients for authcode exchanges, token exchanges, and refreshes.
This is only a first commit towards making this feature work.
- Hook dynamic clients into fosite by returning them from the storage
interface (after finding and validating them)
- In the auth endpoint, prevent the use of the username and password
headers for dynamic clients to force them to use the browser-based
login flows for all the upstream types
- Add happy path integration tests in supervisor_login_test.go
- Add lots of comments (and some small refactors) in
supervisor_login_test.go to make it much easier to understand
- Add lots of unit tests for the auth endpoint regarding dynamic clients
(more unit tests to be added for other endpoints in follow-up commits)
- Enhance crud.go to make lifetime=0 mean never garbage collect,
since we want client secret storage Secrets to last forever
- Move the OIDCClient validation code to a package where it can be
shared between the controller and the fosite storage interface
- Make shared test helpers for tests that need to create OIDC client
secret storage Secrets
- Create a public const for "pinniped-cli" now that we are using that
string in several places in the production code
The following validation is enforced:
1. Names must start with client.oauth.pinniped.dev-
2. Redirect URIs must start with https://
or http://127.0.0.1
or http://::1
3. All spec lists must not have duplicates
Added an integration test to assert all static validations.
Signed-off-by: Monis Khan <mok@vmware.com>
When response_mode=form_post is requested, some error cases will be
returned to the client using the form_post web page to POST the result
back to the client's redirect URL.
Also fix some comments that didn't fit onto one line in the yaml
examples, be consistent about putting a blank line above `---` yaml
separators, and some other small doc improvements.
Also:
- Add CSS to login page
- Refactor login page HTML and CSS into a new package
- New custom CSP headers for the login page, because the requirements
are different from the form_post page
Note that attempting to update 1.18.18 to 1.18.20 didn't work for some
reason, so I skipped that one. The code generator didn't like 1.18.20
and it deleted all the generated code. Avoiding 1.18.19 because it is
listed as having a regression at
https://kubernetes.io/releases/patch-releases/#non-active-branch-history
The other handlers for GET and POST requests are not yet implemented in
this commit. The shared handler code in login_handler.go takes care of
things checking the method, checking the CSRF cookie, decoding the state
param, and adding security headers on behalf of both the GET and POST
handlers.
Some code has been extracted from callback_handler.go to be shared.
Also fix some test failures on the callback handler, register the
new login handler in manager.go and add a (half baked) integration test
Signed-off-by: Margo Crawford <margaretc@vmware.com>
To keep this backwards compatible, this PR changes how
the cli deals with ambiguous flows. Previously, if there
was more than one flow advertised, the cli would require users
to set the flag --upstream-identity-provider-flow. Now it
chooses the first one in the list.
Signed-off-by: Margo Crawford <margaretc@vmware.com>
Go 1.18.1 started using MacOS' x509 verification APIs on Macs
rather than Go's own. The error messages are different.
Signed-off-by: Margo Crawford <margaretc@vmware.com>
We cannot use plog until the log level config has been setup, but
that occurs after this init function has run.
Signed-off-by: Monis Khan <mok@vmware.com>
- Use camel-case in the static configmap
- Parse the value into a boolean in the go struct instead of a string
- Add test for when unsupported value is used in the configmap
- Run the config_test.go tests in parallel
- Update some paragraphs in configure-supervisor.md for clarity
Add new deprecated_insecure_accept_external_unencrypted_http_requests
value in values.yaml. Allow it to be a boolean or a string to make it
easier to use (both --data-value and --data-value-yaml will work).
Also:
- Consider "ip6-localhost" and "ip6-loopback" to be loopback addresses
for the validation
- Remove unused env.SupervisorHTTPAddress var
- Deprecate the `service_http_*` values in values.yaml by renaming them
and causing a ytt render error when the old names are used
ory/x has new releases very often, sometimes multiple times per week,
causing a lot of noise from dependabot. We were barely using it
directly, so replace our direct usages with equivalent code.
You can use an older version of K8s on your development workstation
by temporarily editing kind-up.sh to add the `--image` flag. By defining
both v1beta2 and v1beta3 you should continue to be able to use old
versions of K8s in this way with Kind v0.12.0.
It appears that kind completely ignores kubeadm.k8s.io/v1beta2 config
starting in Kind v0.12.0.
You can observe the config being ignored or used by adding `-v 10` to
the command-line arguments of `kind create cluster` in kind-up.sh.
- Two of the linters changed their names
- Updated code and nolint comments to make all linters pass with 1.44.2
- Added a new hack/install-linter.sh script to help developers install
the expected version of the linter for local development
- Note that v0.8.0 no longer supports the "trivialVersions=true"
command-line option, so remove that from update-codegen.sh.
It doesn't seem to impact the output (our generated CRD yaml files).
Also:
- Make our code generator script work with Go 1.17
- Make our update.sh script work on linux
- Update the patch versions of the old Kube versions that we were using
to generate code (see kube-versions.txt)
- Use our container images from ghcr instead of
projects.registry.vmware.com for codegen purposes
- Make it easier to debug in the future by passing "-v" to the Kube
codegen scripts
- Updated copyright years to make commit checks pass
The purpose of this change is to allow Helm to be used to deploy Pinniped
into the local KinD cluster for the local integration tests. That said,
the change allows any alternate deployment mechanism, I just happen
to be using it with Helm.
All default behavior is preserved. This won't change how anyone uses the
script today, it just allows me not to copy/paste the whole setup for the
integration tests.
Changes:
1) An option called `--alternate-deploy <path-to-deploy-script>` has been
added, that when enabled calls the specified script instead of using ytt
and kapp. The alternate deploy script is called with the app to deploy
and the tag of the docker image to use. We set the default value of
the alternate_deploy variable to undefined, and there is a check that
tests if the alternate deploy is defined. For the superivsor it looks
like this:
```
if [ "$alternate_deploy" != "undefined" ]; then
log_note "The Pinniped Supervisor will be deployed with $alternate_deploy pinniped-supervisor $tag..."
$alternate_deploy pinniped-supervisor $tag
else
normal ytt/kapp deploy
fi
```
2) Additional log_note entries have been added to enumerate all values passed
into the ytt/kapp deploy. Used while I was trying to reach parity in the integration
tests, but I think they are useful for debugging.
3) The manifests produced by ytt and written to /tmp are now named individually.
This is so an easy comparison can be made between manifests produced by a ytt/kapp
run of integration tests and manifests produced by helm run of the integration tests.
If something is not working I have been comparing the manifests after these runs to
find differences.
This allows us to target browser based tests with the regex:
go test -v -race -count 1 -timeout 0 ./test/integration -run '/_Browser'
New tests that call browsertest.Open will automatically be forced to
follow this convention.
Signed-off-by: Monis Khan <mok@vmware.com>
When the POST to the CLI's localhost callback endpoint results in a
non-2XX status code, then treat that as a failed login attempt and
automatically show the manual copy/paste UI.
Just in case some future browser change sends some new kind of request
to our CLI, just ignore them by returning StatusMethodNotAllowed and
continuing to listen.
When the test was going to fail, a goroutine would accidentally block
on writing to an unbuffered channel, and the spawnTestGoroutine helper
would wait for that goroutine to end on cleanup, causing the test to
hang forever while it was trying to fail.
This is to support the new changes in Google Chrome v98 which now
performs CORS preflight requests for the Javascript form submission
on the Supervisor's login page, even though the form is being submitted
to a localhost listener.
This type of issue should only be opened if you intend to create a
formal proposal document. Please refer to the proposal process in
[proposals/README.md](proposals/README.md).
Please title this issue starting with `[Proposal]` followed by a
title for what you are going to propose. For example:
`[Proposal] Lunar landing module authentication via Pinniped`.
-->
### Proposal Tracking Issue
- Proposal: <!-- this starts empty, then please update to link to proposal PR, then also link to proposal doc file after it is merged -->
- Discussion Links: <!-- link to any mailing list threads, Slack conversations, community meetings, or other places where the proposal was discussed, if any -->
-<!-- A -->
-<!-- B -->
- Pull requests: <!-- link to all PRs related to this proposal such as updates to the proposal doc, implementation PRs, etc. - keep this list up to date -->
# For more details on CodeQL's query packs, refer to: https://docs.github.com/en/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning#using-queries-in-ql-packs
# queries: security-extended,security-and-quality
# Install Go.
# See https://github.com/actions/setup-go?tab=readme-ov-file#getting-go-version-from-the-gomod-file.
- uses:actions/setup-go@v5
with:
go-version-file:'go.mod'
# Autobuild attempts to build any compiled languages (C/C++, C#, or Java).
# If this step fails, then you should remove it and run the build manually (see below)
- name:Autobuild
uses:github/codeql-action/autobuild@v1
uses:github/codeql-action/autobuild@v3
# ℹ️ Command-line programs to run using the OS shell.
# 📚 https://git.io/JvXDl
# ✏️ If the Autobuild fails above, remove it and uncomment the following three lines
# and modify them (or add more) to build your code if your project
# uses a compiled language
# If the Autobuild fails above, remove it and uncomment the following three lines.
# modify them (or add more) to build your code if your project, please refer to the EXAMPLE below for guidance.
or in the Kubernetes Slack Workspace within the [#pinniped channel](https://kubernetes.slack.com/archives/C01BW364RJA).
or in the Kubernetes Slack Workspace within the [#pinniped channel](https://go.pinniped.dev/community/slack).
Join our [Google Group](https://go.pinniped.dev/community/group) to receive updates and meeting invitations.
## Issues
@@ -72,23 +64,38 @@ Please follow the procedure described in [SECURITY.md](SECURITY.md).
## CLA
We welcome contributions from everyone but we can only accept them if you sign
We welcome contributions from everyone, but we can only accept them if you sign
our Contributor License Agreement (CLA). If you would like to contribute and you
have not signed it, our CLA-bot will walk you through the process when you open
a Pull Request. For questions about the CLA process, see the
[FAQ](https://cla.vmware.com/faq) or submit a question through the GitHub issue
tracker.
## Learning about Pinniped
New to Pinniped?
- Start here to learn how to install and use Pinniped: [Learn to use Pinniped for federated authentication to Kubernetes clusters](https://pinniped.dev/docs/tutorials/concierge-and-supervisor-demo/)
- Start here to learn how to navigate the source code: [Code Walk-through](https://pinniped.dev/docs/reference/code-walkthrough/)
- Other more detailed documentation can be found at: [Pinniped Docs](https://pinniped.dev/docs/)
## Building
The [Dockerfile](Dockerfile) at the root of the repo can be used to build and
package the code. After making a change to the code, rebuild the docker image with the following command.
package the server-side code. After making a change to the code, rebuild the
docker image with the following command.
```bash
# From the root directory of the repo...
docker build .
```
The Pinniped CLI client can be built for local use with the following command.
@@ -4,48 +4,65 @@ This document defines the project governance for Pinniped.
# Overview
**Pinniped** is committed to building an open, inclusive, productive and self-governing open source community focused on building authentication services for Kubernetes clusters. The
community is governed by this document which defines how all members should work together to achieve this goal.
**Pinniped** is committed to building an open, inclusive, productive and self-governing open source community focused on
building authentication services for Kubernetes clusters. The community is governed by this document which defines how
all members should work together to achieve this goal.
# Code of Conduct
The Pinniped community abides by this [code of conduct](https://github.com/vmware-tanzu/pinniped/blob/main/CODE_OF_CONDUCT.md).
The Pinniped community abides by this
[code of conduct](https://github.com/vmware-tanzu/pinniped/blob/main/CODE_OF_CONDUCT.md).
# Community Roles
* **Users:** Members that engage with the Pinniped community via any medium (Slack, GitHub, mailing lists, etc.).
* **Contributors:** Do regular contributions to the Pinniped project (documentation, code reviews, responding to issues, participating in proposal discussions, contributing code, etc.).
* **Maintainers:** Responsible for the overall health and direction of the project. They are the final reviewers of PRs and responsible for Pinniped releases.
* **Contributors:** Do regular contributions to the Pinniped project (documentation, code reviews, responding to issues,
participating in proposal discussions, contributing code, etc.).
* **Maintainers:** Responsible for the overall health and direction of the project. They are the final reviewers of PRs
and responsible for Pinniped releases.
# Maintainers
New maintainers must be nominated by an existing maintainer and must be elected by a supermajority of existing maintainers. Likewise, maintainers can be removed by a supermajority of the existing maintainers or can resign by notifying one of the maintainers.
**Note:** If a maintainer leaves their employer they are still considered a maintainer of Pinniped, unless they voluntarily resign. Employment is not taken into consideration when determining maintainer eligibility unless the company itself violates our [Code of Conduct](https://github.com/vmware-tanzu/pinniped/blob/main/CODE_OF_CONDUCT.md).
New maintainers must be nominated by an existing maintainer and must be elected by a supermajority of existing
maintainers. Likewise, maintainers can be removed by a supermajority of the existing maintainers or can resign by
notifying one of the maintainers.
---
# Supermajority
A supermajority is defined as two-thirds of members in the group. A supermajority of Maintainers is required for certain decisions as outlined above. A supermajority vote is equivalent to the number of votes in favor of being at least twice the number of votes against. For example, if you have 5 maintainers, a supermajority vote is 4 votes. Voting on decisions can happen on the mailing list, GitHub, Slack, email, or via a voting service, when appropriate. Maintainers can either vote "agree, yes, +1", "disagree, no, -1", or "abstain". A vote passes when supermajority is met. An abstain vote equals not voting at all.
**Note:** If a maintainer leaves their employer they are still considered a maintainer of Pinniped, unless they
voluntarily resign. Employment is not taken into consideration when determining maintainer eligibility unless the
company itself violates our [Code of Conduct](https://github.com/vmware-tanzu/pinniped/blob/main/CODE_OF_CONDUCT.md).
---
# Decision Making
Ideally, all project decisions are resolved by consensus. If impossible, any maintainer may call a vote. Unless otherwise specified in this document, any vote will be decided by a supermajority of maintainers.
---
# Proposal Process
The proposal process is currently being worked on. No formal process is available at this time. You may reach out to the maintainers in the Kubernetes Slack Workspace within the [#pinniped](https://kubernetes.slack.com/archives/C01BW364RJA) channel or on the [Pinniped mailing list](project-pinniped@googlegroups.com) with any questions you may have or to send us your proposals.
Ideally, all project decisions are resolved by consensus. If impossible, any maintainer may call a vote. Unless
otherwise specified in this document, any vote will be decided by a supermajority of maintainers.
---
# Lazy Consensus
To maintain velocity in Pinniped, the concept of [Lazy Consensus](http://en.osswiki.info/concepts/lazy_consensus) is practiced. Ideas and / or proposals should be shared by maintainers via GitHub. Out of respect for other contributors, major changes should also be accompanied by a ping on the Kubernetes Slack in [#Pinniped](https://kubernetes.slack.com/archives/C01BW364RJA) or a note on the [Pinniped mailing list](project-pinniped@googlegroups.com) as appropriate. Author(s) of proposals for major changes will give a time period of no less than five (5) working days for comment and remain cognizant of popular observed world holidays.
## Supermajority
**What constitutes the need for a proposal?**
If there is significant risk with a potential feature or track of work (such as complexity, cost to implement, product viability, etc.), then we recommend creating a proposal for feedback and approval. If a potential feature is well understood and doesn't impose risk, then we recommend a **standard GitHub issue** to clarify the details.
A supermajority is defined as two-thirds of members in the group. A supermajority of maintainers is required for certain
decisions as outlined in this document. A supermajority vote is equivalent to the number of votes in favor being at
least twice the number of votes against. A vote to abstain equals not voting at all. For example, if you have 5
maintainers who all cast non-abstaining votes, then a supermajority vote is at least 4 votes in favor. Voting on
decisions can happen on the mailing list, GitHub, Slack, email, or via a voting service, when appropriate. Maintainers
can either vote "agree, yes, +1", "disagree, no, -1", or "abstain". A vote passes when supermajority is met.
Other maintainers may chime in and request additional time for review, but should remain cognizant of blocking progress and abstain from delaying progress unless absolutely needed. The expectation is that blocking progress is accompanied by a guarantee to review and respond to the relevant action in short order.
## Lazy Consensus
To maintain velocity in Pinniped, the concept of [Lazy Consensus](http://en.osswiki.info/concepts/lazy_consensus) is
practiced.
Other maintainers may chime in and request additional time for review, but should remain cognizant of blocking progress
and abstain from delaying progress unless absolutely needed. The expectation is that blocking progress is accompanied by
a guarantee to review and respond to the relevant action in short order.
Lazy consensus does not apply to the process of:
* Removal of maintainers from Pinniped
---
# Updating Governance
All substantive changes in Governance require a supermajority agreement by all maintainers.
## Updating Governance
All substantive changes in Governance, including substantive changes to the proposal process, require a supermajority
agreement by all maintainers.
# Proposal Process
The proposal process is defined in [proposals/README.md](proposals/README.md).
This document provides a high-level overview of the next big features the maintainers are planning to work on. This
should serve as a reference point for Pinniped users and contributors to understand where the project is heading, and
help determine if a contribution could be conflicting with a longer term plan.
###
**About this document**
### How to help
This document provides a link to the[ Pinniped Project issues](https://github.com/vmware-tanzu/pinniped/issues) list that serves as the up to date description of items that are in the Pinniped release pipeline. Most items are gathered from the community or include a feedback loop with the community. This should serve as a reference point for Pinniped users and contributors to understand where the project is heading, and help determine if a contribution could be conflicting with a longer term plan.
Discussion on the roadmap is welcomed. If you want to provide suggestions, use cases, and feedback to an item in the
roadmap, please reach out to the maintainers using one of the methods described in the project's
[Contributions](https://github.com/vmware-tanzu/pinniped/blob/main/CONTRIBUTING.md) to Pinniped are also welcomed.
### How to add an item to the roadmap
###
**How to help?**
One of the most important aspects in any open source community is the concept of proposals. Large changes to the
codebase and / or new features should be preceded by
a [proposal](https://github.com/vmware-tanzu/pinniped/tree/main/proposals) in our repo.
For smaller enhancements, you can open an issue to track that initiative or feature request.
We work with and rely on community feedback to focus our efforts to improve Pinniped and maintain a healthy roadmap.
Discussion on the roadmap can take place in threads under [Issues](https://github.com/vmware-tanzu/pinniped/issues) or in [community meetings](https://github.com/vmware-tanzu/pinniped/blob/main/CONTRIBUTING.md#meeting-with-the-maintainers). Please open and comment on an issue if you want to provide suggestions and feedback to an item in the roadmap. Please review the roadmap to avoid potential duplicated effort.
###
**Need an idea for a contribution?**
We’ve created an [Opportunity Areas](https://github.com/vmware-tanzu/pinniped/discussions/483) discussion thread that outlines some areas we believe are excellent starting points for the community to get involved. In that discussion we’ve included specific work items that one might consider that also support the high-level items presented in our roadmap.
###
**How to add an item to the roadmap?**
Please open an issue to track any initiative on the roadmap of Pinniped (usually driven by new feature requests). We will work with and rely on our community to focus our efforts to improve Pinniped.
###
**Current Roadmap**
The following table includes the current roadmap for Pinniped. If you have any questions or would like to contribute to Pinniped, please attend a [community meeting](https://github.com/vmware-tanzu/pinniped/blob/main/CONTRIBUTING.md#meeting-with-the-maintainers) to discuss with our team. If you don't know where to start, we are always looking for contributors that will help us reduce technical, automation, and documentation debt. Please take the timelines & dates as proposals and goals. Priorities and requirements change based on community feedback, roadblocks encountered, community contributions, etc. If you depend on a specific item, we encourage you to attend community meetings to get updated status information, or help us deliver that feature by contributing to Pinniped.
Last Updated: Sept 2021
|Theme|Description|Timeline|
|--|--|--|
|Improving Security Posture|Supervisor token refresh fails when the upstream refresh token no longer works for OIDC |Jan 2022|
|Improving Security Posture|Supervisor token refresh fails when the upstream user is in an invalid state for LDAP/AD |Jan 2022|
|Improving Security Posture|Support Audit logging of security events related to Authentication |April/May 2022|
|Improving Security Posture|mTLS for Supervisor sessions |Exploring/Ongoing|
|Improving Security Posture|Key management/rotation for Pinniped components with minimal downtime |Exploring/Ongoing|
|Improving Security Posture|Support for Session Logout |Exploring/Ongoing|
|Improving Security Posture|Support for Idle Session/ Inactivity timeout|Exploring/Ongoing|
|Improving Security Posture|Support for Max Concurrent Sessions|Exploring/Ongoing|
|Improving Security Posture|Support for configurable Session Length |Exploring/Ongoing|
|Improving Security Posture|Reject use of username and groups with system: prefix |Exploring/Ongoing|
|Improving Security Posture|Support for using external KMS for Supervisor signing keys |Exploring/Ongoing|
|Improving Security Posture|Client side use of Secure Enclaves for Session data |Exploring/Ongoing|
|Improving Security Posture|Enforce the use of HTTP Strict Transport (HSTS) |Exploring/Ongoing|
|Improving Security Posture|Assert that Pinniped runs under the restricted PSP version2 levels |Exploring/Ongoing|
|Wider Concierge cluster support|Support for OpenShift cluster types in the Concierge|Exploring/Ongoing|
|Identity transforms|Support prefixing, filtering, or performing coarse-grained checks on upstream users and groups|Exploring/Ongoing|
|CLI SSO|Support Kerberos based authentication on CLI |Exploring/Ongoing|
|Extended IDP support|Support more types of identity providers on the Supervisor|Exploring/Ongoing|
|Improved Documentation|Reorganizing and improving Pinniped docs; new how-to guides and tutorials|Exploring/Ongoing|
|Improve our CI/CD systems|Upgrade tests; make Kind more efficient and reliable for CI ; Windows tests; performance tests; scale tests; soak tests|Exploring/Ongoing|
|CLI Improvements|Improving CLI UX for setting up Supervisor IDPs|Exploring/Ongoing|
|Telemetry|Adding some useful phone home metrics as well as some vanity metrics|Exploring/Ongoing|
|Observability|Expose Pinniped metrics through Prometheus Integration|Exploring/Ongoing|
|Device Code Flow|Add support for OAuth 2.0 Device Authorization Grant in the Pinniped CLI and Supervisor|Exploring/Ongoing|
|Supervisor with New Clients|Enable registering new clients with Supervisor|Exploring/Ongoing|
Priorities and requirements change based on community feedback, roadblocks encountered, community contributions,
etc. If you depend on a specific item, we encourage you to reach out for updated status information, or help us deliver
that feature by [contributing](https://github.com/vmware-tanzu/pinniped/blob/main/CONTRIBUTING.md) to Pinniped.
// Allowed, when specified, indicates that only users with membership in at least one of the listed
// GitHub organizations may log in. In addition, the group membership presented to Kubernetes will only include
// teams within the listed GitHub organizations. Additional login rules or group filtering can optionally be
// provided as policy expression on any Pinniped Supervisor FederationDomain that includes this IDP.
//
// The configured GitHub App or GitHub OAuth App must be allowed to see membership in the listed organizations,
// otherwise Pinniped will not be aware that the user belongs to the listed organization or any teams
// within that organization.
//
// If no organizations are listed, you must set organizations: AllGitHubUsers.
//
// +kubebuilder:validation:MaxItems=64
// +listType=set
// +optional
Allowed[]string`json:"allowed,omitempty"`
}
// GitHubAllowAuthenticationSpec allows customization of who can authenticate using this IDP and how.
typeGitHubAllowAuthenticationSpecstruct{
// Organizations allows customization of which organizations can authenticate using this IDP.
// +kubebuilder:validation:XValidation:message="spec.allowAuthentication.organizations.policy must be 'OnlyUsersFromAllowedOrganizations' when spec.allowAuthentication.organizations.allowed has organizations listed",rule="!(has(self.allowed) && size(self.allowed) > 0 && self.policy == 'AllGitHubUsers')"
// +kubebuilder:validation:XValidation:message="spec.allowAuthentication.organizations.policy must be 'AllGitHubUsers' when spec.allowAuthentication.organizations.allowed is empty",rule="!((!has(self.allowed) || size(self.allowed) == 0) && self.policy == 'OnlyUsersFromAllowedOrganizations')"
f.StringVar(&flags.oidc.clientID,"oidc-client-id","pinniped-cli","OpenID Connect client ID (default: autodiscover)")
f.StringVar(&flags.oidc.clientID,"oidc-client-id",oidcapi.ClientIDPinnipedCLI,"OpenID Connect client ID (default: autodiscover)")
f.Uint16Var(&flags.oidc.listenPort,"oidc-listen-port",0,"TCP port for localhost listener (authorization code flow only)")
f.StringSliceVar(&flags.oidc.scopes,"oidc-scopes",[]string{oidc.ScopeOfflineAccess,oidc.ScopeOpenID,"pinniped:request-audience"},"OpenID Connect scopes to request during login")
f.StringSliceVar(&flags.oidc.scopes,"oidc-scopes",[]string{oidcapi.ScopeOfflineAccess,oidcapi.ScopeOpenID,oidcapi.ScopeRequestAudience,oidcapi.ScopeUsername,oidcapi.ScopeGroups},"OpenID Connect scopes to request during login")
f.BoolVar(&flags.oidc.skipBrowser,"oidc-skip-browser",false,"During OpenID Connect login, skip opening the browser (just print the URL)")
f.BoolVar(&flags.oidc.debugSessionCache,"oidc-debug-session-cache",false,"Print debug logs related to the OpenID Connect session cache")
f.StringVar(&flags.oidc.requestAudience,"oidc-request-audience","","Request a token with an alternate audience using RFC8693 token exchange")
f.StringVar(&flags.oidc.upstreamIDPName,"upstream-identity-provider-name","","The name of the upstream identity provider used during login with a Supervisor")
f.StringVar(&flags.oidc.upstreamIDPType,"upstream-identity-provider-type","",fmt.Sprintf("The type of the upstream identity provider used during login with a Supervisor (e.g. '%s', '%s', '%s')",idpdiscoveryv1alpha1.IDPTypeOIDC,idpdiscoveryv1alpha1.IDPTypeLDAP,idpdiscoveryv1alpha1.IDPTypeActiveDirectory))
f.StringVar(
&flags.oidc.upstreamIDPType,
"upstream-identity-provider-type",
"",
fmt.Sprintf(
"The type of the upstream identity provider used during login with a Supervisor (e.g. '%s', '%s', '%s', '%s')",
idpdiscoveryv1alpha1.IDPTypeOIDC,
idpdiscoveryv1alpha1.IDPTypeLDAP,
idpdiscoveryv1alpha1.IDPTypeActiveDirectory,
idpdiscoveryv1alpha1.IDPTypeGitHub,
),
)
f.StringVar(&flags.oidc.upstreamIDPFlow,"upstream-identity-provider-flow","",fmt.Sprintf("The type of client flow to use with the upstream identity provider during login with a Supervisor (e.g. '%s', '%s')",idpdiscoveryv1alpha1.IDPFlowCLIPassword,idpdiscoveryv1alpha1.IDPFlowBrowserAuthcode))
f.StringVar(&flags.kubeconfigPath,"kubeconfig",os.Getenv("KUBECONFIG"),"Path to kubeconfig file")
f.StringVar(&flags.kubeconfigContextOverride,"kubeconfig-context","","Kubeconfig context name (default: current active context)")
f.StringVar(&flags.generatedNameSuffix,"generated-name-suffix","-pinniped","Suffix to append to generated cluster, context, user kubeconfig entries")
f.StringVar(&flags.credentialCachePath,"credential-cache","","Path to cluster-specific credentials cache")
f.StringVar(&flags.pinnipedCliPath,"pinniped-cli-path","","Full path or executable name for the Pinniped CLI binary to be embedded in the resulting kubeconfig output (e.g. 'pinniped') (default: full path of the binary used to execute this command)")
f.StringVar(&flags.installHint,"install-hint","The pinniped CLI does not appear to be installed. See https://get.pinniped.dev/cli for more details","This text is shown to the user when the pinniped CLI is not installed.")
mustMarkHidden(cmd,"oidc-debug-session-cache")
// --oidc-skip-listen is mainly needed for testing. We'll leave it hidden until we have a non-testing use case.
mustMarkHidden(cmd,"oidc-skip-listen")
mustMarkHidden(cmd,
"oidc-debug-session-cache",
"oidc-skip-listen",// --oidc-skip-listen is mainly needed for testing. We'll leave it hidden until we have a non-testing use case.
cmd.Flags().Uint16Var(&flags.listenPort,"listen-port",0,"TCP port for localhost listener (authorization code flow only)")
cmd.Flags().StringSliceVar(&flags.scopes,"scopes",[]string{oidc.ScopeOfflineAccess,oidc.ScopeOpenID,"pinniped:request-audience"},"OIDC scopes to request during login")
cmd.Flags().StringSliceVar(&flags.scopes,"scopes",[]string{oidcapi.ScopeOfflineAccess,oidcapi.ScopeOpenID,oidcapi.ScopeRequestAudience,oidcapi.ScopeUsername,oidcapi.ScopeGroups},"OIDC scopes to request during login")
cmd.Flags().BoolVar(&flags.skipBrowser,"skip-browser",false,"Skip opening the browser (just print the URL)")
cmd.Flags().BoolVar(&flags.skipListen,"skip-listen",false,"Skip starting a localhost callback listener (manual copy/paste flow only)")
cmd.Flags().StringVar(&flags.sessionCachePath,"session-cache",filepath.Join(mustGetConfigDir(),"sessions.yaml"),"Path to session cache file")
cmd.Flags().StringVar(&flags.conciergeAPIGroupSuffix,"concierge-api-group-suffix",groupsuffix.PinnipedDefaultSuffix,"Concierge API group suffix")
cmd.Flags().StringVar(&flags.credentialCachePath,"credential-cache",filepath.Join(mustGetConfigDir(),"credentials.yaml"),"Path to cluster-specific credentials cache (\"\" disables the cache)")
cmd.Flags().StringVar(&flags.upstreamIdentityProviderName,"upstream-identity-provider-name","","The name of the upstream identity provider used during login with a Supervisor")
cmd.Flags().StringVar(&flags.upstreamIdentityProviderType,"upstream-identity-provider-type",idpdiscoveryv1alpha1.IDPTypeOIDC.String(),fmt.Sprintf("The type of the upstream identity provider used during login with a Supervisor (e.g. '%s', '%s', '%s')",idpdiscoveryv1alpha1.IDPTypeOIDC,idpdiscoveryv1alpha1.IDPTypeLDAP,idpdiscoveryv1alpha1.IDPTypeActiveDirectory))
"The type of the upstream identity provider used during login with a Supervisor (e.g. '%s', '%s', '%s', '%s')",
idpdiscoveryv1alpha1.IDPTypeOIDC,
idpdiscoveryv1alpha1.IDPTypeLDAP,
idpdiscoveryv1alpha1.IDPTypeActiveDirectory,
idpdiscoveryv1alpha1.IDPTypeGitHub,
))
cmd.Flags().StringVar(&flags.upstreamIdentityProviderFlow,"upstream-identity-provider-flow","",fmt.Sprintf("The type of client flow to use with the upstream identity provider during login with a Supervisor (e.g. '%s', '%s')",idpdiscoveryv1alpha1.IDPFlowBrowserAuthcode,idpdiscoveryv1alpha1.IDPFlowCLIPassword))
// --skip-listen is mainly needed for testing. We'll leave it hidden until we have a non-testing use case.
--listen-port uint16 TCP port for localhost listener (authorization code flow only)
--request-audience string Request a token with an alternate audience using RFC8693 token exchange
--scopes strings OIDC scopes to request during login (default [offline_access,openid,pinniped:request-audience])
--scopes strings OIDC scopes to request during login (default [offline_access,openid,pinniped:request-audience,username,groups])
--session-cache string Path to session cache file (default "`+cfgDir+`/sessions.yaml")
--skip-browser Skip opening the browser (just print the URL)
--upstream-identity-provider-flow string The type of client flow to use with the upstream identity provider during login with a Supervisor (e.g. 'browser_authcode', 'cli_password')
--upstream-identity-provider-name string The name of the upstream identity provider used during login with a Supervisor
--upstream-identity-provider-type string The type of the upstream identity provider used during login with a Supervisor (e.g. 'oidc', 'ldap', 'activedirectory') (default "oidc")
--upstream-identity-provider-type string The type of the upstream identity provider used during login with a Supervisor (e.g. 'oidc', 'ldap', 'activedirectory', 'github') (default "oidc")
Error: invalid Concierge parameters: invalid API group suffix: a lowercase RFC 1123 subdomain must consist of lower case alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character (e.g. 'example.com', regex used for validation is '[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*')
`),
},
{
name:"invalid upstream type",
args:[]string{
"--issuer","test-issuer",
"--upstream-identity-provider-type","invalid",
},
wantError:true,
wantStderr:here.Doc(`
Error: --upstream-identity-provider-type value not recognized: invalid (supported values: oidc, ldap, activedirectory)
`),
},
{
name:"oidc upstream type with default flow is allowed",
name:"oidc upstream type with unsupported flow is an error",
args:[]string{
"--issuer","test-issuer",
"--client-id","test-client-id",
"--upstream-identity-provider-type","oidc",
"--upstream-identity-provider-flow","foobar",
"--credential-cache","",// must specify --credential-cache or else the cache file on disk causes test pollution
},
wantError:true,
wantStderr:here.Doc(`
Error: --upstream-identity-provider-flow value not recognized for identity provider type "oidc": foobar (supported values: browser_authcode, cli_password)
`),
},
{
name:"ldap upstream type with default flow is allowed",
args:[]string{
"--issuer","test-issuer",
"--client-id","test-client-id",
"--upstream-identity-provider-type","ldap",
"--credential-cache","",// must specify --credential-cache or else the cache file on disk causes test pollution
"--upstream-identity-provider-flow","browser_authcode",// "browser_authcode" is only supported for OIDC upstreams
"--credential-cache","",// must specify --credential-cache or else the cache file on disk causes test pollution
},
wantError:true,
wantStderr:here.Doc(`
Error: --upstream-identity-provider-flow value not recognized for identity provider type "activedirectory": browser_authcode (supported values: [cli_password])
cmd.Flags().StringVar(&flags.conciergeAPIGroupSuffix,"concierge-api-group-suffix",groupsuffix.PinnipedDefaultSuffix,"Concierge API group suffix")
cmd.Flags().StringVar(&flags.credentialCachePath,"credential-cache",filepath.Join(mustGetConfigDir(),"credentials.yaml"),"Path to cluster-specific credentials cache (\"\" disables the cache)")
wantStderr:"Error: could not complete WhoAmIRequest (is the Pinniped WhoAmI API running and healthy?): whoamirequests.identity.concierge.pinniped.dev \"whatever\" not found\n",
description:"JWTAuthenticator describes the configuration of a JWT authenticator.
\n Upon receiving a signed JWT, a JWTAuthenticator will performs some validation
on it (e.g., valid signature, existence of claims, etc.) and extract the
username and groups from the token."
description:|-
JWTAuthenticator describes the configuration of a JWT authenticator.
Upon receiving a signed JWT, a JWTAuthenticator will performs some validation on it (e.g., valid
signature, existence of claims, etc.) and extract the username and groups from the token.
properties:
apiVersion:
description:'APIVersion defines the versioned schema of this representation
of an object. Servers should convert recognized schemas to the latest
internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources'
description:|-
APIVersion defines the versioned schema of this representation of an object.
Servers should convert recognized schemas to the latest internal value, and
may reject unrecognized values.
More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources
type:string
kind:
description:'Kind is a string value representing the REST resource this
object represents. Servers may infer this from the endpoint the client
submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds'
description:|-
Kind is a string value representing the REST resource this object represents.
Servers may infer this from the endpoint the client submits requests to.
Cannot be updated.
In CamelCase.
More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds
type:string
metadata:
type:object
@@ -58,24 +63,25 @@ spec:
minLength:1
type:string
claims:
description:Claims allows customization of the claims that will be
mapped to user identity for Kubernetes access.
description:|-
Claims allows customization of the claims that will be mapped to user identity
for Kubernetes access.
properties:
groups:
description:Groups is the name of the claim which should be read
to extract the user's group membership from the JWT token. When
not specified, it will default to "groups".
description:|-
Groups is the name of the claim which should be read to extract the user's
group membership from the JWT token. When not specified, it will default to "groups".
type:string
username:
description:Username is the name of the claim which should be
read to extract the username from the JWT token. When not specified,
it will default to "username".
description:|-
Username is the name of the claim which should be read to extract the
username from the JWT token. When not specified, it will default to "username".
type:string
type:object
issuer:
description:Issuer is the OIDC issuer URL that will be used to discover
public signing keys. Issuer is also used to validate the "iss" JWT
claim.
description:|-
Issuer is the OIDC issuer URL that will be used to discover public signing keys. Issuer is
also used to validate the "iss" JWT claim.
minLength:1
pattern:^https://
type:string
@@ -98,37 +104,43 @@ spec:
description:Represents the observations of the authenticator's current
state.
items:
description:Condition status of a resource (mirrored from the metav1.Condition
type added in Kubernetes 1.19). In a future API version we can
switch to using the upstream type. See https://github.com/kubernetes/apimachinery/blob/v0.19.0/pkg/apis/meta/v1/types.go#L1353-L1413.
description:"Condition contains details for one aspect of the current
state of this API Resource.\n---\nThis struct is intended for
direct use as an array at the field path .status.conditions. For
example,\n\n\n\ttype FooStatus struct{\n\t // Represents the
observations of a foo's current state.\n\t // Known .status.conditions.type
are: \"Available\", \"Progressing\", and \"Degraded\"\n\t //
description:'APIVersion defines the versioned schema of this representation
of an object. Servers should convert recognized schemas to the latest
internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources'
description:|-
APIVersion defines the versioned schema of this representation of an object.
Servers should convert recognized schemas to the latest internal value, and
may reject unrecognized values.
More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources
type:string
kind:
description:'Kind is a string value representing the REST resource this
object represents. Servers may infer this from the endpoint the client
submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds'
description:|-
Kind is a string value representing the REST resource this object represents.
Servers may infer this from the endpoint the client submits requests to.
Cannot be updated.
In CamelCase.
More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds
type:string
metadata:
type:object
@@ -71,37 +74,43 @@ spec:
description:Represents the observations of the authenticator's current
state.
items:
description:Condition status of a resource (mirrored from the metav1.Condition
type added in Kubernetes 1.19). In a future API version we can
switch to using the upstream type. See https://github.com/kubernetes/apimachinery/blob/v0.19.0/pkg/apis/meta/v1/types.go#L1353-L1413.
description:"Condition contains details for one aspect of the current
state of this API Resource.\n---\nThis struct is intended for
direct use as an array at the field path .status.conditions. For
example,\n\n\n\ttype FooStatus struct{\n\t // Represents the
observations of a foo's current state.\n\t // Known .status.conditions.type
are: \"Available\", \"Progressing\", and \"Degraded\"\n\t //
description:Phase summarizes the overall status of the WebhookAuthenticator.
enum:
- Pending
- Ready
- Error
type:string
type:object
required:
- spec
@@ -142,9 +160,3 @@ spec:
storage:true
subresources:
status:{}
status:
acceptedNames:
kind:""
plural:""
conditions:[]
storedVersions:[]
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
