djpbessems/ContainerImage.Pinniped
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
4878ae77e5
ContainerImage.Pinniped/internal/groupsuffix/groupsuffix_test.go

657 lines
25 KiB
Go
Raw Normal View History

Allow multiple Pinnipeds to work on same cluster Yes, this is a huge commit. The middleware allows you to customize the API groups of all of the *.pinniped.dev API groups. Some notes about other small things in this commit: - We removed the internal/client package in favor of pkg/conciergeclient. The two packages do basically the same thing. I don't think we use the former anymore. - We re-enabled cluster-scoped owner assertions in the integration tests. This code was added in internal/ownerref. See a0546942 for when this assertion was removed. - Note: the middlware code is in charge of restoring the GV of a request object, so we should never need to write mutations that do that. - We updated the supervisor secret generation to no longer manually set an owner reference to the deployment since the middleware code now does this. I think we still need some way to make an initial event for the secret generator controller, which involves knowing the namespace and the name of the generated secret, so I still wired the deployment through. We could use a namespace/name tuple here, but I was lazy. Signed-off-by: Andrew Keesler <akeesler@vmware.com> Co-authored-by: Ryan Richard <richardry@vmware.com>
2021-01-13 01:27:41 +00:00
// Copyright 2021 the Pinniped contributors. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
package groupsuffix
import (
"context"
"fmt"
"strings"
"testing"
"github.com/stretchr/testify/require"
corev1 "k8s.io/api/core/v1"
metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
"k8s.io/apimachinery/pkg/runtime/schema"
Use new 'go.pinniped.dev/generated/latest' package. Signed-off-by: Matt Moyer <moyerm@vmware.com>
2021-02-16 19:00:08 +00:00
authv1alpha1 "go.pinniped.dev/generated/latest/apis/concierge/authentication/v1alpha1"
loginv1alpha1 "go.pinniped.dev/generated/latest/apis/concierge/login/v1alpha1"
configv1alpha1 "go.pinniped.dev/generated/latest/apis/supervisor/config/v1alpha1"
Allow multiple Pinnipeds to work on same cluster Yes, this is a huge commit. The middleware allows you to customize the API groups of all of the *.pinniped.dev API groups. Some notes about other small things in this commit: - We removed the internal/client package in favor of pkg/conciergeclient. The two packages do basically the same thing. I don't think we use the former anymore. - We re-enabled cluster-scoped owner assertions in the integration tests. This code was added in internal/ownerref. See a0546942 for when this assertion was removed. - Note: the middlware code is in charge of restoring the GV of a request object, so we should never need to write mutations that do that. - We updated the supervisor secret generation to no longer manually set an owner reference to the deployment since the middleware code now does this. I think we still need some way to make an initial event for the secret generator controller, which involves knowing the namespace and the name of the generated secret, so I still wired the deployment through. We could use a namespace/name tuple here, but I was lazy. Signed-off-by: Andrew Keesler <akeesler@vmware.com> Co-authored-by: Ryan Richard <richardry@vmware.com>
2021-01-13 01:27:41 +00:00
"go.pinniped.dev/internal/kubeclient"
"go.pinniped.dev/internal/testutil"
)
func ExampleReplace_loginv1alpha1() {
s, _ := Replace(loginv1alpha1.GroupName, "tuna.fish.io")
fmt.Println(s)
// Output: login.concierge.tuna.fish.io
}
func ExampleReplace_string() {
s, _ := Replace("idp.supervisor.pinniped.dev", "marlin.io")
fmt.Println(s)
// Output: idp.supervisor.marlin.io
}
internal/groupsuffix: mutate TokenCredentialRequest's Authenticator This is a partial revert of 288d9c999efe. For some reason it didn't occur to me that we could do it this way earlier. Whoops. This also contains a middleware update: mutation funcs can return an error now and short-circuit the rest of the request/response flow. The idea here is that if someone is configuring their kubeclient to use middleware, they are agreeing to a narrow-er client contract by doing so (e.g., their TokenCredentialRequest's must have an Spec.Authenticator.APIGroup set). I also updated some internal/groupsuffix tests to be more realistic. Signed-off-by: Andrew Keesler <akeesler@vmware.com>
2021-02-05 01:02:59 +00:00
Allow multiple Pinnipeds to work on same cluster Yes, this is a huge commit. The middleware allows you to customize the API groups of all of the *.pinniped.dev API groups. Some notes about other small things in this commit: - We removed the internal/client package in favor of pkg/conciergeclient. The two packages do basically the same thing. I don't think we use the former anymore. - We re-enabled cluster-scoped owner assertions in the integration tests. This code was added in internal/ownerref. See a0546942 for when this assertion was removed. - Note: the middlware code is in charge of restoring the GV of a request object, so we should never need to write mutations that do that. - We updated the supervisor secret generation to no longer manually set an owner reference to the deployment since the middleware code now does this. I think we still need some way to make an initial event for the secret generator controller, which involves knowing the namespace and the name of the generated secret, so I still wired the deployment through. We could use a namespace/name tuple here, but I was lazy. Signed-off-by: Andrew Keesler <akeesler@vmware.com> Co-authored-by: Ryan Richard <richardry@vmware.com>
2021-01-13 01:27:41 +00:00
func TestMiddlware(t *testing.T) {
const newSuffix = "some.suffix.com"
podWithoutOwner := &corev1.Pod{
TypeMeta: metav1.TypeMeta{
APIVersion: corev1.SchemeGroupVersion.String(),
Kind: "Pod",
},
ObjectMeta: metav1.ObjectMeta{
OwnerReferences: []metav1.OwnerReference{},
},
}
nonPinnipedOwner := &corev1.Pod{
ObjectMeta: metav1.ObjectMeta{
Name: "some-name",
UID: "some-uid",
},
}
nonPinnipedOwnerGVK := corev1.SchemeGroupVersion.WithKind("Pod")
podWithNonPinnipedOwner := &corev1.Pod{
TypeMeta: metav1.TypeMeta{
APIVersion: corev1.SchemeGroupVersion.String(),
Kind: "Pod",
},
ObjectMeta: metav1.ObjectMeta{
OwnerReferences: []metav1.OwnerReference{
*metav1.NewControllerRef(nonPinnipedOwner, nonPinnipedOwnerGVK),
},
},
}
var ok bool
pinnipedOwner := &configv1alpha1.FederationDomain{
ObjectMeta: metav1.ObjectMeta{
Name: "some-name",
UID: "some-uid",
},
}
pinnipedOwnerGVK := configv1alpha1.SchemeGroupVersion.WithKind("FederationDomain")
pinnipedOwnerWithNewGroupGVK := configv1alpha1.SchemeGroupVersion.WithKind("FederationDomain")
pinnipedOwnerWithNewGroupGVK.Group, ok = Replace(pinnipedOwnerWithNewGroupGVK.Group, newSuffix)
require.True(t, ok)
podWithPinnipedOwner := &corev1.Pod{
TypeMeta: metav1.TypeMeta{
APIVersion: corev1.SchemeGroupVersion.String(),
Kind: "Pod",
},
ObjectMeta: metav1.ObjectMeta{
OwnerReferences: []metav1.OwnerReference{
*metav1.NewControllerRef(pinnipedOwner, pinnipedOwnerGVK),
// make sure we don't update the non-pinniped owner
*metav1.NewControllerRef(nonPinnipedOwner, nonPinnipedOwnerGVK),
},
},
}
podWithPinnipedOwnerWithNewGroup := &corev1.Pod{
TypeMeta: metav1.TypeMeta{
APIVersion: corev1.SchemeGroupVersion.String(),
Kind: "Pod",
},
ObjectMeta: metav1.ObjectMeta{
OwnerReferences: []metav1.OwnerReference{
*metav1.NewControllerRef(pinnipedOwner, pinnipedOwnerWithNewGroupGVK),
// make sure we don't update the non-pinniped owner
*metav1.NewControllerRef(nonPinnipedOwner, nonPinnipedOwnerGVK),
},
},
}
federationDomainWithPinnipedOwner := &configv1alpha1.FederationDomain{
TypeMeta: metav1.TypeMeta{
APIVersion: configv1alpha1.SchemeGroupVersion.String(),
Kind: "FederationDomain",
},
ObjectMeta: metav1.ObjectMeta{
OwnerReferences: []metav1.OwnerReference{
*metav1.NewControllerRef(pinnipedOwner, pinnipedOwnerGVK),
// make sure we don't update the non-pinniped owner
*metav1.NewControllerRef(nonPinnipedOwner, nonPinnipedOwnerGVK),
},
},
}
internal/groupsuffix: mutate TokenCredentialRequest's Authenticator This is a partial revert of 288d9c999efe. For some reason it didn't occur to me that we could do it this way earlier. Whoops. This also contains a middleware update: mutation funcs can return an error now and short-circuit the rest of the request/response flow. The idea here is that if someone is configuring their kubeclient to use middleware, they are agreeing to a narrow-er client contract by doing so (e.g., their TokenCredentialRequest's must have an Spec.Authenticator.APIGroup set). I also updated some internal/groupsuffix tests to be more realistic. Signed-off-by: Andrew Keesler <akeesler@vmware.com>
2021-02-05 01:02:59 +00:00
federationDomainWithNewGroupAndPinnipedOwner := &configv1alpha1.FederationDomain{
Allow multiple Pinnipeds to work on same cluster Yes, this is a huge commit. The middleware allows you to customize the API groups of all of the *.pinniped.dev API groups. Some notes about other small things in this commit: - We removed the internal/client package in favor of pkg/conciergeclient. The two packages do basically the same thing. I don't think we use the former anymore. - We re-enabled cluster-scoped owner assertions in the integration tests. This code was added in internal/ownerref. See a0546942 for when this assertion was removed. - Note: the middlware code is in charge of restoring the GV of a request object, so we should never need to write mutations that do that. - We updated the supervisor secret generation to no longer manually set an owner reference to the deployment since the middleware code now does this. I think we still need some way to make an initial event for the secret generator controller, which involves knowing the namespace and the name of the generated secret, so I still wired the deployment through. We could use a namespace/name tuple here, but I was lazy. Signed-off-by: Andrew Keesler <akeesler@vmware.com> Co-authored-by: Ryan Richard <richardry@vmware.com>
2021-01-13 01:27:41 +00:00
TypeMeta: metav1.TypeMeta{
internal/groupsuffix: mutate TokenCredentialRequest's Authenticator This is a partial revert of 288d9c999efe. For some reason it didn't occur to me that we could do it this way earlier. Whoops. This also contains a middleware update: mutation funcs can return an error now and short-circuit the rest of the request/response flow. The idea here is that if someone is configuring their kubeclient to use middleware, they are agreeing to a narrow-er client contract by doing so (e.g., their TokenCredentialRequest's must have an Spec.Authenticator.APIGroup set). I also updated some internal/groupsuffix tests to be more realistic. Signed-off-by: Andrew Keesler <akeesler@vmware.com>
2021-02-05 01:02:59 +00:00
APIVersion: replaceGV(t, configv1alpha1.SchemeGroupVersion, newSuffix).String(),
Allow multiple Pinnipeds to work on same cluster Yes, this is a huge commit. The middleware allows you to customize the API groups of all of the *.pinniped.dev API groups. Some notes about other small things in this commit: - We removed the internal/client package in favor of pkg/conciergeclient. The two packages do basically the same thing. I don't think we use the former anymore. - We re-enabled cluster-scoped owner assertions in the integration tests. This code was added in internal/ownerref. See a0546942 for when this assertion was removed. - Note: the middlware code is in charge of restoring the GV of a request object, so we should never need to write mutations that do that. - We updated the supervisor secret generation to no longer manually set an owner reference to the deployment since the middleware code now does this. I think we still need some way to make an initial event for the secret generator controller, which involves knowing the namespace and the name of the generated secret, so I still wired the deployment through. We could use a namespace/name tuple here, but I was lazy. Signed-off-by: Andrew Keesler <akeesler@vmware.com> Co-authored-by: Ryan Richard <richardry@vmware.com>
2021-01-13 01:27:41 +00:00
Kind: "FederationDomain",
},
ObjectMeta: metav1.ObjectMeta{
OwnerReferences: []metav1.OwnerReference{
internal/groupsuffix: mutate TokenCredentialRequest's Authenticator This is a partial revert of 288d9c999efe. For some reason it didn't occur to me that we could do it this way earlier. Whoops. This also contains a middleware update: mutation funcs can return an error now and short-circuit the rest of the request/response flow. The idea here is that if someone is configuring their kubeclient to use middleware, they are agreeing to a narrow-er client contract by doing so (e.g., their TokenCredentialRequest's must have an Spec.Authenticator.APIGroup set). I also updated some internal/groupsuffix tests to be more realistic. Signed-off-by: Andrew Keesler <akeesler@vmware.com>
2021-02-05 01:02:59 +00:00
*metav1.NewControllerRef(pinnipedOwner, pinnipedOwnerGVK),
Allow multiple Pinnipeds to work on same cluster Yes, this is a huge commit. The middleware allows you to customize the API groups of all of the *.pinniped.dev API groups. Some notes about other small things in this commit: - We removed the internal/client package in favor of pkg/conciergeclient. The two packages do basically the same thing. I don't think we use the former anymore. - We re-enabled cluster-scoped owner assertions in the integration tests. This code was added in internal/ownerref. See a0546942 for when this assertion was removed. - Note: the middlware code is in charge of restoring the GV of a request object, so we should never need to write mutations that do that. - We updated the supervisor secret generation to no longer manually set an owner reference to the deployment since the middleware code now does this. I think we still need some way to make an initial event for the secret generator controller, which involves knowing the namespace and the name of the generated secret, so I still wired the deployment through. We could use a namespace/name tuple here, but I was lazy. Signed-off-by: Andrew Keesler <akeesler@vmware.com> Co-authored-by: Ryan Richard <richardry@vmware.com>
2021-01-13 01:27:41 +00:00
// make sure we don't update the non-pinniped owner
*metav1.NewControllerRef(nonPinnipedOwner, nonPinnipedOwnerGVK),
},
},
}
federationDomainWithNewGroupAndPinnipedOwnerWithNewGroup := &configv1alpha1.FederationDomain{
TypeMeta: metav1.TypeMeta{
internal/groupsuffix: mutate TokenCredentialRequest's Authenticator This is a partial revert of 288d9c999efe. For some reason it didn't occur to me that we could do it this way earlier. Whoops. This also contains a middleware update: mutation funcs can return an error now and short-circuit the rest of the request/response flow. The idea here is that if someone is configuring their kubeclient to use middleware, they are agreeing to a narrow-er client contract by doing so (e.g., their TokenCredentialRequest's must have an Spec.Authenticator.APIGroup set). I also updated some internal/groupsuffix tests to be more realistic. Signed-off-by: Andrew Keesler <akeesler@vmware.com>
2021-02-05 01:02:59 +00:00
APIVersion: replaceGV(t, configv1alpha1.SchemeGroupVersion, newSuffix).String(),
Allow multiple Pinnipeds to work on same cluster Yes, this is a huge commit. The middleware allows you to customize the API groups of all of the *.pinniped.dev API groups. Some notes about other small things in this commit: - We removed the internal/client package in favor of pkg/conciergeclient. The two packages do basically the same thing. I don't think we use the former anymore. - We re-enabled cluster-scoped owner assertions in the integration tests. This code was added in internal/ownerref. See a0546942 for when this assertion was removed. - Note: the middlware code is in charge of restoring the GV of a request object, so we should never need to write mutations that do that. - We updated the supervisor secret generation to no longer manually set an owner reference to the deployment since the middleware code now does this. I think we still need some way to make an initial event for the secret generator controller, which involves knowing the namespace and the name of the generated secret, so I still wired the deployment through. We could use a namespace/name tuple here, but I was lazy. Signed-off-by: Andrew Keesler <akeesler@vmware.com> Co-authored-by: Ryan Richard <richardry@vmware.com>
2021-01-13 01:27:41 +00:00
Kind: "FederationDomain",
},
ObjectMeta: metav1.ObjectMeta{
OwnerReferences: []metav1.OwnerReference{
*metav1.NewControllerRef(pinnipedOwner, pinnipedOwnerWithNewGroupGVK),
// make sure we don't update the non-pinniped owner
*metav1.NewControllerRef(nonPinnipedOwner, nonPinnipedOwnerGVK),
},
},
}
internal/groupsuffix: mutate TokenCredentialRequest's Authenticator This is a partial revert of 288d9c999efe. For some reason it didn't occur to me that we could do it this way earlier. Whoops. This also contains a middleware update: mutation funcs can return an error now and short-circuit the rest of the request/response flow. The idea here is that if someone is configuring their kubeclient to use middleware, they are agreeing to a narrow-er client contract by doing so (e.g., their TokenCredentialRequest's must have an Spec.Authenticator.APIGroup set). I also updated some internal/groupsuffix tests to be more realistic. Signed-off-by: Andrew Keesler <akeesler@vmware.com>
2021-02-05 01:02:59 +00:00
tokenCredentialRequest := with(
&loginv1alpha1.TokenCredentialRequest{},
gvk(replaceGV(t, loginv1alpha1.SchemeGroupVersion, newSuffix).WithKind("TokenCredentialRequest")),
)
tokenCredentialRequestWithPinnipedAuthenticator := with(
tokenCredentialRequest,
authenticatorAPIGroup(authv1alpha1.SchemeGroupVersion.Group),
)
tokenCredentialRequestWithCustomAPIGroupAuthenticator := with(
tokenCredentialRequest,
authenticatorAPIGroup(replaceGV(t, authv1alpha1.SchemeGroupVersion, newSuffix).Group),
)
tokenCredentialRequestWithNewGroup := with(
tokenCredentialRequest,
gvk(replaceGV(t, loginv1alpha1.SchemeGroupVersion, newSuffix).WithKind("TokenCredentialRequest")),
)
tokenCredentialRequestWithNewGroupAndPinnipedAuthenticator := with(
tokenCredentialRequestWithNewGroup,
authenticatorAPIGroup(authv1alpha1.SchemeGroupVersion.Group),
)
tokenCredentialRequestWithNewGroupAndCustomAPIGroupAuthenticator := with(
tokenCredentialRequestWithNewGroup,
authenticatorAPIGroup(replaceGV(t, authv1alpha1.SchemeGroupVersion, newSuffix).Group),
)
Allow multiple Pinnipeds to work on same cluster Yes, this is a huge commit. The middleware allows you to customize the API groups of all of the *.pinniped.dev API groups. Some notes about other small things in this commit: - We removed the internal/client package in favor of pkg/conciergeclient. The two packages do basically the same thing. I don't think we use the former anymore. - We re-enabled cluster-scoped owner assertions in the integration tests. This code was added in internal/ownerref. See a0546942 for when this assertion was removed. - Note: the middlware code is in charge of restoring the GV of a request object, so we should never need to write mutations that do that. - We updated the supervisor secret generation to no longer manually set an owner reference to the deployment since the middleware code now does this. I think we still need some way to make an initial event for the secret generator controller, which involves knowing the namespace and the name of the generated secret, so I still wired the deployment through. We could use a namespace/name tuple here, but I was lazy. Signed-off-by: Andrew Keesler <akeesler@vmware.com> Co-authored-by: Ryan Richard <richardry@vmware.com>
2021-01-13 01:27:41 +00:00
tests := []struct {
internal/groupsuffix: mutate TokenCredentialRequest's Authenticator This is a partial revert of 288d9c999efe. For some reason it didn't occur to me that we could do it this way earlier. Whoops. This also contains a middleware update: mutation funcs can return an error now and short-circuit the rest of the request/response flow. The idea here is that if someone is configuring their kubeclient to use middleware, they are agreeing to a narrow-er client contract by doing so (e.g., their TokenCredentialRequest's must have an Spec.Authenticator.APIGroup set). I also updated some internal/groupsuffix tests to be more realistic. Signed-off-by: Andrew Keesler <akeesler@vmware.com>
2021-02-05 01:02:59 +00:00
name string
apiGroupSuffix string
rt *testutil.RoundTrip
requestObj, responseObj kubeclient.Object
wantNilMiddleware bool
wantMutateRequests, wantMutateResponses int
wantMutateRequestErrors, wantMutateResponseErrors []string
wantRequestObj, wantResponseObj kubeclient.Object
Allow multiple Pinnipeds to work on same cluster Yes, this is a huge commit. The middleware allows you to customize the API groups of all of the *.pinniped.dev API groups. Some notes about other small things in this commit: - We removed the internal/client package in favor of pkg/conciergeclient. The two packages do basically the same thing. I don't think we use the former anymore. - We re-enabled cluster-scoped owner assertions in the integration tests. This code was added in internal/ownerref. See a0546942 for when this assertion was removed. - Note: the middlware code is in charge of restoring the GV of a request object, so we should never need to write mutations that do that. - We updated the supervisor secret generation to no longer manually set an owner reference to the deployment since the middleware code now does this. I think we still need some way to make an initial event for the secret generator controller, which involves knowing the namespace and the name of the generated secret, so I still wired the deployment through. We could use a namespace/name tuple here, but I was lazy. Signed-off-by: Andrew Keesler <akeesler@vmware.com> Co-authored-by: Ryan Richard <richardry@vmware.com>
2021-01-13 01:27:41 +00:00
}{
{
name: "api group suffix is empty",
apiGroupSuffix: "",
rt: (&testutil.RoundTrip{}).
WithVerb(kubeclient.VerbGet).
WithNamespace("some-namespace").
WithResource(corev1.SchemeGroupVersion.WithResource("pods")),
wantNilMiddleware: true,
},
{
name: "api group suffix is default",
apiGroupSuffix: "pinniped.dev",
rt: (&testutil.RoundTrip{}).
WithVerb(kubeclient.VerbGet).
WithNamespace("some-namespace").
WithResource(corev1.SchemeGroupVersion.WithResource("pods")),
wantNilMiddleware: true,
},
{
name: "get resource without pinniped.dev",
apiGroupSuffix: newSuffix,
rt: (&testutil.RoundTrip{}).
WithVerb(kubeclient.VerbGet).
WithNamespace("some-namespace").
WithResource(corev1.SchemeGroupVersion.WithResource("pods")),
responseObj: podWithoutOwner,
wantMutateResponses: 1,
wantResponseObj: podWithoutOwner,
},
{
name: "get resource without pinniped.dev with non-pinniped.dev owner ref",
apiGroupSuffix: newSuffix,
rt: (&testutil.RoundTrip{}).
WithVerb(kubeclient.VerbGet).
WithNamespace("some-namespace").
WithResource(corev1.SchemeGroupVersion.WithResource("pods")),
responseObj: podWithNonPinnipedOwner,
wantMutateResponses: 1,
wantResponseObj: podWithNonPinnipedOwner,
},
{
name: "get resource without pinniped.dev with pinniped.dev owner ref",
apiGroupSuffix: newSuffix,
rt: (&testutil.RoundTrip{}).
WithVerb(kubeclient.VerbGet).
WithNamespace("some-namespace").
WithResource(corev1.SchemeGroupVersion.WithResource("pods")),
responseObj: podWithPinnipedOwnerWithNewGroup,
wantMutateResponses: 1,
wantResponseObj: podWithPinnipedOwner,
},
{
name: "get resource with pinniped.dev",
apiGroupSuffix: newSuffix,
rt: (&testutil.RoundTrip{}).
WithVerb(kubeclient.VerbGet).
WithResource(loginv1alpha1.SchemeGroupVersion.WithResource("tokencredentialrequests")),
internal/groupsuffix: mutate TokenCredentialRequest's Authenticator This is a partial revert of 288d9c999efe. For some reason it didn't occur to me that we could do it this way earlier. Whoops. This also contains a middleware update: mutation funcs can return an error now and short-circuit the rest of the request/response flow. The idea here is that if someone is configuring their kubeclient to use middleware, they are agreeing to a narrow-er client contract by doing so (e.g., their TokenCredentialRequest's must have an Spec.Authenticator.APIGroup set). I also updated some internal/groupsuffix tests to be more realistic. Signed-off-by: Andrew Keesler <akeesler@vmware.com>
2021-02-05 01:02:59 +00:00
requestObj: with(&metav1.PartialObjectMetadata{}, gvk(loginv1alpha1.SchemeGroupVersion.WithKind("TokenCredentialRequest"))),
responseObj: tokenCredentialRequestWithNewGroup,
Allow multiple Pinnipeds to work on same cluster Yes, this is a huge commit. The middleware allows you to customize the API groups of all of the *.pinniped.dev API groups. Some notes about other small things in this commit: - We removed the internal/client package in favor of pkg/conciergeclient. The two packages do basically the same thing. I don't think we use the former anymore. - We re-enabled cluster-scoped owner assertions in the integration tests. This code was added in internal/ownerref. See a0546942 for when this assertion was removed. - Note: the middlware code is in charge of restoring the GV of a request object, so we should never need to write mutations that do that. - We updated the supervisor secret generation to no longer manually set an owner reference to the deployment since the middleware code now does this. I think we still need some way to make an initial event for the secret generator controller, which involves knowing the namespace and the name of the generated secret, so I still wired the deployment through. We could use a namespace/name tuple here, but I was lazy. Signed-off-by: Andrew Keesler <akeesler@vmware.com> Co-authored-by: Ryan Richard <richardry@vmware.com>
2021-01-13 01:27:41 +00:00
wantMutateRequests: 1,
wantMutateResponses: 1,
internal/groupsuffix: mutate TokenCredentialRequest's Authenticator This is a partial revert of 288d9c999efe. For some reason it didn't occur to me that we could do it this way earlier. Whoops. This also contains a middleware update: mutation funcs can return an error now and short-circuit the rest of the request/response flow. The idea here is that if someone is configuring their kubeclient to use middleware, they are agreeing to a narrow-er client contract by doing so (e.g., their TokenCredentialRequest's must have an Spec.Authenticator.APIGroup set). I also updated some internal/groupsuffix tests to be more realistic. Signed-off-by: Andrew Keesler <akeesler@vmware.com>
2021-02-05 01:02:59 +00:00
wantRequestObj: with(&metav1.PartialObjectMetadata{}, gvk(replaceGV(t, loginv1alpha1.SchemeGroupVersion, newSuffix).WithKind("TokenCredentialRequest"))),
wantResponseObj: tokenCredentialRequestWithNewGroup, // the middleware will reset object GVK for us
Allow multiple Pinnipeds to work on same cluster Yes, this is a huge commit. The middleware allows you to customize the API groups of all of the *.pinniped.dev API groups. Some notes about other small things in this commit: - We removed the internal/client package in favor of pkg/conciergeclient. The two packages do basically the same thing. I don't think we use the former anymore. - We re-enabled cluster-scoped owner assertions in the integration tests. This code was added in internal/ownerref. See a0546942 for when this assertion was removed. - Note: the middlware code is in charge of restoring the GV of a request object, so we should never need to write mutations that do that. - We updated the supervisor secret generation to no longer manually set an owner reference to the deployment since the middleware code now does this. I think we still need some way to make an initial event for the secret generator controller, which involves knowing the namespace and the name of the generated secret, so I still wired the deployment through. We could use a namespace/name tuple here, but I was lazy. Signed-off-by: Andrew Keesler <akeesler@vmware.com> Co-authored-by: Ryan Richard <richardry@vmware.com>
2021-01-13 01:27:41 +00:00
},
{
name: "create resource without pinniped.dev and without owner ref",
apiGroupSuffix: newSuffix,
rt: (&testutil.RoundTrip{}).
WithVerb(kubeclient.VerbCreate).
WithNamespace("some-namespace").
WithResource(corev1.SchemeGroupVersion.WithResource("pods")),
requestObj: podWithoutOwner,
responseObj: podWithoutOwner,
wantMutateRequests: 1,
wantMutateResponses: 1,
wantRequestObj: podWithoutOwner,
wantResponseObj: podWithoutOwner,
},
{
name: "create resource without pinniped.dev and with owner ref that has no pinniped.dev owner",
apiGroupSuffix: newSuffix,
rt: (&testutil.RoundTrip{}).
WithVerb(kubeclient.VerbCreate).
WithNamespace("some-namespace").
WithResource(corev1.SchemeGroupVersion.WithResource("pods")),
requestObj: podWithNonPinnipedOwner,
responseObj: podWithNonPinnipedOwner,
wantMutateRequests: 1,
wantMutateResponses: 1,
wantRequestObj: podWithNonPinnipedOwner,
wantResponseObj: podWithNonPinnipedOwner,
},
{
name: "create resource without pinniped.dev and with owner ref that has pinniped.dev owner",
apiGroupSuffix: newSuffix,
rt: (&testutil.RoundTrip{}).
WithVerb(kubeclient.VerbCreate).
WithNamespace("some-namespace").
WithResource(corev1.SchemeGroupVersion.WithResource("pods")),
requestObj: podWithPinnipedOwner,
responseObj: podWithPinnipedOwnerWithNewGroup,
wantMutateRequests: 1,
wantMutateResponses: 1,
wantRequestObj: podWithPinnipedOwnerWithNewGroup,
wantResponseObj: podWithPinnipedOwner,
},
{
name: "create subresource without pinniped.dev",
apiGroupSuffix: newSuffix,
rt: (&testutil.RoundTrip{}).
WithVerb(kubeclient.VerbCreate).
WithNamespace("some-namespace").
WithResource(corev1.SchemeGroupVersion.WithResource("pods")).
WithSubresource("some-subresource"),
responseObj: podWithPinnipedOwner,
wantMutateResponses: 1,
wantResponseObj: podWithPinnipedOwner,
},
{
internal/groupsuffix: mutate TokenCredentialRequest's Authenticator This is a partial revert of 288d9c999efe. For some reason it didn't occur to me that we could do it this way earlier. Whoops. This also contains a middleware update: mutation funcs can return an error now and short-circuit the rest of the request/response flow. The idea here is that if someone is configuring their kubeclient to use middleware, they are agreeing to a narrow-er client contract by doing so (e.g., their TokenCredentialRequest's must have an Spec.Authenticator.APIGroup set). I also updated some internal/groupsuffix tests to be more realistic. Signed-off-by: Andrew Keesler <akeesler@vmware.com>
2021-02-05 01:02:59 +00:00
// test that multiple of our middleware request mutations play nicely with each other
Allow multiple Pinnipeds to work on same cluster Yes, this is a huge commit. The middleware allows you to customize the API groups of all of the *.pinniped.dev API groups. Some notes about other small things in this commit: - We removed the internal/client package in favor of pkg/conciergeclient. The two packages do basically the same thing. I don't think we use the former anymore. - We re-enabled cluster-scoped owner assertions in the integration tests. This code was added in internal/ownerref. See a0546942 for when this assertion was removed. - Note: the middlware code is in charge of restoring the GV of a request object, so we should never need to write mutations that do that. - We updated the supervisor secret generation to no longer manually set an owner reference to the deployment since the middleware code now does this. I think we still need some way to make an initial event for the secret generator controller, which involves knowing the namespace and the name of the generated secret, so I still wired the deployment through. We could use a namespace/name tuple here, but I was lazy. Signed-off-by: Andrew Keesler <akeesler@vmware.com> Co-authored-by: Ryan Richard <richardry@vmware.com>
2021-01-13 01:27:41 +00:00
name: "create resource with pinniped.dev and with owner ref that has pinniped.dev owner",
apiGroupSuffix: newSuffix,
rt: (&testutil.RoundTrip{}).
WithVerb(kubeclient.VerbCreate).
WithNamespace("some-namespace").
WithResource(configv1alpha1.SchemeGroupVersion.WithResource("federationdomains")),
requestObj: federationDomainWithPinnipedOwner,
internal/groupsuffix: mutate TokenCredentialRequest's Authenticator This is a partial revert of 288d9c999efe. For some reason it didn't occur to me that we could do it this way earlier. Whoops. This also contains a middleware update: mutation funcs can return an error now and short-circuit the rest of the request/response flow. The idea here is that if someone is configuring their kubeclient to use middleware, they are agreeing to a narrow-er client contract by doing so (e.g., their TokenCredentialRequest's must have an Spec.Authenticator.APIGroup set). I also updated some internal/groupsuffix tests to be more realistic. Signed-off-by: Andrew Keesler <akeesler@vmware.com>
2021-02-05 01:02:59 +00:00
responseObj: federationDomainWithNewGroupAndPinnipedOwnerWithNewGroup,
Allow multiple Pinnipeds to work on same cluster Yes, this is a huge commit. The middleware allows you to customize the API groups of all of the *.pinniped.dev API groups. Some notes about other small things in this commit: - We removed the internal/client package in favor of pkg/conciergeclient. The two packages do basically the same thing. I don't think we use the former anymore. - We re-enabled cluster-scoped owner assertions in the integration tests. This code was added in internal/ownerref. See a0546942 for when this assertion was removed. - Note: the middlware code is in charge of restoring the GV of a request object, so we should never need to write mutations that do that. - We updated the supervisor secret generation to no longer manually set an owner reference to the deployment since the middleware code now does this. I think we still need some way to make an initial event for the secret generator controller, which involves knowing the namespace and the name of the generated secret, so I still wired the deployment through. We could use a namespace/name tuple here, but I was lazy. Signed-off-by: Andrew Keesler <akeesler@vmware.com> Co-authored-by: Ryan Richard <richardry@vmware.com>
2021-01-13 01:27:41 +00:00
wantMutateRequests: 2,
wantMutateResponses: 1,
wantRequestObj: federationDomainWithNewGroupAndPinnipedOwnerWithNewGroup,
internal/groupsuffix: mutate TokenCredentialRequest's Authenticator This is a partial revert of 288d9c999efe. For some reason it didn't occur to me that we could do it this way earlier. Whoops. This also contains a middleware update: mutation funcs can return an error now and short-circuit the rest of the request/response flow. The idea here is that if someone is configuring their kubeclient to use middleware, they are agreeing to a narrow-er client contract by doing so (e.g., their TokenCredentialRequest's must have an Spec.Authenticator.APIGroup set). I also updated some internal/groupsuffix tests to be more realistic. Signed-off-by: Andrew Keesler <akeesler@vmware.com>
2021-02-05 01:02:59 +00:00
wantResponseObj: federationDomainWithNewGroupAndPinnipedOwner, // the middleware will reset object GVK for us
Allow multiple Pinnipeds to work on same cluster Yes, this is a huge commit. The middleware allows you to customize the API groups of all of the *.pinniped.dev API groups. Some notes about other small things in this commit: - We removed the internal/client package in favor of pkg/conciergeclient. The two packages do basically the same thing. I don't think we use the former anymore. - We re-enabled cluster-scoped owner assertions in the integration tests. This code was added in internal/ownerref. See a0546942 for when this assertion was removed. - Note: the middlware code is in charge of restoring the GV of a request object, so we should never need to write mutations that do that. - We updated the supervisor secret generation to no longer manually set an owner reference to the deployment since the middleware code now does this. I think we still need some way to make an initial event for the secret generator controller, which involves knowing the namespace and the name of the generated secret, so I still wired the deployment through. We could use a namespace/name tuple here, but I was lazy. Signed-off-by: Andrew Keesler <akeesler@vmware.com> Co-authored-by: Ryan Richard <richardry@vmware.com>
2021-01-13 01:27:41 +00:00
},
{
name: "update resource without pinniped.dev",
apiGroupSuffix: newSuffix,
rt: (&testutil.RoundTrip{}).
WithVerb(kubeclient.VerbUpdate).
WithNamespace("some-namespace").
WithResource(corev1.SchemeGroupVersion.WithResource("pods")),
responseObj: podWithoutOwner,
wantMutateResponses: 1,
wantResponseObj: podWithoutOwner,
},
{
name: "update resource with pinniped.dev",
apiGroupSuffix: newSuffix,
rt: (&testutil.RoundTrip{}).
WithVerb(kubeclient.VerbUpdate).
WithResource(loginv1alpha1.SchemeGroupVersion.WithResource("tokencredentialrequests")),
requestObj: tokenCredentialRequest,
internal/groupsuffix: mutate TokenCredentialRequest's Authenticator This is a partial revert of 288d9c999efe. For some reason it didn't occur to me that we could do it this way earlier. Whoops. This also contains a middleware update: mutation funcs can return an error now and short-circuit the rest of the request/response flow. The idea here is that if someone is configuring their kubeclient to use middleware, they are agreeing to a narrow-er client contract by doing so (e.g., their TokenCredentialRequest's must have an Spec.Authenticator.APIGroup set). I also updated some internal/groupsuffix tests to be more realistic. Signed-off-by: Andrew Keesler <akeesler@vmware.com>
2021-02-05 01:02:59 +00:00
responseObj: tokenCredentialRequestWithNewGroup,
Allow multiple Pinnipeds to work on same cluster Yes, this is a huge commit. The middleware allows you to customize the API groups of all of the *.pinniped.dev API groups. Some notes about other small things in this commit: - We removed the internal/client package in favor of pkg/conciergeclient. The two packages do basically the same thing. I don't think we use the former anymore. - We re-enabled cluster-scoped owner assertions in the integration tests. This code was added in internal/ownerref. See a0546942 for when this assertion was removed. - Note: the middlware code is in charge of restoring the GV of a request object, so we should never need to write mutations that do that. - We updated the supervisor secret generation to no longer manually set an owner reference to the deployment since the middleware code now does this. I think we still need some way to make an initial event for the secret generator controller, which involves knowing the namespace and the name of the generated secret, so I still wired the deployment through. We could use a namespace/name tuple here, but I was lazy. Signed-off-by: Andrew Keesler <akeesler@vmware.com> Co-authored-by: Ryan Richard <richardry@vmware.com>
2021-01-13 01:27:41 +00:00
wantMutateRequests: 1,
wantMutateResponses: 1,
wantRequestObj: tokenCredentialRequestWithNewGroup,
internal/groupsuffix: mutate TokenCredentialRequest's Authenticator This is a partial revert of 288d9c999efe. For some reason it didn't occur to me that we could do it this way earlier. Whoops. This also contains a middleware update: mutation funcs can return an error now and short-circuit the rest of the request/response flow. The idea here is that if someone is configuring their kubeclient to use middleware, they are agreeing to a narrow-er client contract by doing so (e.g., their TokenCredentialRequest's must have an Spec.Authenticator.APIGroup set). I also updated some internal/groupsuffix tests to be more realistic. Signed-off-by: Andrew Keesler <akeesler@vmware.com>
2021-02-05 01:02:59 +00:00
wantResponseObj: tokenCredentialRequestWithNewGroup, // the middleware will reset object GVK for us
Allow multiple Pinnipeds to work on same cluster Yes, this is a huge commit. The middleware allows you to customize the API groups of all of the *.pinniped.dev API groups. Some notes about other small things in this commit: - We removed the internal/client package in favor of pkg/conciergeclient. The two packages do basically the same thing. I don't think we use the former anymore. - We re-enabled cluster-scoped owner assertions in the integration tests. This code was added in internal/ownerref. See a0546942 for when this assertion was removed. - Note: the middlware code is in charge of restoring the GV of a request object, so we should never need to write mutations that do that. - We updated the supervisor secret generation to no longer manually set an owner reference to the deployment since the middleware code now does this. I think we still need some way to make an initial event for the secret generator controller, which involves knowing the namespace and the name of the generated secret, so I still wired the deployment through. We could use a namespace/name tuple here, but I was lazy. Signed-off-by: Andrew Keesler <akeesler@vmware.com> Co-authored-by: Ryan Richard <richardry@vmware.com>
2021-01-13 01:27:41 +00:00
},
{
name: "list resource without pinniped.dev",
apiGroupSuffix: newSuffix,
rt: (&testutil.RoundTrip{}).
WithVerb(kubeclient.VerbList).
WithNamespace("some-namespace").
WithResource(corev1.SchemeGroupVersion.WithResource("pods")),
responseObj: podWithoutOwner,
wantMutateResponses: 1,
wantResponseObj: podWithoutOwner,
},
{
name: "list resource with pinniped.dev",
apiGroupSuffix: newSuffix,
rt: (&testutil.RoundTrip{}).
WithVerb(kubeclient.VerbList).
WithResource(loginv1alpha1.SchemeGroupVersion.WithResource("tokencredentialrequests")),
requestObj: tokenCredentialRequest,
internal/groupsuffix: mutate TokenCredentialRequest's Authenticator This is a partial revert of 288d9c999efe. For some reason it didn't occur to me that we could do it this way earlier. Whoops. This also contains a middleware update: mutation funcs can return an error now and short-circuit the rest of the request/response flow. The idea here is that if someone is configuring their kubeclient to use middleware, they are agreeing to a narrow-er client contract by doing so (e.g., their TokenCredentialRequest's must have an Spec.Authenticator.APIGroup set). I also updated some internal/groupsuffix tests to be more realistic. Signed-off-by: Andrew Keesler <akeesler@vmware.com>
2021-02-05 01:02:59 +00:00
responseObj: tokenCredentialRequestWithNewGroup,
Allow multiple Pinnipeds to work on same cluster Yes, this is a huge commit. The middleware allows you to customize the API groups of all of the *.pinniped.dev API groups. Some notes about other small things in this commit: - We removed the internal/client package in favor of pkg/conciergeclient. The two packages do basically the same thing. I don't think we use the former anymore. - We re-enabled cluster-scoped owner assertions in the integration tests. This code was added in internal/ownerref. See a0546942 for when this assertion was removed. - Note: the middlware code is in charge of restoring the GV of a request object, so we should never need to write mutations that do that. - We updated the supervisor secret generation to no longer manually set an owner reference to the deployment since the middleware code now does this. I think we still need some way to make an initial event for the secret generator controller, which involves knowing the namespace and the name of the generated secret, so I still wired the deployment through. We could use a namespace/name tuple here, but I was lazy. Signed-off-by: Andrew Keesler <akeesler@vmware.com> Co-authored-by: Ryan Richard <richardry@vmware.com>
2021-01-13 01:27:41 +00:00
wantMutateRequests: 1,
wantMutateResponses: 1,
wantRequestObj: tokenCredentialRequestWithNewGroup,
internal/groupsuffix: mutate TokenCredentialRequest's Authenticator This is a partial revert of 288d9c999efe. For some reason it didn't occur to me that we could do it this way earlier. Whoops. This also contains a middleware update: mutation funcs can return an error now and short-circuit the rest of the request/response flow. The idea here is that if someone is configuring their kubeclient to use middleware, they are agreeing to a narrow-er client contract by doing so (e.g., their TokenCredentialRequest's must have an Spec.Authenticator.APIGroup set). I also updated some internal/groupsuffix tests to be more realistic. Signed-off-by: Andrew Keesler <akeesler@vmware.com>
2021-02-05 01:02:59 +00:00
wantResponseObj: tokenCredentialRequestWithNewGroup, // the middleware will reset object GVK for us
Allow multiple Pinnipeds to work on same cluster Yes, this is a huge commit. The middleware allows you to customize the API groups of all of the *.pinniped.dev API groups. Some notes about other small things in this commit: - We removed the internal/client package in favor of pkg/conciergeclient. The two packages do basically the same thing. I don't think we use the former anymore. - We re-enabled cluster-scoped owner assertions in the integration tests. This code was added in internal/ownerref. See a0546942 for when this assertion was removed. - Note: the middlware code is in charge of restoring the GV of a request object, so we should never need to write mutations that do that. - We updated the supervisor secret generation to no longer manually set an owner reference to the deployment since the middleware code now does this. I think we still need some way to make an initial event for the secret generator controller, which involves knowing the namespace and the name of the generated secret, so I still wired the deployment through. We could use a namespace/name tuple here, but I was lazy. Signed-off-by: Andrew Keesler <akeesler@vmware.com> Co-authored-by: Ryan Richard <richardry@vmware.com>
2021-01-13 01:27:41 +00:00
},
{
name: "watch resource without pinniped.dev",
apiGroupSuffix: newSuffix,
rt: (&testutil.RoundTrip{}).
WithVerb(kubeclient.VerbWatch).
WithNamespace("some-namespace").
WithResource(corev1.SchemeGroupVersion.WithResource("pods")),
responseObj: podWithoutOwner,
wantMutateResponses: 1,
wantResponseObj: podWithoutOwner,
},
{
name: "watch resource with pinniped.dev",
apiGroupSuffix: newSuffix,
rt: (&testutil.RoundTrip{}).
WithVerb(kubeclient.VerbList).
WithResource(loginv1alpha1.SchemeGroupVersion.WithResource("tokencredentialrequests")),
requestObj: tokenCredentialRequest,
internal/groupsuffix: mutate TokenCredentialRequest's Authenticator This is a partial revert of 288d9c999efe. For some reason it didn't occur to me that we could do it this way earlier. Whoops. This also contains a middleware update: mutation funcs can return an error now and short-circuit the rest of the request/response flow. The idea here is that if someone is configuring their kubeclient to use middleware, they are agreeing to a narrow-er client contract by doing so (e.g., their TokenCredentialRequest's must have an Spec.Authenticator.APIGroup set). I also updated some internal/groupsuffix tests to be more realistic. Signed-off-by: Andrew Keesler <akeesler@vmware.com>
2021-02-05 01:02:59 +00:00
responseObj: tokenCredentialRequestWithNewGroup,
Allow multiple Pinnipeds to work on same cluster Yes, this is a huge commit. The middleware allows you to customize the API groups of all of the *.pinniped.dev API groups. Some notes about other small things in this commit: - We removed the internal/client package in favor of pkg/conciergeclient. The two packages do basically the same thing. I don't think we use the former anymore. - We re-enabled cluster-scoped owner assertions in the integration tests. This code was added in internal/ownerref. See a0546942 for when this assertion was removed. - Note: the middlware code is in charge of restoring the GV of a request object, so we should never need to write mutations that do that. - We updated the supervisor secret generation to no longer manually set an owner reference to the deployment since the middleware code now does this. I think we still need some way to make an initial event for the secret generator controller, which involves knowing the namespace and the name of the generated secret, so I still wired the deployment through. We could use a namespace/name tuple here, but I was lazy. Signed-off-by: Andrew Keesler <akeesler@vmware.com> Co-authored-by: Ryan Richard <richardry@vmware.com>
2021-01-13 01:27:41 +00:00
wantMutateRequests: 1,
wantMutateResponses: 1,
wantRequestObj: tokenCredentialRequestWithNewGroup,
internal/groupsuffix: mutate TokenCredentialRequest's Authenticator This is a partial revert of 288d9c999efe. For some reason it didn't occur to me that we could do it this way earlier. Whoops. This also contains a middleware update: mutation funcs can return an error now and short-circuit the rest of the request/response flow. The idea here is that if someone is configuring their kubeclient to use middleware, they are agreeing to a narrow-er client contract by doing so (e.g., their TokenCredentialRequest's must have an Spec.Authenticator.APIGroup set). I also updated some internal/groupsuffix tests to be more realistic. Signed-off-by: Andrew Keesler <akeesler@vmware.com>
2021-02-05 01:02:59 +00:00
wantResponseObj: tokenCredentialRequestWithNewGroup, // the middleware will reset object GVK for us
Allow multiple Pinnipeds to work on same cluster Yes, this is a huge commit. The middleware allows you to customize the API groups of all of the *.pinniped.dev API groups. Some notes about other small things in this commit: - We removed the internal/client package in favor of pkg/conciergeclient. The two packages do basically the same thing. I don't think we use the former anymore. - We re-enabled cluster-scoped owner assertions in the integration tests. This code was added in internal/ownerref. See a0546942 for when this assertion was removed. - Note: the middlware code is in charge of restoring the GV of a request object, so we should never need to write mutations that do that. - We updated the supervisor secret generation to no longer manually set an owner reference to the deployment since the middleware code now does this. I think we still need some way to make an initial event for the secret generator controller, which involves knowing the namespace and the name of the generated secret, so I still wired the deployment through. We could use a namespace/name tuple here, but I was lazy. Signed-off-by: Andrew Keesler <akeesler@vmware.com> Co-authored-by: Ryan Richard <richardry@vmware.com>
2021-01-13 01:27:41 +00:00
},
{
name: "patch resource without pinniped.dev",
apiGroupSuffix: newSuffix,
rt: (&testutil.RoundTrip{}).
WithVerb(kubeclient.VerbPatch).
WithNamespace("some-namespace").
WithResource(corev1.SchemeGroupVersion.WithResource("pods")),
responseObj: podWithoutOwner,
wantMutateResponses: 1,
wantResponseObj: podWithoutOwner,
},
{
name: "patch resource with pinniped.dev",
apiGroupSuffix: newSuffix,
rt: (&testutil.RoundTrip{}).
internal/groupsuffix: mutate TokenCredentialRequest's Authenticator This is a partial revert of 288d9c999efe. For some reason it didn't occur to me that we could do it this way earlier. Whoops. This also contains a middleware update: mutation funcs can return an error now and short-circuit the rest of the request/response flow. The idea here is that if someone is configuring their kubeclient to use middleware, they are agreeing to a narrow-er client contract by doing so (e.g., their TokenCredentialRequest's must have an Spec.Authenticator.APIGroup set). I also updated some internal/groupsuffix tests to be more realistic. Signed-off-by: Andrew Keesler <akeesler@vmware.com>
2021-02-05 01:02:59 +00:00
WithVerb(kubeclient.VerbPatch).
Allow multiple Pinnipeds to work on same cluster Yes, this is a huge commit. The middleware allows you to customize the API groups of all of the *.pinniped.dev API groups. Some notes about other small things in this commit: - We removed the internal/client package in favor of pkg/conciergeclient. The two packages do basically the same thing. I don't think we use the former anymore. - We re-enabled cluster-scoped owner assertions in the integration tests. This code was added in internal/ownerref. See a0546942 for when this assertion was removed. - Note: the middlware code is in charge of restoring the GV of a request object, so we should never need to write mutations that do that. - We updated the supervisor secret generation to no longer manually set an owner reference to the deployment since the middleware code now does this. I think we still need some way to make an initial event for the secret generator controller, which involves knowing the namespace and the name of the generated secret, so I still wired the deployment through. We could use a namespace/name tuple here, but I was lazy. Signed-off-by: Andrew Keesler <akeesler@vmware.com> Co-authored-by: Ryan Richard <richardry@vmware.com>
2021-01-13 01:27:41 +00:00
WithResource(loginv1alpha1.SchemeGroupVersion.WithResource("tokencredentialrequests")),
requestObj: tokenCredentialRequest,
internal/groupsuffix: mutate TokenCredentialRequest's Authenticator This is a partial revert of 288d9c999efe. For some reason it didn't occur to me that we could do it this way earlier. Whoops. This also contains a middleware update: mutation funcs can return an error now and short-circuit the rest of the request/response flow. The idea here is that if someone is configuring their kubeclient to use middleware, they are agreeing to a narrow-er client contract by doing so (e.g., their TokenCredentialRequest's must have an Spec.Authenticator.APIGroup set). I also updated some internal/groupsuffix tests to be more realistic. Signed-off-by: Andrew Keesler <akeesler@vmware.com>
2021-02-05 01:02:59 +00:00
responseObj: tokenCredentialRequestWithNewGroup,
Allow multiple Pinnipeds to work on same cluster Yes, this is a huge commit. The middleware allows you to customize the API groups of all of the *.pinniped.dev API groups. Some notes about other small things in this commit: - We removed the internal/client package in favor of pkg/conciergeclient. The two packages do basically the same thing. I don't think we use the former anymore. - We re-enabled cluster-scoped owner assertions in the integration tests. This code was added in internal/ownerref. See a0546942 for when this assertion was removed. - Note: the middlware code is in charge of restoring the GV of a request object, so we should never need to write mutations that do that. - We updated the supervisor secret generation to no longer manually set an owner reference to the deployment since the middleware code now does this. I think we still need some way to make an initial event for the secret generator controller, which involves knowing the namespace and the name of the generated secret, so I still wired the deployment through. We could use a namespace/name tuple here, but I was lazy. Signed-off-by: Andrew Keesler <akeesler@vmware.com> Co-authored-by: Ryan Richard <richardry@vmware.com>
2021-01-13 01:27:41 +00:00
wantMutateRequests: 1,
wantMutateResponses: 1,
wantRequestObj: tokenCredentialRequestWithNewGroup,
internal/groupsuffix: mutate TokenCredentialRequest's Authenticator This is a partial revert of 288d9c999efe. For some reason it didn't occur to me that we could do it this way earlier. Whoops. This also contains a middleware update: mutation funcs can return an error now and short-circuit the rest of the request/response flow. The idea here is that if someone is configuring their kubeclient to use middleware, they are agreeing to a narrow-er client contract by doing so (e.g., their TokenCredentialRequest's must have an Spec.Authenticator.APIGroup set). I also updated some internal/groupsuffix tests to be more realistic. Signed-off-by: Andrew Keesler <akeesler@vmware.com>
2021-02-05 01:02:59 +00:00
wantResponseObj: tokenCredentialRequestWithNewGroup, // the middleware will reset object GVK for us
},
{
name: "create tokencredentialrequest with pinniped.dev authenticator api group",
apiGroupSuffix: newSuffix,
rt: (&testutil.RoundTrip{}).
WithVerb(kubeclient.VerbCreate).
WithResource(loginv1alpha1.SchemeGroupVersion.WithResource("tokencredentialrequests")),
requestObj: tokenCredentialRequestWithPinnipedAuthenticator,
responseObj: tokenCredentialRequestWithNewGroup, // a token credential response does not contain a spec
wantMutateRequests: 3,
wantMutateResponses: 1,
wantRequestObj: tokenCredentialRequestWithNewGroupAndCustomAPIGroupAuthenticator,
wantResponseObj: tokenCredentialRequestWithNewGroup, // the middleware will reset object GVK for us
},
{
name: "create tokencredentialrequest with custom authenticator api group fails because api group is expected to be pinniped.dev",
apiGroupSuffix: newSuffix,
rt: (&testutil.RoundTrip{}).
WithVerb(kubeclient.VerbCreate).
WithResource(loginv1alpha1.SchemeGroupVersion.WithResource("tokencredentialrequests")),
requestObj: tokenCredentialRequestWithCustomAPIGroupAuthenticator,
responseObj: tokenCredentialRequestWithNewGroup, // a token credential response does not contain a spec
wantMutateRequests: 3,
wantMutateResponses: 1,
Switch to go.uber.org/zap for JSON formatted logging Signed-off-by: Monis Khan <mok@vmware.com>
2022-04-16 02:43:53 +00:00
wantMutateRequestErrors: []string{`cannot replace token credential request / authenticator API group "authentication.concierge.some.suffix.com" with group suffix "some.suffix.com"`},
internal/groupsuffix: mutate TokenCredentialRequest's Authenticator This is a partial revert of 288d9c999efe. For some reason it didn't occur to me that we could do it this way earlier. Whoops. This also contains a middleware update: mutation funcs can return an error now and short-circuit the rest of the request/response flow. The idea here is that if someone is configuring their kubeclient to use middleware, they are agreeing to a narrow-er client contract by doing so (e.g., their TokenCredentialRequest's must have an Spec.Authenticator.APIGroup set). I also updated some internal/groupsuffix tests to be more realistic. Signed-off-by: Andrew Keesler <akeesler@vmware.com>
2021-02-05 01:02:59 +00:00
wantResponseObj: tokenCredentialRequestWithNewGroup, // the middleware will reset object GVK for us
},
{
name: "create tokencredentialrequest with pinniped.dev authenticator api group and subresource",
apiGroupSuffix: newSuffix,
rt: (&testutil.RoundTrip{}).
WithVerb(kubeclient.VerbCreate).
WithResource(loginv1alpha1.SchemeGroupVersion.WithResource("tokencredentialrequests")).
WithSubresource("some-subresource"),
requestObj: tokenCredentialRequestWithPinnipedAuthenticator,
responseObj: tokenCredentialRequestWithNewGroup, // a token credential response does not contain a spec
wantMutateRequests: 1,
wantMutateResponses: 1,
wantRequestObj: tokenCredentialRequestWithNewGroupAndPinnipedAuthenticator,
wantResponseObj: tokenCredentialRequestWithNewGroup, // the middleware will reset object GVK for us
},
{
name: "non-create tokencredentialrequest with pinniped.dev authenticator api group",
apiGroupSuffix: newSuffix,
rt: (&testutil.RoundTrip{}).
WithVerb(kubeclient.VerbList).
WithResource(loginv1alpha1.SchemeGroupVersion.WithResource("tokencredentialrequests")),
requestObj: tokenCredentialRequestWithPinnipedAuthenticator,
responseObj: tokenCredentialRequestWithNewGroup, // a token credential response does not contain a spec
wantMutateRequests: 1,
wantMutateResponses: 1,
wantRequestObj: tokenCredentialRequestWithNewGroupAndPinnipedAuthenticator,
wantResponseObj: tokenCredentialRequestWithNewGroup, // the middleware will reset object GVK for us
},
{
name: "create tokencredentialrequest with nil authenticator api group",
apiGroupSuffix: newSuffix,
rt: (&testutil.RoundTrip{}).
WithVerb(kubeclient.VerbCreate).
WithResource(loginv1alpha1.SchemeGroupVersion.WithResource("tokencredentialrequests")),
requestObj: tokenCredentialRequest,
responseObj: tokenCredentialRequestWithNewGroup, // a token credential response does not contain a spec
wantMutateRequests: 3,
wantMutateResponses: 1,
Switch to go.uber.org/zap for JSON formatted logging Signed-off-by: Monis Khan <mok@vmware.com>
2022-04-16 02:43:53 +00:00
wantMutateRequestErrors: []string{`cannot replace token credential request / without authenticator API group`},
internal/groupsuffix: mutate TokenCredentialRequest's Authenticator This is a partial revert of 288d9c999efe. For some reason it didn't occur to me that we could do it this way earlier. Whoops. This also contains a middleware update: mutation funcs can return an error now and short-circuit the rest of the request/response flow. The idea here is that if someone is configuring their kubeclient to use middleware, they are agreeing to a narrow-er client contract by doing so (e.g., their TokenCredentialRequest's must have an Spec.Authenticator.APIGroup set). I also updated some internal/groupsuffix tests to be more realistic. Signed-off-by: Andrew Keesler <akeesler@vmware.com>
2021-02-05 01:02:59 +00:00
wantResponseObj: tokenCredentialRequestWithNewGroup, // the middleware will reset object GVK for us
},
{
name: "create tokencredentialrequest with non-*loginv1alpha1.TokenCredentialRequest",
apiGroupSuffix: newSuffix,
rt: (&testutil.RoundTrip{}).
WithVerb(kubeclient.VerbCreate).
WithResource(loginv1alpha1.SchemeGroupVersion.WithResource("tokencredentialrequests")),
requestObj: podWithoutOwner,
responseObj: podWithoutOwner,
wantMutateRequests: 3,
wantMutateResponses: 1,
wantMutateRequestErrors: []string{`cannot cast obj of type *v1.Pod to *loginv1alpha1.TokenCredentialRequest`},
wantResponseObj: podWithoutOwner,
Allow multiple Pinnipeds to work on same cluster Yes, this is a huge commit. The middleware allows you to customize the API groups of all of the *.pinniped.dev API groups. Some notes about other small things in this commit: - We removed the internal/client package in favor of pkg/conciergeclient. The two packages do basically the same thing. I don't think we use the former anymore. - We re-enabled cluster-scoped owner assertions in the integration tests. This code was added in internal/ownerref. See a0546942 for when this assertion was removed. - Note: the middlware code is in charge of restoring the GV of a request object, so we should never need to write mutations that do that. - We updated the supervisor secret generation to no longer manually set an owner reference to the deployment since the middleware code now does this. I think we still need some way to make an initial event for the secret generator controller, which involves knowing the namespace and the name of the generated secret, so I still wired the deployment through. We could use a namespace/name tuple here, but I was lazy. Signed-off-by: Andrew Keesler <akeesler@vmware.com> Co-authored-by: Ryan Richard <richardry@vmware.com>
2021-01-13 01:27:41 +00:00
},
}
for _, test := range tests {
test := test
t.Run(test.name, func(t *testing.T) {
m := New(test.apiGroupSuffix)
if test.wantNilMiddleware {
require.Nil(t, m, "wanted nil middleware")
return
}
m.Handle(context.Background(), test.rt)
internal/groupsuffix: mutate TokenCredentialRequest's Authenticator This is a partial revert of 288d9c999efe. For some reason it didn't occur to me that we could do it this way earlier. Whoops. This also contains a middleware update: mutation funcs can return an error now and short-circuit the rest of the request/response flow. The idea here is that if someone is configuring their kubeclient to use middleware, they are agreeing to a narrow-er client contract by doing so (e.g., their TokenCredentialRequest's must have an Spec.Authenticator.APIGroup set). I also updated some internal/groupsuffix tests to be more realistic. Signed-off-by: Andrew Keesler <akeesler@vmware.com>
2021-02-05 01:02:59 +00:00
require.Len(t, test.rt.MutateRequests, test.wantMutateRequests, "undesired request mutation count")
require.Len(t, test.rt.MutateResponses, test.wantMutateResponses, "undesired response mutation count")
Allow multiple Pinnipeds to work on same cluster Yes, this is a huge commit. The middleware allows you to customize the API groups of all of the *.pinniped.dev API groups. Some notes about other small things in this commit: - We removed the internal/client package in favor of pkg/conciergeclient. The two packages do basically the same thing. I don't think we use the former anymore. - We re-enabled cluster-scoped owner assertions in the integration tests. This code was added in internal/ownerref. See a0546942 for when this assertion was removed. - Note: the middlware code is in charge of restoring the GV of a request object, so we should never need to write mutations that do that. - We updated the supervisor secret generation to no longer manually set an owner reference to the deployment since the middleware code now does this. I think we still need some way to make an initial event for the secret generator controller, which involves knowing the namespace and the name of the generated secret, so I still wired the deployment through. We could use a namespace/name tuple here, but I was lazy. Signed-off-by: Andrew Keesler <akeesler@vmware.com> Co-authored-by: Ryan Richard <richardry@vmware.com>
2021-01-13 01:27:41 +00:00
if test.wantMutateRequests != 0 {
require.NotNil(t, test.requestObj, "expected test.requestObj to be set")
objMutated := test.requestObj.DeepCopyObject().(kubeclient.Object)
internal/groupsuffix: mutate TokenCredentialRequest's Authenticator This is a partial revert of 288d9c999efe. For some reason it didn't occur to me that we could do it this way earlier. Whoops. This also contains a middleware update: mutation funcs can return an error now and short-circuit the rest of the request/response flow. The idea here is that if someone is configuring their kubeclient to use middleware, they are agreeing to a narrow-er client contract by doing so (e.g., their TokenCredentialRequest's must have an Spec.Authenticator.APIGroup set). I also updated some internal/groupsuffix tests to be more realistic. Signed-off-by: Andrew Keesler <akeesler@vmware.com>
2021-02-05 01:02:59 +00:00
var mutateRequestErrors []string
Allow multiple Pinnipeds to work on same cluster Yes, this is a huge commit. The middleware allows you to customize the API groups of all of the *.pinniped.dev API groups. Some notes about other small things in this commit: - We removed the internal/client package in favor of pkg/conciergeclient. The two packages do basically the same thing. I don't think we use the former anymore. - We re-enabled cluster-scoped owner assertions in the integration tests. This code was added in internal/ownerref. See a0546942 for when this assertion was removed. - Note: the middlware code is in charge of restoring the GV of a request object, so we should never need to write mutations that do that. - We updated the supervisor secret generation to no longer manually set an owner reference to the deployment since the middleware code now does this. I think we still need some way to make an initial event for the secret generator controller, which involves knowing the namespace and the name of the generated secret, so I still wired the deployment through. We could use a namespace/name tuple here, but I was lazy. Signed-off-by: Andrew Keesler <akeesler@vmware.com> Co-authored-by: Ryan Richard <richardry@vmware.com>
2021-01-13 01:27:41 +00:00
for _, mutateRequest := range test.rt.MutateRequests {
mutateRequest := mutateRequest
internal/groupsuffix: mutate TokenCredentialRequest's Authenticator This is a partial revert of 288d9c999efe. For some reason it didn't occur to me that we could do it this way earlier. Whoops. This also contains a middleware update: mutation funcs can return an error now and short-circuit the rest of the request/response flow. The idea here is that if someone is configuring their kubeclient to use middleware, they are agreeing to a narrow-er client contract by doing so (e.g., their TokenCredentialRequest's must have an Spec.Authenticator.APIGroup set). I also updated some internal/groupsuffix tests to be more realistic. Signed-off-by: Andrew Keesler <akeesler@vmware.com>
2021-02-05 01:02:59 +00:00
if err := mutateRequest(objMutated); err != nil {
mutateRequestErrors = append(mutateRequestErrors, err.Error())
}
}
if len(test.wantMutateRequestErrors) > 0 {
require.Equal(t, test.wantMutateRequestErrors, mutateRequestErrors, "mutate request errors did not match")
} else {
require.Equal(t, test.wantRequestObj, objMutated, "request obj did not match")
Allow multiple Pinnipeds to work on same cluster Yes, this is a huge commit. The middleware allows you to customize the API groups of all of the *.pinniped.dev API groups. Some notes about other small things in this commit: - We removed the internal/client package in favor of pkg/conciergeclient. The two packages do basically the same thing. I don't think we use the former anymore. - We re-enabled cluster-scoped owner assertions in the integration tests. This code was added in internal/ownerref. See a0546942 for when this assertion was removed. - Note: the middlware code is in charge of restoring the GV of a request object, so we should never need to write mutations that do that. - We updated the supervisor secret generation to no longer manually set an owner reference to the deployment since the middleware code now does this. I think we still need some way to make an initial event for the secret generator controller, which involves knowing the namespace and the name of the generated secret, so I still wired the deployment through. We could use a namespace/name tuple here, but I was lazy. Signed-off-by: Andrew Keesler <akeesler@vmware.com> Co-authored-by: Ryan Richard <richardry@vmware.com>
2021-01-13 01:27:41 +00:00
}
}
if test.wantMutateResponses != 0 {
require.NotNil(t, test.responseObj, "expected test.responseObj to be set")
objMutated := test.responseObj.DeepCopyObject().(kubeclient.Object)
internal/groupsuffix: mutate TokenCredentialRequest's Authenticator This is a partial revert of 288d9c999efe. For some reason it didn't occur to me that we could do it this way earlier. Whoops. This also contains a middleware update: mutation funcs can return an error now and short-circuit the rest of the request/response flow. The idea here is that if someone is configuring their kubeclient to use middleware, they are agreeing to a narrow-er client contract by doing so (e.g., their TokenCredentialRequest's must have an Spec.Authenticator.APIGroup set). I also updated some internal/groupsuffix tests to be more realistic. Signed-off-by: Andrew Keesler <akeesler@vmware.com>
2021-02-05 01:02:59 +00:00
var mutateResponseErrors []string
Allow multiple Pinnipeds to work on same cluster Yes, this is a huge commit. The middleware allows you to customize the API groups of all of the *.pinniped.dev API groups. Some notes about other small things in this commit: - We removed the internal/client package in favor of pkg/conciergeclient. The two packages do basically the same thing. I don't think we use the former anymore. - We re-enabled cluster-scoped owner assertions in the integration tests. This code was added in internal/ownerref. See a0546942 for when this assertion was removed. - Note: the middlware code is in charge of restoring the GV of a request object, so we should never need to write mutations that do that. - We updated the supervisor secret generation to no longer manually set an owner reference to the deployment since the middleware code now does this. I think we still need some way to make an initial event for the secret generator controller, which involves knowing the namespace and the name of the generated secret, so I still wired the deployment through. We could use a namespace/name tuple here, but I was lazy. Signed-off-by: Andrew Keesler <akeesler@vmware.com> Co-authored-by: Ryan Richard <richardry@vmware.com>
2021-01-13 01:27:41 +00:00
for _, mutateResponse := range test.rt.MutateResponses {
mutateResponse := mutateResponse
internal/groupsuffix: mutate TokenCredentialRequest's Authenticator This is a partial revert of 288d9c999efe. For some reason it didn't occur to me that we could do it this way earlier. Whoops. This also contains a middleware update: mutation funcs can return an error now and short-circuit the rest of the request/response flow. The idea here is that if someone is configuring their kubeclient to use middleware, they are agreeing to a narrow-er client contract by doing so (e.g., their TokenCredentialRequest's must have an Spec.Authenticator.APIGroup set). I also updated some internal/groupsuffix tests to be more realistic. Signed-off-by: Andrew Keesler <akeesler@vmware.com>
2021-02-05 01:02:59 +00:00
if err := mutateResponse(objMutated); err != nil {
mutateResponseErrors = append(mutateResponseErrors, err.Error())
}
}
if len(test.wantMutateRequestErrors) > 0 {
require.Equal(t, test.wantMutateResponseErrors, mutateResponseErrors, "mutate response errors did not match")
} else {
require.Equal(t, test.wantResponseObj, objMutated, "response obj did not match")
Allow multiple Pinnipeds to work on same cluster Yes, this is a huge commit. The middleware allows you to customize the API groups of all of the *.pinniped.dev API groups. Some notes about other small things in this commit: - We removed the internal/client package in favor of pkg/conciergeclient. The two packages do basically the same thing. I don't think we use the former anymore. - We re-enabled cluster-scoped owner assertions in the integration tests. This code was added in internal/ownerref. See a0546942 for when this assertion was removed. - Note: the middlware code is in charge of restoring the GV of a request object, so we should never need to write mutations that do that. - We updated the supervisor secret generation to no longer manually set an owner reference to the deployment since the middleware code now does this. I think we still need some way to make an initial event for the secret generator controller, which involves knowing the namespace and the name of the generated secret, so I still wired the deployment through. We could use a namespace/name tuple here, but I was lazy. Signed-off-by: Andrew Keesler <akeesler@vmware.com> Co-authored-by: Ryan Richard <richardry@vmware.com>
2021-01-13 01:27:41 +00:00
}
}
})
}
}
func TestReplaceError(t *testing.T) {
Use custom suffix in `Spec.Authenticator.APIGroup` of `TokenCredentialRequest` When the Pinniped server has been installed with the `api_group_suffix` option, for example using `mysuffix.com`, then clients who would like to submit a `TokenCredentialRequest` to the server should set the `Spec.Authenticator.APIGroup` field as `authentication.concierge.mysuffix.com`. This makes more sense from the client's point of view than using the default `authentication.concierge.pinniped.dev` because `authentication.concierge.mysuffix.com` is the name of the API group that they can observe their cluster and `authentication.concierge.pinniped.dev` does not exist as an API group on their cluster. This commit includes both the client and server-side changes to make this work, as well as integration test updates. Co-authored-by: Andrew Keesler <akeesler@vmware.com> Co-authored-by: Ryan Richard <richardry@vmware.com> Co-authored-by: Margo Crawford <margaretc@vmware.com>
2021-02-03 23:49:15 +00:00
s, ok := Replace("bad-suffix-that-doesnt-end-in-pinniped-dot-dev", "shouldnt-matter.com")
require.Equal(t, "", s)
Allow multiple Pinnipeds to work on same cluster Yes, this is a huge commit. The middleware allows you to customize the API groups of all of the *.pinniped.dev API groups. Some notes about other small things in this commit: - We removed the internal/client package in favor of pkg/conciergeclient. The two packages do basically the same thing. I don't think we use the former anymore. - We re-enabled cluster-scoped owner assertions in the integration tests. This code was added in internal/ownerref. See a0546942 for when this assertion was removed. - Note: the middlware code is in charge of restoring the GV of a request object, so we should never need to write mutations that do that. - We updated the supervisor secret generation to no longer manually set an owner reference to the deployment since the middleware code now does this. I think we still need some way to make an initial event for the secret generator controller, which involves knowing the namespace and the name of the generated secret, so I still wired the deployment through. We could use a namespace/name tuple here, but I was lazy. Signed-off-by: Andrew Keesler <akeesler@vmware.com> Co-authored-by: Ryan Richard <richardry@vmware.com>
2021-01-13 01:27:41 +00:00
require.False(t, ok)
Use custom suffix in `Spec.Authenticator.APIGroup` of `TokenCredentialRequest` When the Pinniped server has been installed with the `api_group_suffix` option, for example using `mysuffix.com`, then clients who would like to submit a `TokenCredentialRequest` to the server should set the `Spec.Authenticator.APIGroup` field as `authentication.concierge.mysuffix.com`. This makes more sense from the client's point of view than using the default `authentication.concierge.pinniped.dev` because `authentication.concierge.mysuffix.com` is the name of the API group that they can observe their cluster and `authentication.concierge.pinniped.dev` does not exist as an API group on their cluster. This commit includes both the client and server-side changes to make this work, as well as integration test updates. Co-authored-by: Andrew Keesler <akeesler@vmware.com> Co-authored-by: Ryan Richard <richardry@vmware.com> Co-authored-by: Margo Crawford <margaretc@vmware.com>
2021-02-03 23:49:15 +00:00
s, ok = Replace("bad-suffix-that-end-in.prefixed-pinniped.dev", "shouldnt-matter.com")
require.Equal(t, "", s)
Allow multiple Pinnipeds to work on same cluster Yes, this is a huge commit. The middleware allows you to customize the API groups of all of the *.pinniped.dev API groups. Some notes about other small things in this commit: - We removed the internal/client package in favor of pkg/conciergeclient. The two packages do basically the same thing. I don't think we use the former anymore. - We re-enabled cluster-scoped owner assertions in the integration tests. This code was added in internal/ownerref. See a0546942 for when this assertion was removed. - Note: the middlware code is in charge of restoring the GV of a request object, so we should never need to write mutations that do that. - We updated the supervisor secret generation to no longer manually set an owner reference to the deployment since the middleware code now does this. I think we still need some way to make an initial event for the secret generator controller, which involves knowing the namespace and the name of the generated secret, so I still wired the deployment through. We could use a namespace/name tuple here, but I was lazy. Signed-off-by: Andrew Keesler <akeesler@vmware.com> Co-authored-by: Ryan Richard <richardry@vmware.com>
2021-01-13 01:27:41 +00:00
require.False(t, ok)
}
func TestReplaceSuffix(t *testing.T) {
s, ok := Replace("something.pinniped.dev.something-else.pinniped.dev", "tuna.io")
require.Equal(t, "something.pinniped.dev.something-else.tuna.io", s)
require.True(t, ok)
Use custom suffix in `Spec.Authenticator.APIGroup` of `TokenCredentialRequest` When the Pinniped server has been installed with the `api_group_suffix` option, for example using `mysuffix.com`, then clients who would like to submit a `TokenCredentialRequest` to the server should set the `Spec.Authenticator.APIGroup` field as `authentication.concierge.mysuffix.com`. This makes more sense from the client's point of view than using the default `authentication.concierge.pinniped.dev` because `authentication.concierge.mysuffix.com` is the name of the API group that they can observe their cluster and `authentication.concierge.pinniped.dev` does not exist as an API group on their cluster. This commit includes both the client and server-side changes to make this work, as well as integration test updates. Co-authored-by: Andrew Keesler <akeesler@vmware.com> Co-authored-by: Ryan Richard <richardry@vmware.com> Co-authored-by: Margo Crawford <margaretc@vmware.com>
2021-02-03 23:49:15 +00:00
// When the replace wasn't actually needed, it still returns true.
s, ok = Unreplace("something.pinniped.dev", "pinniped.dev")
require.Equal(t, "something.pinniped.dev", s)
require.True(t, ok)
}
func TestUnreplaceSuffix(t *testing.T) {
s, ok := Unreplace("something.pinniped.dev.something-else.tuna.io", "tuna.io")
require.Equal(t, "something.pinniped.dev.something-else.pinniped.dev", s)
require.True(t, ok)
// When the unreplace wasn't actually needed, it still returns true.
s, ok = Unreplace("something.pinniped.dev", "pinniped.dev")
require.Equal(t, "something.pinniped.dev", s)
require.True(t, ok)
// When the unreplace was needed but did not work, return false.
s, ok = Unreplace("something.pinniped.dev.something-else.tuna.io", "salmon.io")
require.Equal(t, "", s)
require.False(t, ok)
Allow multiple Pinnipeds to work on same cluster Yes, this is a huge commit. The middleware allows you to customize the API groups of all of the *.pinniped.dev API groups. Some notes about other small things in this commit: - We removed the internal/client package in favor of pkg/conciergeclient. The two packages do basically the same thing. I don't think we use the former anymore. - We re-enabled cluster-scoped owner assertions in the integration tests. This code was added in internal/ownerref. See a0546942 for when this assertion was removed. - Note: the middlware code is in charge of restoring the GV of a request object, so we should never need to write mutations that do that. - We updated the supervisor secret generation to no longer manually set an owner reference to the deployment since the middleware code now does this. I think we still need some way to make an initial event for the secret generator controller, which involves knowing the namespace and the name of the generated secret, so I still wired the deployment through. We could use a namespace/name tuple here, but I was lazy. Signed-off-by: Andrew Keesler <akeesler@vmware.com> Co-authored-by: Ryan Richard <richardry@vmware.com>
2021-01-13 01:27:41 +00:00
}
func TestValidate(t *testing.T) {
tests := []struct {
apiGroupSuffix string
wantErrorPrefix string
}{
{
apiGroupSuffix: "happy.suffix.com",
},
{
apiGroupSuffix: "no-dots",
Migrate callers to k8s.io/apimachinery/pkg/util/errors.NewAggregate Signed-off-by: Monis Khan <mok@vmware.com>
2021-02-05 17:56:05 +00:00
wantErrorPrefix: "must contain '.'",
Allow multiple Pinnipeds to work on same cluster Yes, this is a huge commit. The middleware allows you to customize the API groups of all of the *.pinniped.dev API groups. Some notes about other small things in this commit: - We removed the internal/client package in favor of pkg/conciergeclient. The two packages do basically the same thing. I don't think we use the former anymore. - We re-enabled cluster-scoped owner assertions in the integration tests. This code was added in internal/ownerref. See a0546942 for when this assertion was removed. - Note: the middlware code is in charge of restoring the GV of a request object, so we should never need to write mutations that do that. - We updated the supervisor secret generation to no longer manually set an owner reference to the deployment since the middleware code now does this. I think we still need some way to make an initial event for the secret generator controller, which involves knowing the namespace and the name of the generated secret, so I still wired the deployment through. We could use a namespace/name tuple here, but I was lazy. Signed-off-by: Andrew Keesler <akeesler@vmware.com> Co-authored-by: Ryan Richard <richardry@vmware.com>
2021-01-13 01:27:41 +00:00
},
{
apiGroupSuffix: ".starts.with.dot",
Migrate callers to k8s.io/apimachinery/pkg/util/errors.NewAggregate Signed-off-by: Monis Khan <mok@vmware.com>
2021-02-05 17:56:05 +00:00
wantErrorPrefix: "a lowercase RFC 1123 subdomain must consist",
Allow multiple Pinnipeds to work on same cluster Yes, this is a huge commit. The middleware allows you to customize the API groups of all of the *.pinniped.dev API groups. Some notes about other small things in this commit: - We removed the internal/client package in favor of pkg/conciergeclient. The two packages do basically the same thing. I don't think we use the former anymore. - We re-enabled cluster-scoped owner assertions in the integration tests. This code was added in internal/ownerref. See a0546942 for when this assertion was removed. - Note: the middlware code is in charge of restoring the GV of a request object, so we should never need to write mutations that do that. - We updated the supervisor secret generation to no longer manually set an owner reference to the deployment since the middleware code now does this. I think we still need some way to make an initial event for the secret generator controller, which involves knowing the namespace and the name of the generated secret, so I still wired the deployment through. We could use a namespace/name tuple here, but I was lazy. Signed-off-by: Andrew Keesler <akeesler@vmware.com> Co-authored-by: Ryan Richard <richardry@vmware.com>
2021-01-13 01:27:41 +00:00
},
{
apiGroupSuffix: "ends.with.dot.",
Migrate callers to k8s.io/apimachinery/pkg/util/errors.NewAggregate Signed-off-by: Monis Khan <mok@vmware.com>
2021-02-05 17:56:05 +00:00
wantErrorPrefix: "a lowercase RFC 1123 subdomain must consist",
Allow multiple Pinnipeds to work on same cluster Yes, this is a huge commit. The middleware allows you to customize the API groups of all of the *.pinniped.dev API groups. Some notes about other small things in this commit: - We removed the internal/client package in favor of pkg/conciergeclient. The two packages do basically the same thing. I don't think we use the former anymore. - We re-enabled cluster-scoped owner assertions in the integration tests. This code was added in internal/ownerref. See a0546942 for when this assertion was removed. - Note: the middlware code is in charge of restoring the GV of a request object, so we should never need to write mutations that do that. - We updated the supervisor secret generation to no longer manually set an owner reference to the deployment since the middleware code now does this. I think we still need some way to make an initial event for the secret generator controller, which involves knowing the namespace and the name of the generated secret, so I still wired the deployment through. We could use a namespace/name tuple here, but I was lazy. Signed-off-by: Andrew Keesler <akeesler@vmware.com> Co-authored-by: Ryan Richard <richardry@vmware.com>
2021-01-13 01:27:41 +00:00
},
{
apiGroupSuffix: ".multiple-issues.because-this-string-is-longer-than-the-253-character-limit-of-a-dns-1123-identifier-" + chars(253),
Migrate callers to k8s.io/apimachinery/pkg/util/errors.NewAggregate Signed-off-by: Monis Khan <mok@vmware.com>
2021-02-05 17:56:05 +00:00
wantErrorPrefix: "[must be no more than 253 characters, a lowercase RFC 1123 subdomain must consist",
Allow multiple Pinnipeds to work on same cluster Yes, this is a huge commit. The middleware allows you to customize the API groups of all of the *.pinniped.dev API groups. Some notes about other small things in this commit: - We removed the internal/client package in favor of pkg/conciergeclient. The two packages do basically the same thing. I don't think we use the former anymore. - We re-enabled cluster-scoped owner assertions in the integration tests. This code was added in internal/ownerref. See a0546942 for when this assertion was removed. - Note: the middlware code is in charge of restoring the GV of a request object, so we should never need to write mutations that do that. - We updated the supervisor secret generation to no longer manually set an owner reference to the deployment since the middleware code now does this. I think we still need some way to make an initial event for the secret generator controller, which involves knowing the namespace and the name of the generated secret, so I still wired the deployment through. We could use a namespace/name tuple here, but I was lazy. Signed-off-by: Andrew Keesler <akeesler@vmware.com> Co-authored-by: Ryan Richard <richardry@vmware.com>
2021-01-13 01:27:41 +00:00
},
}
for _, test := range tests {
test := test
t.Run(test.apiGroupSuffix, func(t *testing.T) {
err := Validate(test.apiGroupSuffix)
if test.wantErrorPrefix != "" {
require.Error(t, err)
require.Truef(
t,
strings.HasPrefix(err.Error(), test.wantErrorPrefix),
"%q does not start with %q", err.Error(), test.wantErrorPrefix)
} else {
require.NoError(t, err)
}
})
}
}
internal/groupsuffix: mutate TokenCredentialRequest's Authenticator This is a partial revert of 288d9c999efe. For some reason it didn't occur to me that we could do it this way earlier. Whoops. This also contains a middleware update: mutation funcs can return an error now and short-circuit the rest of the request/response flow. The idea here is that if someone is configuring their kubeclient to use middleware, they are agreeing to a narrow-er client contract by doing so (e.g., their TokenCredentialRequest's must have an Spec.Authenticator.APIGroup set). I also updated some internal/groupsuffix tests to be more realistic. Signed-off-by: Andrew Keesler <akeesler@vmware.com>
2021-02-05 01:02:59 +00:00
type withFunc func(obj kubeclient.Object)
func with(obj kubeclient.Object, withFuncs ...withFunc) kubeclient.Object {
obj = obj.DeepCopyObject().(kubeclient.Object)
for _, withFunc := range withFuncs {
withFunc(obj)
}
return obj
}
func gvk(gvk schema.GroupVersionKind) withFunc {
return func(obj kubeclient.Object) {
obj.GetObjectKind().SetGroupVersionKind(gvk)
}
}
func authenticatorAPIGroup(apiGroup string) withFunc {
return func(obj kubeclient.Object) {
tokenCredentialRequest := obj.(*loginv1alpha1.TokenCredentialRequest)
tokenCredentialRequest.Spec.Authenticator.APIGroup = &apiGroup
}
}
func replaceGV(t *testing.T, baseGV schema.GroupVersion, apiGroupSuffix string) schema.GroupVersion {
Allow multiple Pinnipeds to work on same cluster Yes, this is a huge commit. The middleware allows you to customize the API groups of all of the *.pinniped.dev API groups. Some notes about other small things in this commit: - We removed the internal/client package in favor of pkg/conciergeclient. The two packages do basically the same thing. I don't think we use the former anymore. - We re-enabled cluster-scoped owner assertions in the integration tests. This code was added in internal/ownerref. See a0546942 for when this assertion was removed. - Note: the middlware code is in charge of restoring the GV of a request object, so we should never need to write mutations that do that. - We updated the supervisor secret generation to no longer manually set an owner reference to the deployment since the middleware code now does this. I think we still need some way to make an initial event for the secret generator controller, which involves knowing the namespace and the name of the generated secret, so I still wired the deployment through. We could use a namespace/name tuple here, but I was lazy. Signed-off-by: Andrew Keesler <akeesler@vmware.com> Co-authored-by: Ryan Richard <richardry@vmware.com>
2021-01-13 01:27:41 +00:00
t.Helper()
groupName, ok := Replace(baseGV.Group, apiGroupSuffix)
require.True(t, ok, "expected to be able to replace %q's suffix with %q", baseGV.Group, apiGroupSuffix)
internal/groupsuffix: mutate TokenCredentialRequest's Authenticator This is a partial revert of 288d9c999efe. For some reason it didn't occur to me that we could do it this way earlier. Whoops. This also contains a middleware update: mutation funcs can return an error now and short-circuit the rest of the request/response flow. The idea here is that if someone is configuring their kubeclient to use middleware, they are agreeing to a narrow-er client contract by doing so (e.g., their TokenCredentialRequest's must have an Spec.Authenticator.APIGroup set). I also updated some internal/groupsuffix tests to be more realistic. Signed-off-by: Andrew Keesler <akeesler@vmware.com>
2021-02-05 01:02:59 +00:00
return schema.GroupVersion{Group: groupName, Version: baseGV.Version}
Allow multiple Pinnipeds to work on same cluster Yes, this is a huge commit. The middleware allows you to customize the API groups of all of the *.pinniped.dev API groups. Some notes about other small things in this commit: - We removed the internal/client package in favor of pkg/conciergeclient. The two packages do basically the same thing. I don't think we use the former anymore. - We re-enabled cluster-scoped owner assertions in the integration tests. This code was added in internal/ownerref. See a0546942 for when this assertion was removed. - Note: the middlware code is in charge of restoring the GV of a request object, so we should never need to write mutations that do that. - We updated the supervisor secret generation to no longer manually set an owner reference to the deployment since the middleware code now does this. I think we still need some way to make an initial event for the secret generator controller, which involves knowing the namespace and the name of the generated secret, so I still wired the deployment through. We could use a namespace/name tuple here, but I was lazy. Signed-off-by: Andrew Keesler <akeesler@vmware.com> Co-authored-by: Ryan Richard <richardry@vmware.com>
2021-01-13 01:27:41 +00:00
}
func chars(count int) string {
return strings.Repeat("a", count)
}
Reference in New Issue Copy Permalink