djpbessems/ContainerImage.Pinniped
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
4e8601e73b
ContainerImage.Pinniped/internal/config/concierge/config_test.go

612 lines
24 KiB
Go
Raw Normal View History

Upgrade the linter and fix all new linter warnings Also fix some tests that were broken by bumping golang and dependencies in the previous commits. Note that in addition to changes made to satisfy the linter which do not impact the behavior of the code, this commit also adds ReadHeaderTimeout to all usages of http.Server to satisfy the linter (and because it seemed like a good suggestion).
2022-08-24 21:45:55 +00:00
// Copyright 2020-2022 the Pinniped contributors. All Rights Reserved.
Save 2 lines by using inline-style comments for Copyright Signed-off-by: Andrew Keesler <akeesler@vmware.com>
2020-09-16 14:19:51 +00:00
// SPDX-License-Identifier: Apache-2.0
Define initial config file format - Users may want to consume pkg/config to generate configuration files. - This also involved putting config-related utilities in the config package for ease of consumption. - We did not add in versioning into the Config type for now...this is something we will likely do in the future, but it is not deemed necessary this early in the project. - The config file format tries to follow the patterns of Kube. One such example of this is requiring the use of base64-encoded CA bundle PEM bytes instead of a file path. This also slightly simplifies the config file handling because we don't have to 1) read in a file or 2) deal with the error case of the file not being there. - The webhook code from k8s.io/apiserver is really exactly what we want here. If this dependency gets too burdensome, we can always drop it, but the pros outweigh the cons at the moment. - Writing out a kubeconfig to disk to configure the webhook is a little janky, but hopefully this won't hurt performance too much in the year 2020. - Also bonus: call the right *Serve*() function when starting our servers. Signed-off-by: Andrew Keesler <akeesler@vmware.com>
2020-07-14 15:50:14 +00:00
Supervisor controllers apply custom labels to JWKS secrets Signed-off-by: Ryan Richard <richardry@vmware.com>
2020-10-15 19:40:56 +00:00
package concierge
Define initial config file format - Users may want to consume pkg/config to generate configuration files. - This also involved putting config-related utilities in the config package for ease of consumption. - We did not add in versioning into the Config type for now...this is something we will likely do in the future, but it is not deemed necessary this early in the project. - The config file format tries to follow the patterns of Kube. One such example of this is requiring the use of base64-encoded CA bundle PEM bytes instead of a file path. This also slightly simplifies the config file handling because we don't have to 1) read in a file or 2) deal with the error case of the file not being there. - The webhook code from k8s.io/apiserver is really exactly what we want here. If this dependency gets too burdensome, we can always drop it, but the pros outweigh the cons at the moment. - Writing out a kubeconfig to disk to configure the webhook is a little janky, but hopefully this won't hurt performance too much in the year 2020. - Also bonus: call the right *Serve*() function when starting our servers. Signed-off-by: Andrew Keesler <akeesler@vmware.com>
2020-07-14 15:50:14 +00:00
import (
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
"context"
Rename many of resources that are created in Kubernetes by Pinniped New resource naming conventions: - Do not repeat the Kind in the name, e.g. do not call it foo-cluster-role-binding, just call it foo - Names will generally start with a prefix to identify our component, so when a user lists all objects of that kind, they can tell to which component it is related, e.g. `kubectl get configmaps` would list one named "pinniped-config" - It should be possible for an operator to make the word "pinniped" mostly disappear if they choose, by specifying the app_name in values.yaml, to the extent that is practical (but not from APIService names because those are hardcoded in golang) - Each role/clusterrole and its corresponding binding have the same name - Pinniped resource names that must be known by the server golang code are passed to the code at run time via ConfigMap, rather than hardcoded in the golang code. This also allows them to be prepended with the app_name from values.yaml while creating the ConfigMap. - Since the CLI `get-kubeconfig` command cannot guess the name of the CredentialIssuerConfig resource in advance anymore, it lists all CredentialIssuerConfig in the app's namespace and returns an error if there is not exactly one found, and then uses that one regardless of its name
2020-09-18 22:56:50 +00:00
"os"
Define initial config file format - Users may want to consume pkg/config to generate configuration files. - This also involved putting config-related utilities in the config package for ease of consumption. - We did not add in versioning into the Config type for now...this is something we will likely do in the future, but it is not deemed necessary this early in the project. - The config file format tries to follow the patterns of Kube. One such example of this is requiring the use of base64-encoded CA bundle PEM bytes instead of a file path. This also slightly simplifies the config file handling because we don't have to 1) read in a file or 2) deal with the error case of the file not being there. - The webhook code from k8s.io/apiserver is really exactly what we want here. If this dependency gets too burdensome, we can always drop it, but the pros outweigh the cons at the moment. - Writing out a kubeconfig to disk to configure the webhook is a little janky, but hopefully this won't hurt performance too much in the year 2020. - Also bonus: call the right *Serve*() function when starting our servers. Signed-off-by: Andrew Keesler <akeesler@vmware.com>
2020-07-14 15:50:14 +00:00
"testing"
"github.com/stretchr/testify/require"
Replace all usages of strPtr() with pointer.StringPtr()
2021-05-12 20:20:00 +00:00
"k8s.io/utils/pointer"
Define initial config file format - Users may want to consume pkg/config to generate configuration files. - This also involved putting config-related utilities in the config package for ease of consumption. - We did not add in versioning into the Config type for now...this is something we will likely do in the future, but it is not deemed necessary this early in the project. - The config file format tries to follow the patterns of Kube. One such example of this is requiring the use of base64-encoded CA bundle PEM bytes instead of a file path. This also slightly simplifies the config file handling because we don't have to 1) read in a file or 2) deal with the error case of the file not being there. - The webhook code from k8s.io/apiserver is really exactly what we want here. If this dependency gets too burdensome, we can always drop it, but the pros outweigh the cons at the moment. - Writing out a kubeconfig to disk to configure the webhook is a little janky, but hopefully this won't hurt performance too much in the year 2020. - Also bonus: call the right *Serve*() function when starting our servers. Signed-off-by: Andrew Keesler <akeesler@vmware.com>
2020-07-14 15:50:14 +00:00
Merge branch 'main' into rename_stuff
2020-09-18 23:39:58 +00:00
"go.pinniped.dev/internal/here"
Read the names of the impersonation-related resources from the config They were previously temporarily hardcoded. Now they are set at deploy time via the static ConfigMap in deployment.yaml
2021-03-02 17:31:24 +00:00
"go.pinniped.dev/internal/plog"
Define initial config file format - Users may want to consume pkg/config to generate configuration files. - This also involved putting config-related utilities in the config package for ease of consumption. - We did not add in versioning into the Config type for now...this is something we will likely do in the future, but it is not deemed necessary this early in the project. - The config file format tries to follow the patterns of Kube. One such example of this is requiring the use of base64-encoded CA bundle PEM bytes instead of a file path. This also slightly simplifies the config file handling because we don't have to 1) read in a file or 2) deal with the error case of the file not being there. - The webhook code from k8s.io/apiserver is really exactly what we want here. If this dependency gets too burdensome, we can always drop it, but the pros outweigh the cons at the moment. - Writing out a kubeconfig to disk to configure the webhook is a little janky, but hopefully this won't hurt performance too much in the year 2020. - Also bonus: call the right *Serve*() function when starting our servers. Signed-off-by: Andrew Keesler <akeesler@vmware.com>
2020-07-14 15:50:14 +00:00
)
func TestFromPath(t *testing.T) {
Allow override of discovery URL via ConfigMap Signed-off-by: Andrew Keesler <akeesler@vmware.com> - Seems like the next step is to allow override of the CA bundle; I didn't do that here for simplicity of the commit, but seems like it is the right thing to do in the future.
2020-08-03 14:17:11 +00:00
tests := []struct {
name string
Rename many of resources that are created in Kubernetes by Pinniped New resource naming conventions: - Do not repeat the Kind in the name, e.g. do not call it foo-cluster-role-binding, just call it foo - Names will generally start with a prefix to identify our component, so when a user lists all objects of that kind, they can tell to which component it is related, e.g. `kubectl get configmaps` would list one named "pinniped-config" - It should be possible for an operator to make the word "pinniped" mostly disappear if they choose, by specifying the app_name in values.yaml, to the extent that is practical (but not from APIService names because those are hardcoded in golang) - Each role/clusterrole and its corresponding binding have the same name - Pinniped resource names that must be known by the server golang code are passed to the code at run time via ConfigMap, rather than hardcoded in the golang code. This also allows them to be prepended with the app_name from values.yaml while creating the ConfigMap. - Since the CLI `get-kubeconfig` command cannot guess the name of the CredentialIssuerConfig resource in advance anymore, it lists all CredentialIssuerConfig in the app's namespace and returns an error if there is not exactly one found, and then uses that one regardless of its name
2020-09-18 22:56:50 +00:00
yaml string
Supervisor controllers apply custom labels to JWKS secrets Signed-off-by: Ryan Richard <richardry@vmware.com>
2020-10-15 19:40:56 +00:00
wantConfig *Config
Use duration and renewBefore to control API cert rotation These configuration knobs are much more human-understandable than the previous percentage-based threshold flag. We now allow users to set the lifetime of the serving cert via a ConfigMap. Previously this was hardcoded to 1 year. Signed-off-by: Andrew Keesler <akeesler@vmware.com>
2020-08-20 19:17:18 +00:00
wantError string
Allow override of discovery URL via ConfigMap Signed-off-by: Andrew Keesler <akeesler@vmware.com> - Seems like the next step is to allow override of the CA bundle; I didn't do that here for simplicity of the commit, but seems like it is the right thing to do in the future.
2020-08-03 14:17:11 +00:00
}{
{
Read the names of the impersonation-related resources from the config They were previously temporarily hardcoded. Now they are set at deploy time via the static ConfigMap in deployment.yaml
2021-03-02 17:31:24 +00:00
name: "Fully filled out",
Rename many of resources that are created in Kubernetes by Pinniped New resource naming conventions: - Do not repeat the Kind in the name, e.g. do not call it foo-cluster-role-binding, just call it foo - Names will generally start with a prefix to identify our component, so when a user lists all objects of that kind, they can tell to which component it is related, e.g. `kubectl get configmaps` would list one named "pinniped-config" - It should be possible for an operator to make the word "pinniped" mostly disappear if they choose, by specifying the app_name in values.yaml, to the extent that is practical (but not from APIService names because those are hardcoded in golang) - Each role/clusterrole and its corresponding binding have the same name - Pinniped resource names that must be known by the server golang code are passed to the code at run time via ConfigMap, rather than hardcoded in the golang code. This also allows them to be prepended with the app_name from values.yaml while creating the ConfigMap. - Since the CLI `get-kubeconfig` command cannot guess the name of the CredentialIssuerConfig resource in advance anymore, it lists all CredentialIssuerConfig in the app's namespace and returns an error if there is not exactly one found, and then uses that one regardless of its name
2020-09-18 22:56:50 +00:00
yaml: here.Doc(`
---
discovery:
url: https://some.discovery/url
api:
servingCertificate:
durationSeconds: 3600
renewBeforeSeconds: 2400
internal/config: wire API group suffix through to server components Signed-off-by: Andrew Keesler <akeesler@vmware.com>
2021-01-19 15:52:12 +00:00
apiGroupSuffix: some.suffix.com
Add aggregatedAPIServerPort to the Concierge's static ConfigMap - Allow the port number to be configured to any value within the range 1024 to 65535 - This commit does not include adding new config knobs to the ytt values file, so while it is possible to change this port without needing to recompile, it is not convenient
2021-11-17 00:43:51 +00:00
aggregatedAPIServerPort: 12345
Add impersonationProxyServerPort to the Concierge's static ConfigMap - Used to determine on which port the impersonation proxy will bind - Defaults to 8444, which is the old hard-coded port value - Allow the port number to be configured to any value within the range 1024 to 65535 - This commit does not include adding new config knobs to the ytt values file, so while it is possible to change this port without needing to recompile, it is not convenient
2021-11-17 21:27:59 +00:00
impersonationProxyServerPort: 4242
Rename many of resources that are created in Kubernetes by Pinniped New resource naming conventions: - Do not repeat the Kind in the name, e.g. do not call it foo-cluster-role-binding, just call it foo - Names will generally start with a prefix to identify our component, so when a user lists all objects of that kind, they can tell to which component it is related, e.g. `kubectl get configmaps` would list one named "pinniped-config" - It should be possible for an operator to make the word "pinniped" mostly disappear if they choose, by specifying the app_name in values.yaml, to the extent that is practical (but not from APIService names because those are hardcoded in golang) - Each role/clusterrole and its corresponding binding have the same name - Pinniped resource names that must be known by the server golang code are passed to the code at run time via ConfigMap, rather than hardcoded in the golang code. This also allows them to be prepended with the app_name from values.yaml while creating the ConfigMap. - Since the CLI `get-kubeconfig` command cannot guess the name of the CredentialIssuerConfig resource in advance anymore, it lists all CredentialIssuerConfig in the app's namespace and returns an error if there is not exactly one found, and then uses that one regardless of its name
2020-09-18 22:56:50 +00:00
names:
Make tilt work with the supervisor app and add more uninstall testing - Also continue renaming things related to the concierge app - Enhance the uninstall test to also test uninstalling the supervisor and local-user-authenticator apps
2020-10-09 21:25:34 +00:00
servingCertificateSecret: pinniped-concierge-api-tls-serving-certificate
Rename CredentialIssuerConfig to CredentialIssuer. Signed-off-by: Matt Moyer <moyerm@vmware.com>
2020-11-02 21:39:43 +00:00
credentialIssuer: pinniped-config
Rename many of resources that are created in Kubernetes by Pinniped New resource naming conventions: - Do not repeat the Kind in the name, e.g. do not call it foo-cluster-role-binding, just call it foo - Names will generally start with a prefix to identify our component, so when a user lists all objects of that kind, they can tell to which component it is related, e.g. `kubectl get configmaps` would list one named "pinniped-config" - It should be possible for an operator to make the word "pinniped" mostly disappear if they choose, by specifying the app_name in values.yaml, to the extent that is practical (but not from APIService names because those are hardcoded in golang) - Each role/clusterrole and its corresponding binding have the same name - Pinniped resource names that must be known by the server golang code are passed to the code at run time via ConfigMap, rather than hardcoded in the golang code. This also allows them to be prepended with the app_name from values.yaml while creating the ConfigMap. - Since the CLI `get-kubeconfig` command cannot guess the name of the CredentialIssuerConfig resource in advance anymore, it lists all CredentialIssuerConfig in the app's namespace and returns an error if there is not exactly one found, and then uses that one regardless of its name
2020-09-18 22:56:50 +00:00
apiService: pinniped-api
Add kube-cert-agent controller for getting kube API keypair
2020-09-21 18:16:14 +00:00
kubeCertAgentPrefix: kube-cert-agent-prefix
Read the names of the impersonation-related resources from the config They were previously temporarily hardcoded. Now they are set at deploy time via the static ConfigMap in deployment.yaml
2021-03-02 17:31:24 +00:00
impersonationLoadBalancerService: impersonationLoadBalancerService-value
Wire generatedClusterIPServiceName through from NamesConfig
2021-05-20 21:11:35 +00:00
impersonationClusterIPService: impersonationClusterIPService-value
Read the names of the impersonation-related resources from the config They were previously temporarily hardcoded. Now they are set at deploy time via the static ConfigMap in deployment.yaml
2021-03-02 17:31:24 +00:00
impersonationTLSCertificateSecret: impersonationTLSCertificateSecret-value
impersonationCACertificateSecret: impersonationCACertificateSecret-value
Use TokenCredentialRequest instead of base64 token with impersonator To make an impersonation request, first make a TokenCredentialRequest to get a certificate. That cert will either be issued by the Kube API server's CA or by a new CA specific to the impersonator. Either way, you can then make a request to the impersonator and present that client cert for auth and the impersonator will accept it and make the impesonation call on your behalf. The impersonator http handler now borrows some Kube library code to handle request processing. This will allow us to more closely mimic the behavior of a real API server, e.g. the client cert auth will work exactly like the real API server. Signed-off-by: Monis Khan <mok@vmware.com>
2021-03-10 18:30:06 +00:00
impersonationSignerSecret: impersonationSignerSecret-value
impersonationSignerSecret: impersonationSignerSecret-value
Split out kube-cert-agent service account and bindings. Followup on the previous comment to split apart the ServiceAccount of the kube-cert-agent and the main concierge pod. This is a bit cleaner and ensures that in testing our main Concierge pod never requires any privileged permissions. Signed-off-by: Matt Moyer <moyerm@vmware.com>
2021-05-03 21:31:48 +00:00
agentServiceAccount: agentServiceAccount-value
Remove references to impersonationConfigMap. Signed-off-by: Margo Crawford <margaretc@vmware.com>
2021-05-26 20:24:59 +00:00
extraName: extraName-value
Concierge controllers add labels to all created resources
2020-10-15 17:14:23 +00:00
labels:
myLabelKey1: myLabelValue1
myLabelKey2: myLabelValue2
Read the names of the impersonation-related resources from the config They were previously temporarily hardcoded. Now they are set at deploy time via the static ConfigMap in deployment.yaml
2021-03-02 17:31:24 +00:00
kubeCertAgent:
Add kube-cert-agent controller for getting kube API keypair
2020-09-21 18:16:14 +00:00
namePrefix: kube-cert-agent-name-prefix-
image: kube-cert-agent-image
Plumb through ImagePullSecrets to agent pod Right now in the YTT templates we assume that the agent pods are gonna use the same image as the main Pinniped deployment, so we can use the same logic for the image pull secrets. Signed-off-by: Andrew Keesler <akeesler@vmware.com>
2020-09-24 19:52:05 +00:00
imagePullSecrets: [kube-cert-agent-image-pull-secret]
Read the names of the impersonation-related resources from the config They were previously temporarily hardcoded. Now they are set at deploy time via the static ConfigMap in deployment.yaml
2021-03-02 17:31:24 +00:00
logLevel: debug
Rename many of resources that are created in Kubernetes by Pinniped New resource naming conventions: - Do not repeat the Kind in the name, e.g. do not call it foo-cluster-role-binding, just call it foo - Names will generally start with a prefix to identify our component, so when a user lists all objects of that kind, they can tell to which component it is related, e.g. `kubectl get configmaps` would list one named "pinniped-config" - It should be possible for an operator to make the word "pinniped" mostly disappear if they choose, by specifying the app_name in values.yaml, to the extent that is practical (but not from APIService names because those are hardcoded in golang) - Each role/clusterrole and its corresponding binding have the same name - Pinniped resource names that must be known by the server golang code are passed to the code at run time via ConfigMap, rather than hardcoded in the golang code. This also allows them to be prepended with the app_name from values.yaml while creating the ConfigMap. - Since the CLI `get-kubeconfig` command cannot guess the name of the CredentialIssuerConfig resource in advance anymore, it lists all CredentialIssuerConfig in the app's namespace and returns an error if there is not exactly one found, and then uses that one regardless of its name
2020-09-18 22:56:50 +00:00
`),
Supervisor controllers apply custom labels to JWKS secrets Signed-off-by: Ryan Richard <richardry@vmware.com>
2020-10-15 19:40:56 +00:00
wantConfig: &Config{
DiscoveryInfo: DiscoveryInfoSpec{
Replace all usages of strPtr() with pointer.StringPtr()
2021-05-12 20:20:00 +00:00
URL: pointer.StringPtr("https://some.discovery/url"),
Allow override of discovery URL via ConfigMap Signed-off-by: Andrew Keesler <akeesler@vmware.com> - Seems like the next step is to allow override of the CA bundle; I didn't do that here for simplicity of the commit, but seems like it is the right thing to do in the future.
2020-08-03 14:17:11 +00:00
},
Supervisor controllers apply custom labels to JWKS secrets Signed-off-by: Ryan Richard <richardry@vmware.com>
2020-10-15 19:40:56 +00:00
APIConfig: APIConfigSpec{
ServingCertificateConfig: ServingCertificateConfigSpec{
Missed a usage of int64Ptr in previous commit
2021-05-12 21:00:26 +00:00
DurationSeconds: pointer.Int64Ptr(3600),
RenewBeforeSeconds: pointer.Int64Ptr(2400),
Use duration and renewBefore to control API cert rotation These configuration knobs are much more human-understandable than the previous percentage-based threshold flag. We now allow users to set the lifetime of the serving cert via a ConfigMap. Previously this was hardcoded to 1 year. Signed-off-by: Andrew Keesler <akeesler@vmware.com>
2020-08-20 19:17:18 +00:00
},
},
Add impersonationProxyServerPort to the Concierge's static ConfigMap - Used to determine on which port the impersonation proxy will bind - Defaults to 8444, which is the old hard-coded port value - Allow the port number to be configured to any value within the range 1024 to 65535 - This commit does not include adding new config knobs to the ytt values file, so while it is possible to change this port without needing to recompile, it is not convenient
2021-11-17 21:27:59 +00:00
APIGroupSuffix: pointer.StringPtr("some.suffix.com"),
AggregatedAPIServerPort: pointer.Int64Ptr(12345),
ImpersonationProxyServerPort: pointer.Int64Ptr(4242),
Supervisor controllers apply custom labels to JWKS secrets Signed-off-by: Ryan Richard <richardry@vmware.com>
2020-10-15 19:40:56 +00:00
NamesConfig: NamesConfigSpec{
Read the names of the impersonation-related resources from the config They were previously temporarily hardcoded. Now they are set at deploy time via the static ConfigMap in deployment.yaml
2021-03-02 17:31:24 +00:00
ServingCertificateSecret: "pinniped-concierge-api-tls-serving-certificate",
CredentialIssuer: "pinniped-config",
APIService: "pinniped-api",
ImpersonationLoadBalancerService: "impersonationLoadBalancerService-value",
Wire generatedClusterIPServiceName through from NamesConfig
2021-05-20 21:11:35 +00:00
ImpersonationClusterIPService: "impersonationClusterIPService-value",
Read the names of the impersonation-related resources from the config They were previously temporarily hardcoded. Now they are set at deploy time via the static ConfigMap in deployment.yaml
2021-03-02 17:31:24 +00:00
ImpersonationTLSCertificateSecret: "impersonationTLSCertificateSecret-value",
ImpersonationCACertificateSecret: "impersonationCACertificateSecret-value",
Use TokenCredentialRequest instead of base64 token with impersonator To make an impersonation request, first make a TokenCredentialRequest to get a certificate. That cert will either be issued by the Kube API server's CA or by a new CA specific to the impersonator. Either way, you can then make a request to the impersonator and present that client cert for auth and the impersonator will accept it and make the impesonation call on your behalf. The impersonator http handler now borrows some Kube library code to handle request processing. This will allow us to more closely mimic the behavior of a real API server, e.g. the client cert auth will work exactly like the real API server. Signed-off-by: Monis Khan <mok@vmware.com>
2021-03-10 18:30:06 +00:00
ImpersonationSignerSecret: "impersonationSignerSecret-value",
Split out kube-cert-agent service account and bindings. Followup on the previous comment to split apart the ServiceAccount of the kube-cert-agent and the main concierge pod. This is a bit cleaner and ensures that in testing our main Concierge pod never requires any privileged permissions. Signed-off-by: Matt Moyer <moyerm@vmware.com>
2021-05-03 21:31:48 +00:00
AgentServiceAccount: "agentServiceAccount-value",
Rename many of resources that are created in Kubernetes by Pinniped New resource naming conventions: - Do not repeat the Kind in the name, e.g. do not call it foo-cluster-role-binding, just call it foo - Names will generally start with a prefix to identify our component, so when a user lists all objects of that kind, they can tell to which component it is related, e.g. `kubectl get configmaps` would list one named "pinniped-config" - It should be possible for an operator to make the word "pinniped" mostly disappear if they choose, by specifying the app_name in values.yaml, to the extent that is practical (but not from APIService names because those are hardcoded in golang) - Each role/clusterrole and its corresponding binding have the same name - Pinniped resource names that must be known by the server golang code are passed to the code at run time via ConfigMap, rather than hardcoded in the golang code. This also allows them to be prepended with the app_name from values.yaml while creating the ConfigMap. - Since the CLI `get-kubeconfig` command cannot guess the name of the CredentialIssuerConfig resource in advance anymore, it lists all CredentialIssuerConfig in the app's namespace and returns an error if there is not exactly one found, and then uses that one regardless of its name
2020-09-18 22:56:50 +00:00
},
Concierge controllers add labels to all created resources
2020-10-15 17:14:23 +00:00
Labels: map[string]string{
"myLabelKey1": "myLabelValue1",
"myLabelKey2": "myLabelValue2",
},
Supervisor controllers apply custom labels to JWKS secrets Signed-off-by: Ryan Richard <richardry@vmware.com>
2020-10-15 19:40:56 +00:00
KubeCertAgentConfig: KubeCertAgentSpec{
Replace all usages of strPtr() with pointer.StringPtr()
2021-05-12 20:20:00 +00:00
NamePrefix: pointer.StringPtr("kube-cert-agent-name-prefix-"),
Image: pointer.StringPtr("kube-cert-agent-image"),
Plumb through ImagePullSecrets to agent pod Right now in the YTT templates we assume that the agent pods are gonna use the same image as the main Pinniped deployment, so we can use the same logic for the image pull secrets. Signed-off-by: Andrew Keesler <akeesler@vmware.com>
2020-09-24 19:52:05 +00:00
ImagePullSecrets: []string{"kube-cert-agent-image-pull-secret"},
Add kube-cert-agent controller for getting kube API keypair
2020-09-21 18:16:14 +00:00
},
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
LogLevel: func(level plog.LogLevel) *plog.LogLevel { return &level }(plog.LevelDebug),
Log: plog.LogSpec{
Level: plog.LevelDebug,
},
},
},
{
name: "Fully filled out new log struct",
yaml: here.Doc(`
---
discovery:
url: https://some.discovery/url
api:
servingCertificate:
durationSeconds: 3600
renewBeforeSeconds: 2400
apiGroupSuffix: some.suffix.com
aggregatedAPIServerPort: 12345
impersonationProxyServerPort: 4242
names:
servingCertificateSecret: pinniped-concierge-api-tls-serving-certificate
credentialIssuer: pinniped-config
apiService: pinniped-api
kubeCertAgentPrefix: kube-cert-agent-prefix
impersonationLoadBalancerService: impersonationLoadBalancerService-value
impersonationClusterIPService: impersonationClusterIPService-value
impersonationTLSCertificateSecret: impersonationTLSCertificateSecret-value
impersonationCACertificateSecret: impersonationCACertificateSecret-value
impersonationSignerSecret: impersonationSignerSecret-value
impersonationSignerSecret: impersonationSignerSecret-value
agentServiceAccount: agentServiceAccount-value
extraName: extraName-value
labels:
myLabelKey1: myLabelValue1
myLabelKey2: myLabelValue2
kubeCertAgent:
namePrefix: kube-cert-agent-name-prefix-
image: kube-cert-agent-image
imagePullSecrets: [kube-cert-agent-image-pull-secret]
log:
level: all
format: json
`),
wantConfig: &Config{
DiscoveryInfo: DiscoveryInfoSpec{
URL: pointer.StringPtr("https://some.discovery/url"),
},
APIConfig: APIConfigSpec{
ServingCertificateConfig: ServingCertificateConfigSpec{
DurationSeconds: pointer.Int64Ptr(3600),
RenewBeforeSeconds: pointer.Int64Ptr(2400),
},
},
APIGroupSuffix: pointer.StringPtr("some.suffix.com"),
AggregatedAPIServerPort: pointer.Int64Ptr(12345),
ImpersonationProxyServerPort: pointer.Int64Ptr(4242),
NamesConfig: NamesConfigSpec{
ServingCertificateSecret: "pinniped-concierge-api-tls-serving-certificate",
CredentialIssuer: "pinniped-config",
APIService: "pinniped-api",
ImpersonationLoadBalancerService: "impersonationLoadBalancerService-value",
ImpersonationClusterIPService: "impersonationClusterIPService-value",
ImpersonationTLSCertificateSecret: "impersonationTLSCertificateSecret-value",
ImpersonationCACertificateSecret: "impersonationCACertificateSecret-value",
ImpersonationSignerSecret: "impersonationSignerSecret-value",
AgentServiceAccount: "agentServiceAccount-value",
},
Labels: map[string]string{
"myLabelKey1": "myLabelValue1",
"myLabelKey2": "myLabelValue2",
},
KubeCertAgentConfig: KubeCertAgentSpec{
NamePrefix: pointer.StringPtr("kube-cert-agent-name-prefix-"),
Image: pointer.StringPtr("kube-cert-agent-image"),
ImagePullSecrets: []string{"kube-cert-agent-image-pull-secret"},
},
Log: plog.LogSpec{
Level: plog.LevelAll,
Format: plog.FormatJSON,
},
},
},
{
name: "Fully filled out old log and new log struct",
yaml: here.Doc(`
---
discovery:
url: https://some.discovery/url
api:
servingCertificate:
durationSeconds: 3600
renewBeforeSeconds: 2400
apiGroupSuffix: some.suffix.com
aggregatedAPIServerPort: 12345
impersonationProxyServerPort: 4242
names:
servingCertificateSecret: pinniped-concierge-api-tls-serving-certificate
credentialIssuer: pinniped-config
apiService: pinniped-api
kubeCertAgentPrefix: kube-cert-agent-prefix
impersonationLoadBalancerService: impersonationLoadBalancerService-value
impersonationClusterIPService: impersonationClusterIPService-value
impersonationTLSCertificateSecret: impersonationTLSCertificateSecret-value
impersonationCACertificateSecret: impersonationCACertificateSecret-value
impersonationSignerSecret: impersonationSignerSecret-value
impersonationSignerSecret: impersonationSignerSecret-value
agentServiceAccount: agentServiceAccount-value
extraName: extraName-value
labels:
myLabelKey1: myLabelValue1
myLabelKey2: myLabelValue2
kubeCertAgent:
namePrefix: kube-cert-agent-name-prefix-
image: kube-cert-agent-image
imagePullSecrets: [kube-cert-agent-image-pull-secret]
logLevel: debug
log:
level: all
format: json
`),
wantConfig: &Config{
DiscoveryInfo: DiscoveryInfoSpec{
URL: pointer.StringPtr("https://some.discovery/url"),
},
APIConfig: APIConfigSpec{
ServingCertificateConfig: ServingCertificateConfigSpec{
DurationSeconds: pointer.Int64Ptr(3600),
RenewBeforeSeconds: pointer.Int64Ptr(2400),
},
},
APIGroupSuffix: pointer.StringPtr("some.suffix.com"),
AggregatedAPIServerPort: pointer.Int64Ptr(12345),
ImpersonationProxyServerPort: pointer.Int64Ptr(4242),
NamesConfig: NamesConfigSpec{
ServingCertificateSecret: "pinniped-concierge-api-tls-serving-certificate",
CredentialIssuer: "pinniped-config",
APIService: "pinniped-api",
ImpersonationLoadBalancerService: "impersonationLoadBalancerService-value",
ImpersonationClusterIPService: "impersonationClusterIPService-value",
ImpersonationTLSCertificateSecret: "impersonationTLSCertificateSecret-value",
ImpersonationCACertificateSecret: "impersonationCACertificateSecret-value",
ImpersonationSignerSecret: "impersonationSignerSecret-value",
AgentServiceAccount: "agentServiceAccount-value",
},
Labels: map[string]string{
"myLabelKey1": "myLabelValue1",
"myLabelKey2": "myLabelValue2",
},
KubeCertAgentConfig: KubeCertAgentSpec{
NamePrefix: pointer.StringPtr("kube-cert-agent-name-prefix-"),
Image: pointer.StringPtr("kube-cert-agent-image"),
ImagePullSecrets: []string{"kube-cert-agent-image-pull-secret"},
},
LogLevel: func(level plog.LogLevel) *plog.LogLevel { return &level }(plog.LevelDebug),
Log: plog.LogSpec{
Level: plog.LevelDebug,
Format: plog.FormatJSON,
},
Allow override of discovery URL via ConfigMap Signed-off-by: Andrew Keesler <akeesler@vmware.com> - Seems like the next step is to allow override of the CA bundle; I didn't do that here for simplicity of the commit, but seems like it is the right thing to do in the future.
2020-08-03 14:17:11 +00:00
},
},
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
{
name: "invalid log format",
yaml: here.Doc(`
---
names:
servingCertificateSecret: pinniped-concierge-api-tls-serving-certificate
credentialIssuer: pinniped-config
apiService: pinniped-api
impersonationLoadBalancerService: impersonationLoadBalancerService-value
impersonationClusterIPService: impersonationClusterIPService-value
impersonationTLSCertificateSecret: impersonationTLSCertificateSecret-value
impersonationCACertificateSecret: impersonationCACertificateSecret-value
impersonationSignerSecret: impersonationSignerSecret-value
agentServiceAccount: agentServiceAccount-value
log:
level: all
format: snorlax
`),
wantError: "decode yaml: error unmarshaling JSON: while decoding JSON: invalid log format, valid choices are the empty string, json and text",
},
Allow override of discovery URL via ConfigMap Signed-off-by: Andrew Keesler <akeesler@vmware.com> - Seems like the next step is to allow override of the CA bundle; I didn't do that here for simplicity of the commit, but seems like it is the right thing to do in the future.
2020-08-03 14:17:11 +00:00
{
Rename many of resources that are created in Kubernetes by Pinniped New resource naming conventions: - Do not repeat the Kind in the name, e.g. do not call it foo-cluster-role-binding, just call it foo - Names will generally start with a prefix to identify our component, so when a user lists all objects of that kind, they can tell to which component it is related, e.g. `kubectl get configmaps` would list one named "pinniped-config" - It should be possible for an operator to make the word "pinniped" mostly disappear if they choose, by specifying the app_name in values.yaml, to the extent that is practical (but not from APIService names because those are hardcoded in golang) - Each role/clusterrole and its corresponding binding have the same name - Pinniped resource names that must be known by the server golang code are passed to the code at run time via ConfigMap, rather than hardcoded in the golang code. This also allows them to be prepended with the app_name from values.yaml while creating the ConfigMap. - Since the CLI `get-kubeconfig` command cannot guess the name of the CredentialIssuerConfig resource in advance anymore, it lists all CredentialIssuerConfig in the app's namespace and returns an error if there is not exactly one found, and then uses that one regardless of its name
2020-09-18 22:56:50 +00:00
name: "When only the required fields are present, causes other fields to be defaulted",
yaml: here.Doc(`
---
names:
Make tilt work with the supervisor app and add more uninstall testing - Also continue renaming things related to the concierge app - Enhance the uninstall test to also test uninstalling the supervisor and local-user-authenticator apps
2020-10-09 21:25:34 +00:00
servingCertificateSecret: pinniped-concierge-api-tls-serving-certificate
Rename CredentialIssuerConfig to CredentialIssuer. Signed-off-by: Matt Moyer <moyerm@vmware.com>
2020-11-02 21:39:43 +00:00
credentialIssuer: pinniped-config
Rename many of resources that are created in Kubernetes by Pinniped New resource naming conventions: - Do not repeat the Kind in the name, e.g. do not call it foo-cluster-role-binding, just call it foo - Names will generally start with a prefix to identify our component, so when a user lists all objects of that kind, they can tell to which component it is related, e.g. `kubectl get configmaps` would list one named "pinniped-config" - It should be possible for an operator to make the word "pinniped" mostly disappear if they choose, by specifying the app_name in values.yaml, to the extent that is practical (but not from APIService names because those are hardcoded in golang) - Each role/clusterrole and its corresponding binding have the same name - Pinniped resource names that must be known by the server golang code are passed to the code at run time via ConfigMap, rather than hardcoded in the golang code. This also allows them to be prepended with the app_name from values.yaml while creating the ConfigMap. - Since the CLI `get-kubeconfig` command cannot guess the name of the CredentialIssuerConfig resource in advance anymore, it lists all CredentialIssuerConfig in the app's namespace and returns an error if there is not exactly one found, and then uses that one regardless of its name
2020-09-18 22:56:50 +00:00
apiService: pinniped-api
Read the names of the impersonation-related resources from the config They were previously temporarily hardcoded. Now they are set at deploy time via the static ConfigMap in deployment.yaml
2021-03-02 17:31:24 +00:00
impersonationLoadBalancerService: impersonationLoadBalancerService-value
Wire generatedClusterIPServiceName through from NamesConfig
2021-05-20 21:11:35 +00:00
impersonationClusterIPService: impersonationClusterIPService-value
Read the names of the impersonation-related resources from the config They were previously temporarily hardcoded. Now they are set at deploy time via the static ConfigMap in deployment.yaml
2021-03-02 17:31:24 +00:00
impersonationTLSCertificateSecret: impersonationTLSCertificateSecret-value
impersonationCACertificateSecret: impersonationCACertificateSecret-value
Use TokenCredentialRequest instead of base64 token with impersonator To make an impersonation request, first make a TokenCredentialRequest to get a certificate. That cert will either be issued by the Kube API server's CA or by a new CA specific to the impersonator. Either way, you can then make a request to the impersonator and present that client cert for auth and the impersonator will accept it and make the impesonation call on your behalf. The impersonator http handler now borrows some Kube library code to handle request processing. This will allow us to more closely mimic the behavior of a real API server, e.g. the client cert auth will work exactly like the real API server. Signed-off-by: Monis Khan <mok@vmware.com>
2021-03-10 18:30:06 +00:00
impersonationSignerSecret: impersonationSignerSecret-value
Split out kube-cert-agent service account and bindings. Followup on the previous comment to split apart the ServiceAccount of the kube-cert-agent and the main concierge pod. This is a bit cleaner and ensures that in testing our main Concierge pod never requires any privileged permissions. Signed-off-by: Matt Moyer <moyerm@vmware.com>
2021-05-03 21:31:48 +00:00
agentServiceAccount: agentServiceAccount-value
Rename many of resources that are created in Kubernetes by Pinniped New resource naming conventions: - Do not repeat the Kind in the name, e.g. do not call it foo-cluster-role-binding, just call it foo - Names will generally start with a prefix to identify our component, so when a user lists all objects of that kind, they can tell to which component it is related, e.g. `kubectl get configmaps` would list one named "pinniped-config" - It should be possible for an operator to make the word "pinniped" mostly disappear if they choose, by specifying the app_name in values.yaml, to the extent that is practical (but not from APIService names because those are hardcoded in golang) - Each role/clusterrole and its corresponding binding have the same name - Pinniped resource names that must be known by the server golang code are passed to the code at run time via ConfigMap, rather than hardcoded in the golang code. This also allows them to be prepended with the app_name from values.yaml while creating the ConfigMap. - Since the CLI `get-kubeconfig` command cannot guess the name of the CredentialIssuerConfig resource in advance anymore, it lists all CredentialIssuerConfig in the app's namespace and returns an error if there is not exactly one found, and then uses that one regardless of its name
2020-09-18 22:56:50 +00:00
`),
Supervisor controllers apply custom labels to JWKS secrets Signed-off-by: Ryan Richard <richardry@vmware.com>
2020-10-15 19:40:56 +00:00
wantConfig: &Config{
DiscoveryInfo: DiscoveryInfoSpec{
Allow override of discovery URL via ConfigMap Signed-off-by: Andrew Keesler <akeesler@vmware.com> - Seems like the next step is to allow override of the CA bundle; I didn't do that here for simplicity of the commit, but seems like it is the right thing to do in the future.
2020-08-03 14:17:11 +00:00
URL: nil,
},
Add impersonationProxyServerPort to the Concierge's static ConfigMap - Used to determine on which port the impersonation proxy will bind - Defaults to 8444, which is the old hard-coded port value - Allow the port number to be configured to any value within the range 1024 to 65535 - This commit does not include adding new config knobs to the ytt values file, so while it is possible to change this port without needing to recompile, it is not convenient
2021-11-17 21:27:59 +00:00
APIGroupSuffix: pointer.StringPtr("pinniped.dev"),
AggregatedAPIServerPort: pointer.Int64Ptr(10250),
ImpersonationProxyServerPort: pointer.Int64Ptr(8444),
Supervisor controllers apply custom labels to JWKS secrets Signed-off-by: Ryan Richard <richardry@vmware.com>
2020-10-15 19:40:56 +00:00
APIConfig: APIConfigSpec{
ServingCertificateConfig: ServingCertificateConfigSpec{
Missed a usage of int64Ptr in previous commit
2021-05-12 21:00:26 +00:00
DurationSeconds: pointer.Int64Ptr(60 * 60 * 24 * 365), // about a year
RenewBeforeSeconds: pointer.Int64Ptr(60 * 60 * 24 * 30 * 9), // about 9 months
Use duration and renewBefore to control API cert rotation These configuration knobs are much more human-understandable than the previous percentage-based threshold flag. We now allow users to set the lifetime of the serving cert via a ConfigMap. Previously this was hardcoded to 1 year. Signed-off-by: Andrew Keesler <akeesler@vmware.com>
2020-08-20 19:17:18 +00:00
},
},
Supervisor controllers apply custom labels to JWKS secrets Signed-off-by: Ryan Richard <richardry@vmware.com>
2020-10-15 19:40:56 +00:00
NamesConfig: NamesConfigSpec{
Read the names of the impersonation-related resources from the config They were previously temporarily hardcoded. Now they are set at deploy time via the static ConfigMap in deployment.yaml
2021-03-02 17:31:24 +00:00
ServingCertificateSecret: "pinniped-concierge-api-tls-serving-certificate",
CredentialIssuer: "pinniped-config",
APIService: "pinniped-api",
ImpersonationLoadBalancerService: "impersonationLoadBalancerService-value",
Wire generatedClusterIPServiceName through from NamesConfig
2021-05-20 21:11:35 +00:00
ImpersonationClusterIPService: "impersonationClusterIPService-value",
Read the names of the impersonation-related resources from the config They were previously temporarily hardcoded. Now they are set at deploy time via the static ConfigMap in deployment.yaml
2021-03-02 17:31:24 +00:00
ImpersonationTLSCertificateSecret: "impersonationTLSCertificateSecret-value",
ImpersonationCACertificateSecret: "impersonationCACertificateSecret-value",
Use TokenCredentialRequest instead of base64 token with impersonator To make an impersonation request, first make a TokenCredentialRequest to get a certificate. That cert will either be issued by the Kube API server's CA or by a new CA specific to the impersonator. Either way, you can then make a request to the impersonator and present that client cert for auth and the impersonator will accept it and make the impesonation call on your behalf. The impersonator http handler now borrows some Kube library code to handle request processing. This will allow us to more closely mimic the behavior of a real API server, e.g. the client cert auth will work exactly like the real API server. Signed-off-by: Monis Khan <mok@vmware.com>
2021-03-10 18:30:06 +00:00
ImpersonationSignerSecret: "impersonationSignerSecret-value",
Split out kube-cert-agent service account and bindings. Followup on the previous comment to split apart the ServiceAccount of the kube-cert-agent and the main concierge pod. This is a bit cleaner and ensures that in testing our main Concierge pod never requires any privileged permissions. Signed-off-by: Matt Moyer <moyerm@vmware.com>
2021-05-03 21:31:48 +00:00
AgentServiceAccount: "agentServiceAccount-value",
Rename many of resources that are created in Kubernetes by Pinniped New resource naming conventions: - Do not repeat the Kind in the name, e.g. do not call it foo-cluster-role-binding, just call it foo - Names will generally start with a prefix to identify our component, so when a user lists all objects of that kind, they can tell to which component it is related, e.g. `kubectl get configmaps` would list one named "pinniped-config" - It should be possible for an operator to make the word "pinniped" mostly disappear if they choose, by specifying the app_name in values.yaml, to the extent that is practical (but not from APIService names because those are hardcoded in golang) - Each role/clusterrole and its corresponding binding have the same name - Pinniped resource names that must be known by the server golang code are passed to the code at run time via ConfigMap, rather than hardcoded in the golang code. This also allows them to be prepended with the app_name from values.yaml while creating the ConfigMap. - Since the CLI `get-kubeconfig` command cannot guess the name of the CredentialIssuerConfig resource in advance anymore, it lists all CredentialIssuerConfig in the app's namespace and returns an error if there is not exactly one found, and then uses that one regardless of its name
2020-09-18 22:56:50 +00:00
},
Concierge controllers add labels to all created resources
2020-10-15 17:14:23 +00:00
Labels: map[string]string{},
Supervisor controllers apply custom labels to JWKS secrets Signed-off-by: Ryan Richard <richardry@vmware.com>
2020-10-15 19:40:56 +00:00
KubeCertAgentConfig: KubeCertAgentSpec{
Replace all usages of strPtr() with pointer.StringPtr()
2021-05-12 20:20:00 +00:00
NamePrefix: pointer.StringPtr("pinniped-kube-cert-agent-"),
Image: pointer.StringPtr("debian:latest"),
Add kube-cert-agent controller for getting kube API keypair
2020-09-21 18:16:14 +00:00
},
Allow override of discovery URL via ConfigMap Signed-off-by: Andrew Keesler <akeesler@vmware.com> - Seems like the next step is to allow override of the CA bundle; I didn't do that here for simplicity of the commit, but seems like it is the right thing to do in the future.
2020-08-03 14:17:11 +00:00
},
Define initial config file format - Users may want to consume pkg/config to generate configuration files. - This also involved putting config-related utilities in the config package for ease of consumption. - We did not add in versioning into the Config type for now...this is something we will likely do in the future, but it is not deemed necessary this early in the project. - The config file format tries to follow the patterns of Kube. One such example of this is requiring the use of base64-encoded CA bundle PEM bytes instead of a file path. This also slightly simplifies the config file handling because we don't have to 1) read in a file or 2) deal with the error case of the file not being there. - The webhook code from k8s.io/apiserver is really exactly what we want here. If this dependency gets too burdensome, we can always drop it, but the pros outweigh the cons at the moment. - Writing out a kubeconfig to disk to configure the webhook is a little janky, but hopefully this won't hurt performance too much in the year 2020. - Also bonus: call the right *Serve*() function when starting our servers. Signed-off-by: Andrew Keesler <akeesler@vmware.com>
2020-07-14 15:50:14 +00:00
},
Use duration and renewBefore to control API cert rotation These configuration knobs are much more human-understandable than the previous percentage-based threshold flag. We now allow users to set the lifetime of the serving cert via a ConfigMap. Previously this was hardcoded to 1 year. Signed-off-by: Andrew Keesler <akeesler@vmware.com>
2020-08-20 19:17:18 +00:00
{
Read the names of the impersonation-related resources from the config They were previously temporarily hardcoded. Now they are set at deploy time via the static ConfigMap in deployment.yaml
2021-03-02 17:31:24 +00:00
name: "Empty",
yaml: here.Doc(``),
wantError: "validate names: missing required names: servingCertificateSecret, credentialIssuer, " +
Remove references to impersonationConfigMap. Signed-off-by: Margo Crawford <margaretc@vmware.com>
2021-05-26 20:24:59 +00:00
"apiService, impersonationLoadBalancerService, " +
Wire generatedClusterIPServiceName through from NamesConfig
2021-05-20 21:11:35 +00:00
"impersonationClusterIPService, impersonationTLSCertificateSecret, impersonationCACertificateSecret, " +
Split out kube-cert-agent service account and bindings. Followup on the previous comment to split apart the ServiceAccount of the kube-cert-agent and the main concierge pod. This is a bit cleaner and ensures that in testing our main Concierge pod never requires any privileged permissions. Signed-off-by: Matt Moyer <moyerm@vmware.com>
2021-05-03 21:31:48 +00:00
"impersonationSignerSecret, agentServiceAccount",
Rename many of resources that are created in Kubernetes by Pinniped New resource naming conventions: - Do not repeat the Kind in the name, e.g. do not call it foo-cluster-role-binding, just call it foo - Names will generally start with a prefix to identify our component, so when a user lists all objects of that kind, they can tell to which component it is related, e.g. `kubectl get configmaps` would list one named "pinniped-config" - It should be possible for an operator to make the word "pinniped" mostly disappear if they choose, by specifying the app_name in values.yaml, to the extent that is practical (but not from APIService names because those are hardcoded in golang) - Each role/clusterrole and its corresponding binding have the same name - Pinniped resource names that must be known by the server golang code are passed to the code at run time via ConfigMap, rather than hardcoded in the golang code. This also allows them to be prepended with the app_name from values.yaml while creating the ConfigMap. - Since the CLI `get-kubeconfig` command cannot guess the name of the CredentialIssuerConfig resource in advance anymore, it lists all CredentialIssuerConfig in the app's namespace and returns an error if there is not exactly one found, and then uses that one regardless of its name
2020-09-18 22:56:50 +00:00
},
{
name: "Missing apiService name",
yaml: here.Doc(`
---
names:
Make tilt work with the supervisor app and add more uninstall testing - Also continue renaming things related to the concierge app - Enhance the uninstall test to also test uninstalling the supervisor and local-user-authenticator apps
2020-10-09 21:25:34 +00:00
servingCertificateSecret: pinniped-concierge-api-tls-serving-certificate
Rename CredentialIssuerConfig to CredentialIssuer. Signed-off-by: Matt Moyer <moyerm@vmware.com>
2020-11-02 21:39:43 +00:00
credentialIssuer: pinniped-config
Read the names of the impersonation-related resources from the config They were previously temporarily hardcoded. Now they are set at deploy time via the static ConfigMap in deployment.yaml
2021-03-02 17:31:24 +00:00
impersonationLoadBalancerService: impersonationLoadBalancerService-value
Wire generatedClusterIPServiceName through from NamesConfig
2021-05-20 21:11:35 +00:00
impersonationClusterIPService: impersonationClusterIPService-value
Read the names of the impersonation-related resources from the config They were previously temporarily hardcoded. Now they are set at deploy time via the static ConfigMap in deployment.yaml
2021-03-02 17:31:24 +00:00
impersonationTLSCertificateSecret: impersonationTLSCertificateSecret-value
impersonationCACertificateSecret: impersonationCACertificateSecret-value
Use TokenCredentialRequest instead of base64 token with impersonator To make an impersonation request, first make a TokenCredentialRequest to get a certificate. That cert will either be issued by the Kube API server's CA or by a new CA specific to the impersonator. Either way, you can then make a request to the impersonator and present that client cert for auth and the impersonator will accept it and make the impesonation call on your behalf. The impersonator http handler now borrows some Kube library code to handle request processing. This will allow us to more closely mimic the behavior of a real API server, e.g. the client cert auth will work exactly like the real API server. Signed-off-by: Monis Khan <mok@vmware.com>
2021-03-10 18:30:06 +00:00
impersonationSignerSecret: impersonationSignerSecret-value
Split out kube-cert-agent service account and bindings. Followup on the previous comment to split apart the ServiceAccount of the kube-cert-agent and the main concierge pod. This is a bit cleaner and ensures that in testing our main Concierge pod never requires any privileged permissions. Signed-off-by: Matt Moyer <moyerm@vmware.com>
2021-05-03 21:31:48 +00:00
agentServiceAccount: agentServiceAccount-value
Rename many of resources that are created in Kubernetes by Pinniped New resource naming conventions: - Do not repeat the Kind in the name, e.g. do not call it foo-cluster-role-binding, just call it foo - Names will generally start with a prefix to identify our component, so when a user lists all objects of that kind, they can tell to which component it is related, e.g. `kubectl get configmaps` would list one named "pinniped-config" - It should be possible for an operator to make the word "pinniped" mostly disappear if they choose, by specifying the app_name in values.yaml, to the extent that is practical (but not from APIService names because those are hardcoded in golang) - Each role/clusterrole and its corresponding binding have the same name - Pinniped resource names that must be known by the server golang code are passed to the code at run time via ConfigMap, rather than hardcoded in the golang code. This also allows them to be prepended with the app_name from values.yaml while creating the ConfigMap. - Since the CLI `get-kubeconfig` command cannot guess the name of the CredentialIssuerConfig resource in advance anymore, it lists all CredentialIssuerConfig in the app's namespace and returns an error if there is not exactly one found, and then uses that one regardless of its name
2020-09-18 22:56:50 +00:00
`),
wantError: "validate names: missing required names: apiService",
},
{
Rename CredentialIssuerConfig to CredentialIssuer. Signed-off-by: Matt Moyer <moyerm@vmware.com>
2020-11-02 21:39:43 +00:00
name: "Missing credentialIssuer name",
Rename many of resources that are created in Kubernetes by Pinniped New resource naming conventions: - Do not repeat the Kind in the name, e.g. do not call it foo-cluster-role-binding, just call it foo - Names will generally start with a prefix to identify our component, so when a user lists all objects of that kind, they can tell to which component it is related, e.g. `kubectl get configmaps` would list one named "pinniped-config" - It should be possible for an operator to make the word "pinniped" mostly disappear if they choose, by specifying the app_name in values.yaml, to the extent that is practical (but not from APIService names because those are hardcoded in golang) - Each role/clusterrole and its corresponding binding have the same name - Pinniped resource names that must be known by the server golang code are passed to the code at run time via ConfigMap, rather than hardcoded in the golang code. This also allows them to be prepended with the app_name from values.yaml while creating the ConfigMap. - Since the CLI `get-kubeconfig` command cannot guess the name of the CredentialIssuerConfig resource in advance anymore, it lists all CredentialIssuerConfig in the app's namespace and returns an error if there is not exactly one found, and then uses that one regardless of its name
2020-09-18 22:56:50 +00:00
yaml: here.Doc(`
---
names:
Make tilt work with the supervisor app and add more uninstall testing - Also continue renaming things related to the concierge app - Enhance the uninstall test to also test uninstalling the supervisor and local-user-authenticator apps
2020-10-09 21:25:34 +00:00
servingCertificateSecret: pinniped-concierge-api-tls-serving-certificate
Rename many of resources that are created in Kubernetes by Pinniped New resource naming conventions: - Do not repeat the Kind in the name, e.g. do not call it foo-cluster-role-binding, just call it foo - Names will generally start with a prefix to identify our component, so when a user lists all objects of that kind, they can tell to which component it is related, e.g. `kubectl get configmaps` would list one named "pinniped-config" - It should be possible for an operator to make the word "pinniped" mostly disappear if they choose, by specifying the app_name in values.yaml, to the extent that is practical (but not from APIService names because those are hardcoded in golang) - Each role/clusterrole and its corresponding binding have the same name - Pinniped resource names that must be known by the server golang code are passed to the code at run time via ConfigMap, rather than hardcoded in the golang code. This also allows them to be prepended with the app_name from values.yaml while creating the ConfigMap. - Since the CLI `get-kubeconfig` command cannot guess the name of the CredentialIssuerConfig resource in advance anymore, it lists all CredentialIssuerConfig in the app's namespace and returns an error if there is not exactly one found, and then uses that one regardless of its name
2020-09-18 22:56:50 +00:00
apiService: pinniped-api
Read the names of the impersonation-related resources from the config They were previously temporarily hardcoded. Now they are set at deploy time via the static ConfigMap in deployment.yaml
2021-03-02 17:31:24 +00:00
impersonationLoadBalancerService: impersonationLoadBalancerService-value
Wire generatedClusterIPServiceName through from NamesConfig
2021-05-20 21:11:35 +00:00
impersonationClusterIPService: impersonationClusterIPService-value
Read the names of the impersonation-related resources from the config They were previously temporarily hardcoded. Now they are set at deploy time via the static ConfigMap in deployment.yaml
2021-03-02 17:31:24 +00:00
impersonationTLSCertificateSecret: impersonationTLSCertificateSecret-value
impersonationCACertificateSecret: impersonationCACertificateSecret-value
Use TokenCredentialRequest instead of base64 token with impersonator To make an impersonation request, first make a TokenCredentialRequest to get a certificate. That cert will either be issued by the Kube API server's CA or by a new CA specific to the impersonator. Either way, you can then make a request to the impersonator and present that client cert for auth and the impersonator will accept it and make the impesonation call on your behalf. The impersonator http handler now borrows some Kube library code to handle request processing. This will allow us to more closely mimic the behavior of a real API server, e.g. the client cert auth will work exactly like the real API server. Signed-off-by: Monis Khan <mok@vmware.com>
2021-03-10 18:30:06 +00:00
impersonationSignerSecret: impersonationSignerSecret-value
Split out kube-cert-agent service account and bindings. Followup on the previous comment to split apart the ServiceAccount of the kube-cert-agent and the main concierge pod. This is a bit cleaner and ensures that in testing our main Concierge pod never requires any privileged permissions. Signed-off-by: Matt Moyer <moyerm@vmware.com>
2021-05-03 21:31:48 +00:00
agentServiceAccount: agentServiceAccount-value
Rename many of resources that are created in Kubernetes by Pinniped New resource naming conventions: - Do not repeat the Kind in the name, e.g. do not call it foo-cluster-role-binding, just call it foo - Names will generally start with a prefix to identify our component, so when a user lists all objects of that kind, they can tell to which component it is related, e.g. `kubectl get configmaps` would list one named "pinniped-config" - It should be possible for an operator to make the word "pinniped" mostly disappear if they choose, by specifying the app_name in values.yaml, to the extent that is practical (but not from APIService names because those are hardcoded in golang) - Each role/clusterrole and its corresponding binding have the same name - Pinniped resource names that must be known by the server golang code are passed to the code at run time via ConfigMap, rather than hardcoded in the golang code. This also allows them to be prepended with the app_name from values.yaml while creating the ConfigMap. - Since the CLI `get-kubeconfig` command cannot guess the name of the CredentialIssuerConfig resource in advance anymore, it lists all CredentialIssuerConfig in the app's namespace and returns an error if there is not exactly one found, and then uses that one regardless of its name
2020-09-18 22:56:50 +00:00
`),
Rename CredentialIssuerConfig to CredentialIssuer. Signed-off-by: Matt Moyer <moyerm@vmware.com>
2020-11-02 21:39:43 +00:00
wantError: "validate names: missing required names: credentialIssuer",
Rename many of resources that are created in Kubernetes by Pinniped New resource naming conventions: - Do not repeat the Kind in the name, e.g. do not call it foo-cluster-role-binding, just call it foo - Names will generally start with a prefix to identify our component, so when a user lists all objects of that kind, they can tell to which component it is related, e.g. `kubectl get configmaps` would list one named "pinniped-config" - It should be possible for an operator to make the word "pinniped" mostly disappear if they choose, by specifying the app_name in values.yaml, to the extent that is practical (but not from APIService names because those are hardcoded in golang) - Each role/clusterrole and its corresponding binding have the same name - Pinniped resource names that must be known by the server golang code are passed to the code at run time via ConfigMap, rather than hardcoded in the golang code. This also allows them to be prepended with the app_name from values.yaml while creating the ConfigMap. - Since the CLI `get-kubeconfig` command cannot guess the name of the CredentialIssuerConfig resource in advance anymore, it lists all CredentialIssuerConfig in the app's namespace and returns an error if there is not exactly one found, and then uses that one regardless of its name
2020-09-18 22:56:50 +00:00
},
{
name: "Missing servingCertificateSecret name",
yaml: here.Doc(`
---
names:
Rename CredentialIssuerConfig to CredentialIssuer. Signed-off-by: Matt Moyer <moyerm@vmware.com>
2020-11-02 21:39:43 +00:00
credentialIssuer: pinniped-config
Rename many of resources that are created in Kubernetes by Pinniped New resource naming conventions: - Do not repeat the Kind in the name, e.g. do not call it foo-cluster-role-binding, just call it foo - Names will generally start with a prefix to identify our component, so when a user lists all objects of that kind, they can tell to which component it is related, e.g. `kubectl get configmaps` would list one named "pinniped-config" - It should be possible for an operator to make the word "pinniped" mostly disappear if they choose, by specifying the app_name in values.yaml, to the extent that is practical (but not from APIService names because those are hardcoded in golang) - Each role/clusterrole and its corresponding binding have the same name - Pinniped resource names that must be known by the server golang code are passed to the code at run time via ConfigMap, rather than hardcoded in the golang code. This also allows them to be prepended with the app_name from values.yaml while creating the ConfigMap. - Since the CLI `get-kubeconfig` command cannot guess the name of the CredentialIssuerConfig resource in advance anymore, it lists all CredentialIssuerConfig in the app's namespace and returns an error if there is not exactly one found, and then uses that one regardless of its name
2020-09-18 22:56:50 +00:00
apiService: pinniped-api
Read the names of the impersonation-related resources from the config They were previously temporarily hardcoded. Now they are set at deploy time via the static ConfigMap in deployment.yaml
2021-03-02 17:31:24 +00:00
impersonationLoadBalancerService: impersonationLoadBalancerService-value
Wire generatedClusterIPServiceName through from NamesConfig
2021-05-20 21:11:35 +00:00
impersonationClusterIPService: impersonationClusterIPService-value
Read the names of the impersonation-related resources from the config They were previously temporarily hardcoded. Now they are set at deploy time via the static ConfigMap in deployment.yaml
2021-03-02 17:31:24 +00:00
impersonationTLSCertificateSecret: impersonationTLSCertificateSecret-value
impersonationCACertificateSecret: impersonationCACertificateSecret-value
Use TokenCredentialRequest instead of base64 token with impersonator To make an impersonation request, first make a TokenCredentialRequest to get a certificate. That cert will either be issued by the Kube API server's CA or by a new CA specific to the impersonator. Either way, you can then make a request to the impersonator and present that client cert for auth and the impersonator will accept it and make the impesonation call on your behalf. The impersonator http handler now borrows some Kube library code to handle request processing. This will allow us to more closely mimic the behavior of a real API server, e.g. the client cert auth will work exactly like the real API server. Signed-off-by: Monis Khan <mok@vmware.com>
2021-03-10 18:30:06 +00:00
impersonationSignerSecret: impersonationSignerSecret-value
Split out kube-cert-agent service account and bindings. Followup on the previous comment to split apart the ServiceAccount of the kube-cert-agent and the main concierge pod. This is a bit cleaner and ensures that in testing our main Concierge pod never requires any privileged permissions. Signed-off-by: Matt Moyer <moyerm@vmware.com>
2021-05-03 21:31:48 +00:00
agentServiceAccount: agentServiceAccount-value
Rename many of resources that are created in Kubernetes by Pinniped New resource naming conventions: - Do not repeat the Kind in the name, e.g. do not call it foo-cluster-role-binding, just call it foo - Names will generally start with a prefix to identify our component, so when a user lists all objects of that kind, they can tell to which component it is related, e.g. `kubectl get configmaps` would list one named "pinniped-config" - It should be possible for an operator to make the word "pinniped" mostly disappear if they choose, by specifying the app_name in values.yaml, to the extent that is practical (but not from APIService names because those are hardcoded in golang) - Each role/clusterrole and its corresponding binding have the same name - Pinniped resource names that must be known by the server golang code are passed to the code at run time via ConfigMap, rather than hardcoded in the golang code. This also allows them to be prepended with the app_name from values.yaml while creating the ConfigMap. - Since the CLI `get-kubeconfig` command cannot guess the name of the CredentialIssuerConfig resource in advance anymore, it lists all CredentialIssuerConfig in the app's namespace and returns an error if there is not exactly one found, and then uses that one regardless of its name
2020-09-18 22:56:50 +00:00
`),
wantError: "validate names: missing required names: servingCertificateSecret",
},
Read the names of the impersonation-related resources from the config They were previously temporarily hardcoded. Now they are set at deploy time via the static ConfigMap in deployment.yaml
2021-03-02 17:31:24 +00:00
{
name: "Missing impersonationLoadBalancerService name",
yaml: here.Doc(`
---
names:
servingCertificateSecret: pinniped-concierge-api-tls-serving-certificate
credentialIssuer: pinniped-config
apiService: pinniped-api
Wire generatedClusterIPServiceName through from NamesConfig
2021-05-20 21:11:35 +00:00
impersonationClusterIPService: impersonationClusterIPService-value
Read the names of the impersonation-related resources from the config They were previously temporarily hardcoded. Now they are set at deploy time via the static ConfigMap in deployment.yaml
2021-03-02 17:31:24 +00:00
impersonationTLSCertificateSecret: impersonationTLSCertificateSecret-value
impersonationCACertificateSecret: impersonationCACertificateSecret-value
Use TokenCredentialRequest instead of base64 token with impersonator To make an impersonation request, first make a TokenCredentialRequest to get a certificate. That cert will either be issued by the Kube API server's CA or by a new CA specific to the impersonator. Either way, you can then make a request to the impersonator and present that client cert for auth and the impersonator will accept it and make the impesonation call on your behalf. The impersonator http handler now borrows some Kube library code to handle request processing. This will allow us to more closely mimic the behavior of a real API server, e.g. the client cert auth will work exactly like the real API server. Signed-off-by: Monis Khan <mok@vmware.com>
2021-03-10 18:30:06 +00:00
impersonationSignerSecret: impersonationSignerSecret-value
Split out kube-cert-agent service account and bindings. Followup on the previous comment to split apart the ServiceAccount of the kube-cert-agent and the main concierge pod. This is a bit cleaner and ensures that in testing our main Concierge pod never requires any privileged permissions. Signed-off-by: Matt Moyer <moyerm@vmware.com>
2021-05-03 21:31:48 +00:00
agentServiceAccount: agentServiceAccount-value
Read the names of the impersonation-related resources from the config They were previously temporarily hardcoded. Now they are set at deploy time via the static ConfigMap in deployment.yaml
2021-03-02 17:31:24 +00:00
`),
wantError: "validate names: missing required names: impersonationLoadBalancerService",
},
Wire generatedClusterIPServiceName through from NamesConfig
2021-05-20 21:11:35 +00:00
{
name: "Missing impersonationClusterIPService name",
yaml: here.Doc(`
---
names:
servingCertificateSecret: pinniped-concierge-api-tls-serving-certificate
credentialIssuer: pinniped-config
apiService: pinniped-api
impersonationLoadBalancerService: impersonationLoadBalancerService-value
impersonationTLSCertificateSecret: impersonationTLSCertificateSecret-value
impersonationCACertificateSecret: impersonationCACertificateSecret-value
impersonationSignerSecret: impersonationSignerSecret-value
agentServiceAccount: agentServiceAccount-value
`),
wantError: "validate names: missing required names: impersonationClusterIPService",
},
Read the names of the impersonation-related resources from the config They were previously temporarily hardcoded. Now they are set at deploy time via the static ConfigMap in deployment.yaml
2021-03-02 17:31:24 +00:00
{
name: "Missing impersonationTLSCertificateSecret name",
yaml: here.Doc(`
---
names:
servingCertificateSecret: pinniped-concierge-api-tls-serving-certificate
credentialIssuer: pinniped-config
apiService: pinniped-api
impersonationLoadBalancerService: impersonationLoadBalancerService-value
Wire generatedClusterIPServiceName through from NamesConfig
2021-05-20 21:11:35 +00:00
impersonationClusterIPService: impersonationClusterIPService-value
Read the names of the impersonation-related resources from the config They were previously temporarily hardcoded. Now they are set at deploy time via the static ConfigMap in deployment.yaml
2021-03-02 17:31:24 +00:00
impersonationCACertificateSecret: impersonationCACertificateSecret-value
Use TokenCredentialRequest instead of base64 token with impersonator To make an impersonation request, first make a TokenCredentialRequest to get a certificate. That cert will either be issued by the Kube API server's CA or by a new CA specific to the impersonator. Either way, you can then make a request to the impersonator and present that client cert for auth and the impersonator will accept it and make the impesonation call on your behalf. The impersonator http handler now borrows some Kube library code to handle request processing. This will allow us to more closely mimic the behavior of a real API server, e.g. the client cert auth will work exactly like the real API server. Signed-off-by: Monis Khan <mok@vmware.com>
2021-03-10 18:30:06 +00:00
impersonationSignerSecret: impersonationSignerSecret-value
Split out kube-cert-agent service account and bindings. Followup on the previous comment to split apart the ServiceAccount of the kube-cert-agent and the main concierge pod. This is a bit cleaner and ensures that in testing our main Concierge pod never requires any privileged permissions. Signed-off-by: Matt Moyer <moyerm@vmware.com>
2021-05-03 21:31:48 +00:00
agentServiceAccount: agentServiceAccount-value
Read the names of the impersonation-related resources from the config They were previously temporarily hardcoded. Now they are set at deploy time via the static ConfigMap in deployment.yaml
2021-03-02 17:31:24 +00:00
`),
wantError: "validate names: missing required names: impersonationTLSCertificateSecret",
},
{
name: "Missing impersonationCACertificateSecret name",
yaml: here.Doc(`
---
names:
servingCertificateSecret: pinniped-concierge-api-tls-serving-certificate
credentialIssuer: pinniped-config
apiService: pinniped-api
impersonationLoadBalancerService: impersonationLoadBalancerService-value
Wire generatedClusterIPServiceName through from NamesConfig
2021-05-20 21:11:35 +00:00
impersonationClusterIPService: impersonationClusterIPService-value
Read the names of the impersonation-related resources from the config They were previously temporarily hardcoded. Now they are set at deploy time via the static ConfigMap in deployment.yaml
2021-03-02 17:31:24 +00:00
impersonationTLSCertificateSecret: impersonationTLSCertificateSecret-value
Use TokenCredentialRequest instead of base64 token with impersonator To make an impersonation request, first make a TokenCredentialRequest to get a certificate. That cert will either be issued by the Kube API server's CA or by a new CA specific to the impersonator. Either way, you can then make a request to the impersonator and present that client cert for auth and the impersonator will accept it and make the impesonation call on your behalf. The impersonator http handler now borrows some Kube library code to handle request processing. This will allow us to more closely mimic the behavior of a real API server, e.g. the client cert auth will work exactly like the real API server. Signed-off-by: Monis Khan <mok@vmware.com>
2021-03-10 18:30:06 +00:00
impersonationSignerSecret: impersonationSignerSecret-value
Split out kube-cert-agent service account and bindings. Followup on the previous comment to split apart the ServiceAccount of the kube-cert-agent and the main concierge pod. This is a bit cleaner and ensures that in testing our main Concierge pod never requires any privileged permissions. Signed-off-by: Matt Moyer <moyerm@vmware.com>
2021-05-03 21:31:48 +00:00
agentServiceAccount: agentServiceAccount-value
Read the names of the impersonation-related resources from the config They were previously temporarily hardcoded. Now they are set at deploy time via the static ConfigMap in deployment.yaml
2021-03-02 17:31:24 +00:00
`),
wantError: "validate names: missing required names: impersonationCACertificateSecret",
},
Use TokenCredentialRequest instead of base64 token with impersonator To make an impersonation request, first make a TokenCredentialRequest to get a certificate. That cert will either be issued by the Kube API server's CA or by a new CA specific to the impersonator. Either way, you can then make a request to the impersonator and present that client cert for auth and the impersonator will accept it and make the impesonation call on your behalf. The impersonator http handler now borrows some Kube library code to handle request processing. This will allow us to more closely mimic the behavior of a real API server, e.g. the client cert auth will work exactly like the real API server. Signed-off-by: Monis Khan <mok@vmware.com>
2021-03-10 18:30:06 +00:00
{
name: "Missing impersonationSignerSecret name",
yaml: here.Doc(`
---
names:
servingCertificateSecret: pinniped-concierge-api-tls-serving-certificate
credentialIssuer: pinniped-config
apiService: pinniped-api
impersonationLoadBalancerService: impersonationLoadBalancerService-value
Wire generatedClusterIPServiceName through from NamesConfig
2021-05-20 21:11:35 +00:00
impersonationClusterIPService: impersonationClusterIPService-value
Use TokenCredentialRequest instead of base64 token with impersonator To make an impersonation request, first make a TokenCredentialRequest to get a certificate. That cert will either be issued by the Kube API server's CA or by a new CA specific to the impersonator. Either way, you can then make a request to the impersonator and present that client cert for auth and the impersonator will accept it and make the impesonation call on your behalf. The impersonator http handler now borrows some Kube library code to handle request processing. This will allow us to more closely mimic the behavior of a real API server, e.g. the client cert auth will work exactly like the real API server. Signed-off-by: Monis Khan <mok@vmware.com>
2021-03-10 18:30:06 +00:00
impersonationTLSCertificateSecret: impersonationTLSCertificateSecret-value
impersonationCACertificateSecret: impersonationCACertificateSecret-value
Split out kube-cert-agent service account and bindings. Followup on the previous comment to split apart the ServiceAccount of the kube-cert-agent and the main concierge pod. This is a bit cleaner and ensures that in testing our main Concierge pod never requires any privileged permissions. Signed-off-by: Matt Moyer <moyerm@vmware.com>
2021-05-03 21:31:48 +00:00
agentServiceAccount: agentServiceAccount-value
Use TokenCredentialRequest instead of base64 token with impersonator To make an impersonation request, first make a TokenCredentialRequest to get a certificate. That cert will either be issued by the Kube API server's CA or by a new CA specific to the impersonator. Either way, you can then make a request to the impersonator and present that client cert for auth and the impersonator will accept it and make the impesonation call on your behalf. The impersonator http handler now borrows some Kube library code to handle request processing. This will allow us to more closely mimic the behavior of a real API server, e.g. the client cert auth will work exactly like the real API server. Signed-off-by: Monis Khan <mok@vmware.com>
2021-03-10 18:30:06 +00:00
`),
wantError: "validate names: missing required names: impersonationSignerSecret",
},
Read the names of the impersonation-related resources from the config They were previously temporarily hardcoded. Now they are set at deploy time via the static ConfigMap in deployment.yaml
2021-03-02 17:31:24 +00:00
{
name: "Missing several required names",
yaml: here.Doc(`
---
names:
servingCertificateSecret: pinniped-concierge-api-tls-serving-certificate
credentialIssuer: pinniped-config
apiService: pinniped-api
impersonationLoadBalancerService: impersonationLoadBalancerService-value
Wire generatedClusterIPServiceName through from NamesConfig
2021-05-20 21:11:35 +00:00
impersonationClusterIPService: impersonationClusterIPService-value
Use TokenCredentialRequest instead of base64 token with impersonator To make an impersonation request, first make a TokenCredentialRequest to get a certificate. That cert will either be issued by the Kube API server's CA or by a new CA specific to the impersonator. Either way, you can then make a request to the impersonator and present that client cert for auth and the impersonator will accept it and make the impesonation call on your behalf. The impersonator http handler now borrows some Kube library code to handle request processing. This will allow us to more closely mimic the behavior of a real API server, e.g. the client cert auth will work exactly like the real API server. Signed-off-by: Monis Khan <mok@vmware.com>
2021-03-10 18:30:06 +00:00
impersonationSignerSecret: impersonationSignerSecret-value
Split out kube-cert-agent service account and bindings. Followup on the previous comment to split apart the ServiceAccount of the kube-cert-agent and the main concierge pod. This is a bit cleaner and ensures that in testing our main Concierge pod never requires any privileged permissions. Signed-off-by: Matt Moyer <moyerm@vmware.com>
2021-05-03 21:31:48 +00:00
agentServiceAccount: agentServiceAccount-value
Read the names of the impersonation-related resources from the config They were previously temporarily hardcoded. Now they are set at deploy time via the static ConfigMap in deployment.yaml
2021-03-02 17:31:24 +00:00
`),
Remove references to impersonationConfigMap. Signed-off-by: Margo Crawford <margaretc@vmware.com>
2021-05-26 20:24:59 +00:00
wantError: "validate names: missing required names: " +
Read the names of the impersonation-related resources from the config They were previously temporarily hardcoded. Now they are set at deploy time via the static ConfigMap in deployment.yaml
2021-03-02 17:31:24 +00:00
"impersonationTLSCertificateSecret, impersonationCACertificateSecret",
},
Rename many of resources that are created in Kubernetes by Pinniped New resource naming conventions: - Do not repeat the Kind in the name, e.g. do not call it foo-cluster-role-binding, just call it foo - Names will generally start with a prefix to identify our component, so when a user lists all objects of that kind, they can tell to which component it is related, e.g. `kubectl get configmaps` would list one named "pinniped-config" - It should be possible for an operator to make the word "pinniped" mostly disappear if they choose, by specifying the app_name in values.yaml, to the extent that is practical (but not from APIService names because those are hardcoded in golang) - Each role/clusterrole and its corresponding binding have the same name - Pinniped resource names that must be known by the server golang code are passed to the code at run time via ConfigMap, rather than hardcoded in the golang code. This also allows them to be prepended with the app_name from values.yaml while creating the ConfigMap. - Since the CLI `get-kubeconfig` command cannot guess the name of the CredentialIssuerConfig resource in advance anymore, it lists all CredentialIssuerConfig in the app's namespace and returns an error if there is not exactly one found, and then uses that one regardless of its name
2020-09-18 22:56:50 +00:00
{
name: "InvalidDurationRenewBefore",
yaml: here.Doc(`
---
api:
servingCertificate:
durationSeconds: 2400
renewBeforeSeconds: 3600
names:
Make tilt work with the supervisor app and add more uninstall testing - Also continue renaming things related to the concierge app - Enhance the uninstall test to also test uninstalling the supervisor and local-user-authenticator apps
2020-10-09 21:25:34 +00:00
servingCertificateSecret: pinniped-concierge-api-tls-serving-certificate
Rename CredentialIssuerConfig to CredentialIssuer. Signed-off-by: Matt Moyer <moyerm@vmware.com>
2020-11-02 21:39:43 +00:00
credentialIssuer: pinniped-config
Rename many of resources that are created in Kubernetes by Pinniped New resource naming conventions: - Do not repeat the Kind in the name, e.g. do not call it foo-cluster-role-binding, just call it foo - Names will generally start with a prefix to identify our component, so when a user lists all objects of that kind, they can tell to which component it is related, e.g. `kubectl get configmaps` would list one named "pinniped-config" - It should be possible for an operator to make the word "pinniped" mostly disappear if they choose, by specifying the app_name in values.yaml, to the extent that is practical (but not from APIService names because those are hardcoded in golang) - Each role/clusterrole and its corresponding binding have the same name - Pinniped resource names that must be known by the server golang code are passed to the code at run time via ConfigMap, rather than hardcoded in the golang code. This also allows them to be prepended with the app_name from values.yaml while creating the ConfigMap. - Since the CLI `get-kubeconfig` command cannot guess the name of the CredentialIssuerConfig resource in advance anymore, it lists all CredentialIssuerConfig in the app's namespace and returns an error if there is not exactly one found, and then uses that one regardless of its name
2020-09-18 22:56:50 +00:00
apiService: pinniped-api
Read the names of the impersonation-related resources from the config They were previously temporarily hardcoded. Now they are set at deploy time via the static ConfigMap in deployment.yaml
2021-03-02 17:31:24 +00:00
impersonationLoadBalancerService: impersonationLoadBalancerService-value
impersonationTLSCertificateSecret: impersonationTLSCertificateSecret-value
impersonationCACertificateSecret: impersonationCACertificateSecret-value
Use TokenCredentialRequest instead of base64 token with impersonator To make an impersonation request, first make a TokenCredentialRequest to get a certificate. That cert will either be issued by the Kube API server's CA or by a new CA specific to the impersonator. Either way, you can then make a request to the impersonator and present that client cert for auth and the impersonator will accept it and make the impesonation call on your behalf. The impersonator http handler now borrows some Kube library code to handle request processing. This will allow us to more closely mimic the behavior of a real API server, e.g. the client cert auth will work exactly like the real API server. Signed-off-by: Monis Khan <mok@vmware.com>
2021-03-10 18:30:06 +00:00
impersonationSignerSecret: impersonationSignerSecret-value
Rename many of resources that are created in Kubernetes by Pinniped New resource naming conventions: - Do not repeat the Kind in the name, e.g. do not call it foo-cluster-role-binding, just call it foo - Names will generally start with a prefix to identify our component, so when a user lists all objects of that kind, they can tell to which component it is related, e.g. `kubectl get configmaps` would list one named "pinniped-config" - It should be possible for an operator to make the word "pinniped" mostly disappear if they choose, by specifying the app_name in values.yaml, to the extent that is practical (but not from APIService names because those are hardcoded in golang) - Each role/clusterrole and its corresponding binding have the same name - Pinniped resource names that must be known by the server golang code are passed to the code at run time via ConfigMap, rather than hardcoded in the golang code. This also allows them to be prepended with the app_name from values.yaml while creating the ConfigMap. - Since the CLI `get-kubeconfig` command cannot guess the name of the CredentialIssuerConfig resource in advance anymore, it lists all CredentialIssuerConfig in the app's namespace and returns an error if there is not exactly one found, and then uses that one regardless of its name
2020-09-18 22:56:50 +00:00
`),
Use duration and renewBefore to control API cert rotation These configuration knobs are much more human-understandable than the previous percentage-based threshold flag. We now allow users to set the lifetime of the serving cert via a ConfigMap. Previously this was hardcoded to 1 year. Signed-off-by: Andrew Keesler <akeesler@vmware.com>
2020-08-20 19:17:18 +00:00
wantError: "validate api: durationSeconds cannot be smaller than renewBeforeSeconds",
},
pkg/config: force api.servingCertificate.renewBeforeSeconds to be positive Signed-off-by: Andrew Keesler <akeesler@vmware.com>
2020-08-20 22:14:07 +00:00
{
Rename many of resources that are created in Kubernetes by Pinniped New resource naming conventions: - Do not repeat the Kind in the name, e.g. do not call it foo-cluster-role-binding, just call it foo - Names will generally start with a prefix to identify our component, so when a user lists all objects of that kind, they can tell to which component it is related, e.g. `kubectl get configmaps` would list one named "pinniped-config" - It should be possible for an operator to make the word "pinniped" mostly disappear if they choose, by specifying the app_name in values.yaml, to the extent that is practical (but not from APIService names because those are hardcoded in golang) - Each role/clusterrole and its corresponding binding have the same name - Pinniped resource names that must be known by the server golang code are passed to the code at run time via ConfigMap, rather than hardcoded in the golang code. This also allows them to be prepended with the app_name from values.yaml while creating the ConfigMap. - Since the CLI `get-kubeconfig` command cannot guess the name of the CredentialIssuerConfig resource in advance anymore, it lists all CredentialIssuerConfig in the app's namespace and returns an error if there is not exactly one found, and then uses that one regardless of its name
2020-09-18 22:56:50 +00:00
name: "NegativeRenewBefore",
yaml: here.Doc(`
---
api:
servingCertificate:
durationSeconds: 2400
renewBeforeSeconds: -10
names:
Make tilt work with the supervisor app and add more uninstall testing - Also continue renaming things related to the concierge app - Enhance the uninstall test to also test uninstalling the supervisor and local-user-authenticator apps
2020-10-09 21:25:34 +00:00
servingCertificateSecret: pinniped-concierge-api-tls-serving-certificate
Rename CredentialIssuerConfig to CredentialIssuer. Signed-off-by: Matt Moyer <moyerm@vmware.com>
2020-11-02 21:39:43 +00:00
credentialIssuer: pinniped-config
Rename many of resources that are created in Kubernetes by Pinniped New resource naming conventions: - Do not repeat the Kind in the name, e.g. do not call it foo-cluster-role-binding, just call it foo - Names will generally start with a prefix to identify our component, so when a user lists all objects of that kind, they can tell to which component it is related, e.g. `kubectl get configmaps` would list one named "pinniped-config" - It should be possible for an operator to make the word "pinniped" mostly disappear if they choose, by specifying the app_name in values.yaml, to the extent that is practical (but not from APIService names because those are hardcoded in golang) - Each role/clusterrole and its corresponding binding have the same name - Pinniped resource names that must be known by the server golang code are passed to the code at run time via ConfigMap, rather than hardcoded in the golang code. This also allows them to be prepended with the app_name from values.yaml while creating the ConfigMap. - Since the CLI `get-kubeconfig` command cannot guess the name of the CredentialIssuerConfig resource in advance anymore, it lists all CredentialIssuerConfig in the app's namespace and returns an error if there is not exactly one found, and then uses that one regardless of its name
2020-09-18 22:56:50 +00:00
apiService: pinniped-api
Read the names of the impersonation-related resources from the config They were previously temporarily hardcoded. Now they are set at deploy time via the static ConfigMap in deployment.yaml
2021-03-02 17:31:24 +00:00
impersonationLoadBalancerService: impersonationLoadBalancerService-value
impersonationTLSCertificateSecret: impersonationTLSCertificateSecret-value
impersonationCACertificateSecret: impersonationCACertificateSecret-value
Use TokenCredentialRequest instead of base64 token with impersonator To make an impersonation request, first make a TokenCredentialRequest to get a certificate. That cert will either be issued by the Kube API server's CA or by a new CA specific to the impersonator. Either way, you can then make a request to the impersonator and present that client cert for auth and the impersonator will accept it and make the impesonation call on your behalf. The impersonator http handler now borrows some Kube library code to handle request processing. This will allow us to more closely mimic the behavior of a real API server, e.g. the client cert auth will work exactly like the real API server. Signed-off-by: Monis Khan <mok@vmware.com>
2021-03-10 18:30:06 +00:00
impersonationSignerSecret: impersonationSignerSecret-value
Rename many of resources that are created in Kubernetes by Pinniped New resource naming conventions: - Do not repeat the Kind in the name, e.g. do not call it foo-cluster-role-binding, just call it foo - Names will generally start with a prefix to identify our component, so when a user lists all objects of that kind, they can tell to which component it is related, e.g. `kubectl get configmaps` would list one named "pinniped-config" - It should be possible for an operator to make the word "pinniped" mostly disappear if they choose, by specifying the app_name in values.yaml, to the extent that is practical (but not from APIService names because those are hardcoded in golang) - Each role/clusterrole and its corresponding binding have the same name - Pinniped resource names that must be known by the server golang code are passed to the code at run time via ConfigMap, rather than hardcoded in the golang code. This also allows them to be prepended with the app_name from values.yaml while creating the ConfigMap. - Since the CLI `get-kubeconfig` command cannot guess the name of the CredentialIssuerConfig resource in advance anymore, it lists all CredentialIssuerConfig in the app's namespace and returns an error if there is not exactly one found, and then uses that one regardless of its name
2020-09-18 22:56:50 +00:00
`),
pkg/config: force api.servingCertificate.renewBeforeSeconds to be positive Signed-off-by: Andrew Keesler <akeesler@vmware.com>
2020-08-20 22:14:07 +00:00
wantError: "validate api: renewBefore must be positive",
},
Add aggregatedAPIServerPort to the Concierge's static ConfigMap - Allow the port number to be configured to any value within the range 1024 to 65535 - This commit does not include adding new config knobs to the ytt values file, so while it is possible to change this port without needing to recompile, it is not convenient
2021-11-17 00:43:51 +00:00
{
name: "AggregatedAPIServerPortDefault too small",
yaml: here.Doc(`
---
aggregatedAPIServerPort: 1023
`),
wantError: "validate aggregatedAPIServerPort: must be within range 1024 to 65535",
},
{
name: "AggregatedAPIServerPortDefault too large",
yaml: here.Doc(`
---
aggregatedAPIServerPort: 65536
`),
wantError: "validate aggregatedAPIServerPort: must be within range 1024 to 65535",
},
Add impersonationProxyServerPort to the Concierge's static ConfigMap - Used to determine on which port the impersonation proxy will bind - Defaults to 8444, which is the old hard-coded port value - Allow the port number to be configured to any value within the range 1024 to 65535 - This commit does not include adding new config knobs to the ytt values file, so while it is possible to change this port without needing to recompile, it is not convenient
2021-11-17 21:27:59 +00:00
{
name: "ImpersonationProxyServerPort too small",
yaml: here.Doc(`
---
impersonationProxyServerPort: 1023
`),
wantError: "validate impersonationProxyServerPort: must be within range 1024 to 65535",
},
{
name: "ImpersonationProxyServerPort too large",
yaml: here.Doc(`
---
impersonationProxyServerPort: 65536
`),
wantError: "validate impersonationProxyServerPort: must be within range 1024 to 65535",
},
pkg/config: force api.servingCertificate.renewBeforeSeconds to be positive Signed-off-by: Andrew Keesler <akeesler@vmware.com>
2020-08-20 22:14:07 +00:00
{
Rename many of resources that are created in Kubernetes by Pinniped New resource naming conventions: - Do not repeat the Kind in the name, e.g. do not call it foo-cluster-role-binding, just call it foo - Names will generally start with a prefix to identify our component, so when a user lists all objects of that kind, they can tell to which component it is related, e.g. `kubectl get configmaps` would list one named "pinniped-config" - It should be possible for an operator to make the word "pinniped" mostly disappear if they choose, by specifying the app_name in values.yaml, to the extent that is practical (but not from APIService names because those are hardcoded in golang) - Each role/clusterrole and its corresponding binding have the same name - Pinniped resource names that must be known by the server golang code are passed to the code at run time via ConfigMap, rather than hardcoded in the golang code. This also allows them to be prepended with the app_name from values.yaml while creating the ConfigMap. - Since the CLI `get-kubeconfig` command cannot guess the name of the CredentialIssuerConfig resource in advance anymore, it lists all CredentialIssuerConfig in the app's namespace and returns an error if there is not exactly one found, and then uses that one regardless of its name
2020-09-18 22:56:50 +00:00
name: "ZeroRenewBefore",
yaml: here.Doc(`
---
api:
servingCertificate:
durationSeconds: 2400
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
renewBeforeSeconds: 0
Rename many of resources that are created in Kubernetes by Pinniped New resource naming conventions: - Do not repeat the Kind in the name, e.g. do not call it foo-cluster-role-binding, just call it foo - Names will generally start with a prefix to identify our component, so when a user lists all objects of that kind, they can tell to which component it is related, e.g. `kubectl get configmaps` would list one named "pinniped-config" - It should be possible for an operator to make the word "pinniped" mostly disappear if they choose, by specifying the app_name in values.yaml, to the extent that is practical (but not from APIService names because those are hardcoded in golang) - Each role/clusterrole and its corresponding binding have the same name - Pinniped resource names that must be known by the server golang code are passed to the code at run time via ConfigMap, rather than hardcoded in the golang code. This also allows them to be prepended with the app_name from values.yaml while creating the ConfigMap. - Since the CLI `get-kubeconfig` command cannot guess the name of the CredentialIssuerConfig resource in advance anymore, it lists all CredentialIssuerConfig in the app's namespace and returns an error if there is not exactly one found, and then uses that one regardless of its name
2020-09-18 22:56:50 +00:00
names:
Make tilt work with the supervisor app and add more uninstall testing - Also continue renaming things related to the concierge app - Enhance the uninstall test to also test uninstalling the supervisor and local-user-authenticator apps
2020-10-09 21:25:34 +00:00
servingCertificateSecret: pinniped-concierge-api-tls-serving-certificate
Rename CredentialIssuerConfig to CredentialIssuer. Signed-off-by: Matt Moyer <moyerm@vmware.com>
2020-11-02 21:39:43 +00:00
credentialIssuer: pinniped-config
Rename many of resources that are created in Kubernetes by Pinniped New resource naming conventions: - Do not repeat the Kind in the name, e.g. do not call it foo-cluster-role-binding, just call it foo - Names will generally start with a prefix to identify our component, so when a user lists all objects of that kind, they can tell to which component it is related, e.g. `kubectl get configmaps` would list one named "pinniped-config" - It should be possible for an operator to make the word "pinniped" mostly disappear if they choose, by specifying the app_name in values.yaml, to the extent that is practical (but not from APIService names because those are hardcoded in golang) - Each role/clusterrole and its corresponding binding have the same name - Pinniped resource names that must be known by the server golang code are passed to the code at run time via ConfigMap, rather than hardcoded in the golang code. This also allows them to be prepended with the app_name from values.yaml while creating the ConfigMap. - Since the CLI `get-kubeconfig` command cannot guess the name of the CredentialIssuerConfig resource in advance anymore, it lists all CredentialIssuerConfig in the app's namespace and returns an error if there is not exactly one found, and then uses that one regardless of its name
2020-09-18 22:56:50 +00:00
apiService: pinniped-api
Read the names of the impersonation-related resources from the config They were previously temporarily hardcoded. Now they are set at deploy time via the static ConfigMap in deployment.yaml
2021-03-02 17:31:24 +00:00
impersonationLoadBalancerService: impersonationLoadBalancerService-value
impersonationTLSCertificateSecret: impersonationTLSCertificateSecret-value
impersonationCACertificateSecret: impersonationCACertificateSecret-value
Use TokenCredentialRequest instead of base64 token with impersonator To make an impersonation request, first make a TokenCredentialRequest to get a certificate. That cert will either be issued by the Kube API server's CA or by a new CA specific to the impersonator. Either way, you can then make a request to the impersonator and present that client cert for auth and the impersonator will accept it and make the impesonation call on your behalf. The impersonator http handler now borrows some Kube library code to handle request processing. This will allow us to more closely mimic the behavior of a real API server, e.g. the client cert auth will work exactly like the real API server. Signed-off-by: Monis Khan <mok@vmware.com>
2021-03-10 18:30:06 +00:00
impersonationSignerSecret: impersonationSignerSecret-value
Rename many of resources that are created in Kubernetes by Pinniped New resource naming conventions: - Do not repeat the Kind in the name, e.g. do not call it foo-cluster-role-binding, just call it foo - Names will generally start with a prefix to identify our component, so when a user lists all objects of that kind, they can tell to which component it is related, e.g. `kubectl get configmaps` would list one named "pinniped-config" - It should be possible for an operator to make the word "pinniped" mostly disappear if they choose, by specifying the app_name in values.yaml, to the extent that is practical (but not from APIService names because those are hardcoded in golang) - Each role/clusterrole and its corresponding binding have the same name - Pinniped resource names that must be known by the server golang code are passed to the code at run time via ConfigMap, rather than hardcoded in the golang code. This also allows them to be prepended with the app_name from values.yaml while creating the ConfigMap. - Since the CLI `get-kubeconfig` command cannot guess the name of the CredentialIssuerConfig resource in advance anymore, it lists all CredentialIssuerConfig in the app's namespace and returns an error if there is not exactly one found, and then uses that one regardless of its name
2020-09-18 22:56:50 +00:00
`),
pkg/config: force api.servingCertificate.renewBeforeSeconds to be positive Signed-off-by: Andrew Keesler <akeesler@vmware.com>
2020-08-20 22:14:07 +00:00
wantError: "validate api: renewBefore must be positive",
},
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: "InvalidAPIGroupSuffix",
yaml: here.Doc(`
---
api:
servingCertificate:
durationSeconds: 3600
renewBeforeSeconds: 2400
apiGroupSuffix: .starts.with.dot
names:
servingCertificateSecret: pinniped-concierge-api-tls-serving-certificate
credentialIssuer: pinniped-config
apiService: pinniped-api
Read the names of the impersonation-related resources from the config They were previously temporarily hardcoded. Now they are set at deploy time via the static ConfigMap in deployment.yaml
2021-03-02 17:31:24 +00:00
impersonationLoadBalancerService: impersonationLoadBalancerService-value
impersonationTLSCertificateSecret: impersonationTLSCertificateSecret-value
impersonationCACertificateSecret: impersonationCACertificateSecret-value
Use TokenCredentialRequest instead of base64 token with impersonator To make an impersonation request, first make a TokenCredentialRequest to get a certificate. That cert will either be issued by the Kube API server's CA or by a new CA specific to the impersonator. Either way, you can then make a request to the impersonator and present that client cert for auth and the impersonator will accept it and make the impesonation call on your behalf. The impersonator http handler now borrows some Kube library code to handle request processing. This will allow us to more closely mimic the behavior of a real API server, e.g. the client cert auth will work exactly like the real API server. Signed-off-by: Monis Khan <mok@vmware.com>
2021-03-10 18:30:06 +00:00
impersonationSignerSecret: impersonationSignerSecret-value
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
`),
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
wantError: "validate apiGroupSuffix: a lowercase RFC 1123 subdomain must consist of lower case alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character (e.g. 'example.com', regex used for validation is '[a-z0-9]([-a-z0-9]*[a-z0-9])?(\\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*')",
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
},
Allow override of discovery URL via ConfigMap Signed-off-by: Andrew Keesler <akeesler@vmware.com> - Seems like the next step is to allow override of the CA bundle; I didn't do that here for simplicity of the commit, but seems like it is the right thing to do in the future.
2020-08-03 14:17:11 +00:00
}
for _, test := range tests {
test := test
t.Run(test.name, func(t *testing.T) {
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
// this is a serial test because it sets the global logger
Rename many of resources that are created in Kubernetes by Pinniped New resource naming conventions: - Do not repeat the Kind in the name, e.g. do not call it foo-cluster-role-binding, just call it foo - Names will generally start with a prefix to identify our component, so when a user lists all objects of that kind, they can tell to which component it is related, e.g. `kubectl get configmaps` would list one named "pinniped-config" - It should be possible for an operator to make the word "pinniped" mostly disappear if they choose, by specifying the app_name in values.yaml, to the extent that is practical (but not from APIService names because those are hardcoded in golang) - Each role/clusterrole and its corresponding binding have the same name - Pinniped resource names that must be known by the server golang code are passed to the code at run time via ConfigMap, rather than hardcoded in the golang code. This also allows them to be prepended with the app_name from values.yaml while creating the ConfigMap. - Since the CLI `get-kubeconfig` command cannot guess the name of the CredentialIssuerConfig resource in advance anymore, it lists all CredentialIssuerConfig in the app's namespace and returns an error if there is not exactly one found, and then uses that one regardless of its name
2020-09-18 22:56:50 +00:00
// Write yaml to temp file
Upgrade the linter and fix all new linter warnings Also fix some tests that were broken by bumping golang and dependencies in the previous commits. Note that in addition to changes made to satisfy the linter which do not impact the behavior of the code, this commit also adds ReadHeaderTimeout to all usages of http.Server to satisfy the linter (and because it seemed like a good suggestion).
2022-08-24 21:45:55 +00:00
f, err := os.CreateTemp("", "pinniped-test-config-yaml-*")
Rename many of resources that are created in Kubernetes by Pinniped New resource naming conventions: - Do not repeat the Kind in the name, e.g. do not call it foo-cluster-role-binding, just call it foo - Names will generally start with a prefix to identify our component, so when a user lists all objects of that kind, they can tell to which component it is related, e.g. `kubectl get configmaps` would list one named "pinniped-config" - It should be possible for an operator to make the word "pinniped" mostly disappear if they choose, by specifying the app_name in values.yaml, to the extent that is practical (but not from APIService names because those are hardcoded in golang) - Each role/clusterrole and its corresponding binding have the same name - Pinniped resource names that must be known by the server golang code are passed to the code at run time via ConfigMap, rather than hardcoded in the golang code. This also allows them to be prepended with the app_name from values.yaml while creating the ConfigMap. - Since the CLI `get-kubeconfig` command cannot guess the name of the CredentialIssuerConfig resource in advance anymore, it lists all CredentialIssuerConfig in the app's namespace and returns an error if there is not exactly one found, and then uses that one regardless of its name
2020-09-18 22:56:50 +00:00
require.NoError(t, err)
defer func() {
err := os.Remove(f.Name())
require.NoError(t, err)
}()
_, err = f.WriteString(test.yaml)
require.NoError(t, err)
err = f.Close()
require.NoError(t, err)
// Test FromPath()
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
ctx, cancel := context.WithCancel(context.Background())
t.Cleanup(cancel)
config, err := FromPath(ctx, f.Name())
Rename many of resources that are created in Kubernetes by Pinniped New resource naming conventions: - Do not repeat the Kind in the name, e.g. do not call it foo-cluster-role-binding, just call it foo - Names will generally start with a prefix to identify our component, so when a user lists all objects of that kind, they can tell to which component it is related, e.g. `kubectl get configmaps` would list one named "pinniped-config" - It should be possible for an operator to make the word "pinniped" mostly disappear if they choose, by specifying the app_name in values.yaml, to the extent that is practical (but not from APIService names because those are hardcoded in golang) - Each role/clusterrole and its corresponding binding have the same name - Pinniped resource names that must be known by the server golang code are passed to the code at run time via ConfigMap, rather than hardcoded in the golang code. This also allows them to be prepended with the app_name from values.yaml while creating the ConfigMap. - Since the CLI `get-kubeconfig` command cannot guess the name of the CredentialIssuerConfig resource in advance anymore, it lists all CredentialIssuerConfig in the app's namespace and returns an error if there is not exactly one found, and then uses that one regardless of its name
2020-09-18 22:56:50 +00:00
Use duration and renewBefore to control API cert rotation These configuration knobs are much more human-understandable than the previous percentage-based threshold flag. We now allow users to set the lifetime of the serving cert via a ConfigMap. Previously this was hardcoded to 1 year. Signed-off-by: Andrew Keesler <akeesler@vmware.com>
2020-08-20 19:17:18 +00:00
if test.wantError != "" {
require.EqualError(t, err, test.wantError)
} else {
require.NoError(t, err)
require.Equal(t, test.wantConfig, config)
}
Allow override of discovery URL via ConfigMap Signed-off-by: Andrew Keesler <akeesler@vmware.com> - Seems like the next step is to allow override of the CA bundle; I didn't do that here for simplicity of the commit, but seems like it is the right thing to do in the future.
2020-08-03 14:17:11 +00:00
})
}
}
Reference in New Issue Copy Permalink