diff --git a/.goreleaser.yml b/.goreleaser.yml index 5c86e202a..89111987d 100644 --- a/.goreleaser.yml +++ b/.goreleaser.yml @@ -59,7 +59,7 @@ release: footer: | ## Release Notes - Please read the [RELEASE_NOTES](https://github.com/bitnami-labs/sealed-secrets/blob/master/RELEASE-NOTES.md) which contain among other things important information for who is upgrading from previous releases. + Please read the [RELEASE_NOTES](https://github.com/bitnami-labs/sealed-secrets/blob/main/RELEASE-NOTES.md) which contain among other things important information for who is upgrading from previous releases. ## Thanks! extra_files: diff --git a/README.md b/README.md index 5495ede10..911edc7eb 100644 --- a/README.md +++ b/README.md @@ -173,7 +173,7 @@ ensure you are using the correct one. (requires secure access to the Kubernetes API server), which is convenient for interactive use, but it's known to be brittle when users have clusters with special configurations such as [private GKE clusters](docs/GKE.md#private-gke-clusters) that have -firewalls between master and nodes. +firewalls between control plane and nodes. An alternative workflow is to store the certificate somewhere (e.g. local disk) with @@ -215,7 +215,7 @@ seal a secret for a namespace, it cannot be moved in another namespace and decry We don't technically use an independent private key for each namespace, but instead we *include* the namespace name during the encryption process, effectively achieving the same result. -Furthermore, namespaces are not the only level at which RBAC configurations can decide who can see which secret. In fact, it's possible that users can access a secret called `foo` in a given namespace but not any other secret in the same namespace. We cannot thus by default let users freely rename SealedSecret resources otherwise a malicious user would be able to decrypt any SealedSecret for that namespace by just renaming it to overwrite the one secret she does have access to. We use the same mechanism used to include the namespace in the encryption key to also include the secret name. +Furthermore, namespaces are not the only level at which RBAC configurations can decide who can see which secret. In fact, it's possible that users can access a secret called `foo` in a given namespace but not any other secret in the same namespace. We cannot thus by default let users freely rename SealedSecret resources otherwise a malicious user would be able to decrypt any SealedSecret for that namespace by just renaming it to overwrite the one secret they do have access to. We use the same mechanism used to include the namespace in the encryption key to also include the secret name. That said, there are many scenarios where you might not care about this level of protection. For example, the only people who have access to your clusters are either admins or they cannot read any secret resource at all. You might have a use case for moving a sealed secret to other namespaces (e.g. you might not know the namespace name upfront), or you might not know the name of the secret (e.g. it could contain a unique suffix based on the hash of the contents etc). @@ -486,7 +486,7 @@ The renewal time of 30d is a reasonable default, but it can be tweaked as needed with the `--key-renew-period=` flag for the command in the pod template of the sealed secret controller. The `value` field can be given as golang duration flag (eg: `720h30m`). -A value of `0` will disable automatic key renewal. Of course, it's possible you have a valid use case for disabling automatic sealing key renewal; but experience has shown that new users often tend to jump to conclusions that they want control over key renewal, before fully understanding how sealed secrets work. Read more about this in the [common misconceptions](#common-misconceptions-about-key-renewal) section below. +A value of `0` will deactivate automatic key renewal. Of course, it's possible you have a valid use case for deactivating automatic sealing key renewal; but experience has shown that new users often tend to jump to conclusions that they want control over key renewal, before fully understanding how sealed secrets work. Read more about this in the [common misconceptions](#common-misconceptions-about-key-renewal) section below. > Unfortunately you cannot use e.g. "d" as a unit for days because that's not supported by the Go stdlib. Instead of hitting your face with a palm, take this as an opportunity to meditate on the [falsehoods programmers believe about time](https://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time). @@ -607,8 +607,8 @@ No, the private keys are only stored in the Secret managed by the controller (un If you do want to make a backup of the encryption private keys, it's easy to do from an account with suitable access and: ```bash -kubectl get secret -n kube-system -l sealedsecrets.bitnami.com/sealed-secrets-key -o yaml >master.key -kubectl get secret -n kube-system sealed-secrets-key -o yaml >>master.key +kubectl get secret -n kube-system -l sealedsecrets.bitnami.com/sealed-secrets-key -o yaml >main.key +kubectl get secret -n kube-system sealed-secrets-key -o yaml >>main.key ``` NOTE: you need the second statement only if you ever installed sealed-secrets older than version 0.9.x on your cluster. @@ -618,7 +618,7 @@ NOTE: This file will contain the controller's public + private keys and should b To restore from a backup after some disaster, just put that secrets back before starting the controller - or if the controller was already started, replace the newly-created secrets and restart the controller: ```bash -kubectl apply -f master.key +kubectl apply -f main.key kubectl delete pod -n kube-system -l name=sealed-secrets-controller ``` diff --git a/RELEASE-NOTES.md b/RELEASE-NOTES.md index c3c83442d..2638b40e4 100644 --- a/RELEASE-NOTES.md +++ b/RELEASE-NOTES.md @@ -61,7 +61,7 @@ Latest release: ### Announcements -This release finally turns on the `update-status` feature flag that was introduced back in v0.12.0. The feature is considered stable (if it doesn't work for you, you can disable it by setting `SEALED_SECRETS_UPDATE_STATUS=0` in the controller manifest). +This release finally turns on the `update-status` feature flag that was introduced back in v0.12.0. The feature is considered stable (if it doesn't work for you, you can deactivate it by setting `SEALED_SECRETS_UPDATE_STATUS=0` in the controller manifest). ### Changelog @@ -202,7 +202,7 @@ In order to turn it back on you need to manually pass the `--update-status` flag ### Changelog - Make it easier to use --raw from stdin ([#386](https://github.com/bitnami-labs/sealed-secrets/issues/386)) -- Disable status updates unless a feature flag is explicitly passed ([#388](https://github.com/bitnami-labs/sealed-secrets/issues/388)) +- Deactivate status updates unless a feature flag is explicitly passed ([#388](https://github.com/bitnami-labs/sealed-secrets/issues/388)) The full Changelog is maintained in https://github.com/bitnami-labs/sealed-secrets/milestone/18?closed=1 @@ -439,7 +439,7 @@ $ kubectl create secret generic mysecret --dry-run -o json --from-file=bar=/tmp/ - Rename "key rotation" to "key renewal" since the terminology was confusing. - Key renewal is enabled by default every 30 days ([#236](https://github.com/bitnami-labs/sealed-secrets/issues/236)) - You can now use env vars such as SEALED_SECRETS_FOO_BAR to customize the controller ([#234](https://github.com/bitnami-labs/sealed-secrets/issues/234)) -- Disabling by default deprecated "v1" encrypted data format (used by pre-v0.7.0 clients) ([#235](https://github.com/bitnami-labs/sealed-secrets/issues/235)) +- Deactivating by default deprecated "v1" encrypted data format (used by pre-v0.7.0 clients) ([#235](https://github.com/bitnami-labs/sealed-secrets/issues/235)) - Fix RBAC rules for /v1/rotate and /v1/validate fixing #166 for good ([#249](https://github.com/bitnami-labs/sealed-secrets/issues/249)) - Implement the --merge-into command ([#253](https://github.com/bitnami-labs/sealed-secrets/issues/253)) - Add the `-o` alias for `--format` ([#261](https://github.com/bitnami-labs/sealed-secrets/issues/261)) diff --git a/cmd/controller/main.go b/cmd/controller/main.go index 3934ae7a2..9fdb69beb 100644 --- a/cmd/controller/main.go +++ b/cmd/controller/main.go @@ -43,7 +43,7 @@ var ( validFor = flag.Duration("key-ttl", 10*365*24*time.Hour, "Duration that certificate is valid for.") myCN = flag.String("my-cn", "", "Common name to be used as issuer/subject DN in generated certificate.") printVersion = flag.Bool("version", false, "Print version information and exit") - keyRenewPeriod = flag.Duration("key-renew-period", defaultKeyRenewPeriod, "New key generation period (automatic rotation disabled if 0)") + keyRenewPeriod = flag.Duration("key-renew-period", defaultKeyRenewPeriod, "New key generation period (automatic rotation deactivated if 0)") acceptV1Data = flag.Bool("accept-deprecated-v1-data", true, "Accept deprecated V1 data field.") keyCutoffTime = flag.String("key-cutoff-time", "", "Create a new key if latest one is older than this cutoff time. RFC1123 format with numeric timezone expected.") namespaceAll = flag.Bool("all-namespaces", true, "Scan all namespaces or only the current namespace (default=true).") @@ -135,7 +135,7 @@ func myNamespace() string { } // Initialises the first key and starts the rotation job. returns an early trigger function. -// A period of 0 disables automatic rotation, but manual rotation (e.g. triggered by SIGUSR1) +// A period of 0 deactivates automatic rotation, but manual rotation (e.g. triggered by SIGUSR1) // is still honoured. func initKeyRenewal(ctx context.Context, registry *KeyRegistry, period time.Duration, cutoffTime time.Time) (func(), error) { // Create a new key if it's the first key, diff --git a/cmd/controller/main_test.go b/cmd/controller/main_test.go index 18b62c11d..dcc6851c7 100644 --- a/cmd/controller/main_test.go +++ b/cmd/controller/main_test.go @@ -184,7 +184,7 @@ func TestReuseKey(t *testing.T) { t.Fatalf("initKeyRenewal() returned err: %v", err) } if hasAction(client, "create", "secrets") { - t.Errorf("initKeyRenewal() should not create a new secret when one already exist and rotation is disabled") + t.Errorf("initKeyRenewal() should not create a new secret when one already exist and rotation is deactivated") } } @@ -348,6 +348,6 @@ func TestLegacySecret(t *testing.T) { t.Fatalf("initKeyRenewal() returned err: %v", err) } if hasAction(client, "create", "secrets") { - t.Errorf("initKeyRenewal() should not create a new secret when one already exist and rotation is disabled") + t.Errorf("initKeyRenewal() should not create a new secret when one already exist and rotation is deactivated") } } diff --git a/docs/GKE.md b/docs/GKE.md index a818435af..a9f4338c0 100644 --- a/docs/GKE.md +++ b/docs/GKE.md @@ -12,7 +12,7 @@ kubectl create clusterrolebinding $USER-cluster-admin-binding --clusterrole=clus ## Private GKE clusters If you are using a **private GKE cluster**, `kubeseal` won't be able to fetch the public key from the controller -because there is firewall that prevents the master to talk directly to the nodes. +because there is firewall that prevents the control plane to talk directly to the nodes. There are currently two workarounds: @@ -29,19 +29,19 @@ Once you have the cert this is how you seal secrets: kubeseal --cert=cert.pem Report Issues {{ $editQuery := (querify "description" "Signed-off-by: NAME \n\n") }} -
  • Edit
    • +
  • Edit
    • {{ end }} {{ if ne .TableOfContents "" }} @@ -16,4 +16,4 @@

    On this page:

    {{ end }} -{{ end }} \ No newline at end of file +{{ end }}