docs: rewrite Kubernetes Operator guide for v1beta1 CRDs#6955
docs: rewrite Kubernetes Operator guide for v1beta1 CRDs#6955jakehulberg wants to merge 1 commit into
Conversation
Rewrites the guide around the v1beta1 flow (InfisicalConnection, InfisicalAuth, InfisicalStaticSecret), replacing the deprecated InfisicalSecret. Leads with Kubernetes Auth (the recommended in-cluster method) and documents Universal Auth as the simpler alternative. Keeps InfisicalPushSecret and InfisicalDynamicSecret on v1alpha1. Adds a Kubernetes Auth reachability matrix. Validated end-to-end on minikube against a self-hosted Infisical: operator install, Connection/Auth/StaticSecret sync, deployment consumption + auto-reload, both auth methods, push, and the production CA + TLS-verify token review path.
|
💬 Discussion in Slack: #pr-review-infisical-6955-docs-rewrite-kubernetes-operator-guide-for-v1beta1-crds Posted by Review Police — reviews, comments, new commits, and CI failures will stream into this channel. |
|
| Filename | Overview |
|---|---|
| docs/documentation/guides/kubernetes-operator.mdx | Full rewrite of the Kubernetes Operator guide for v1beta1 CRDs; introduces inline YAML manifests and a reachability matrix, but the ALLOW_INTERNAL_IP_CONNECTIONS=true guidance lacks an SSRF warning, and the cleanup section omits commands for RBAC resources and doesn't warn that deletionPolicy:Delete will remove secrets from Infisical. |
Reviews (1): Last reviewed commit: "docs: rewrite Kubernetes Operator guide ..." | Re-trigger Greptile
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| | Managed cluster (EKS, GKE, AKS, OpenShift) | Use the API server's public or peered endpoint and supply its CA certificate with verification on. This is the production path. | | ||
| | No inbound access allowed | Set **Review Mode** to **Gateway as Reviewer**, so an in-cluster [Gateway](/documentation/platform/gateways/overview) performs the TokenReview locally. Gateway is an Enterprise feature. | | ||
| | Infisical Cloud + a local cluster (minikube, kind) | Expose the API server through a public hostname (for example an `ngrok` tunnel): a public host passes Infisical's host validation and is reachable for the TokenReview. Leave the CA certificate empty only for local testing, which disables TLS verification. | | ||
| | Self-hosted Infisical that routes to the cluster on a private IP | Set `ALLOW_INTERNAL_IP_CONNECTIONS=true` on the Infisical instance and use the API server's IP. When you save the auth method, Infisical otherwise rejects private IPs and always rejects the literal hostnames `localhost` and `host.docker.internal`. | |
There was a problem hiding this comment.
ALLOW_INTERNAL_IP_CONNECTIONS=true not called out
Setting ALLOW_INTERNAL_IP_CONNECTIONS=true on the Infisical instance removes the guard that blocks private-range destinations from the TokenReview outbound call. Any user with permission to configure a Kubernetes Auth method can then point the Kubernetes Host field at an arbitrary internal address (e.g., 169.254.169.254 on AWS/GCP, or any internal admin service) and cause Infisical's backend to make requests to it. The paragraph should note that access to create or edit Kubernetes Auth methods should be restricted when this flag is enabled.
| ## Cleanup | ||
|
|
||
| ```bash | ||
| kubectl delete infisicalstaticsecret lab-static-secret | ||
| kubectl delete infisicalpushsecret lab-push | ||
| kubectl delete infisicaldynamicsecret lab-dynamic-secret | ||
| kubectl delete infisicalauth lab-auth | ||
| kubectl delete infisicalconnection lab-connection | ||
| helm uninstall infisical-operator -n infisical-operator | ||
| ``` | ||
|
|
||
| **Congratulations! You successfully managed secrets with Kubernetes.** No newline at end of file | ||
| <Note> | ||
| Managed Secrets created with `creationPolicy: Owner` are removed with their owning CRD. Secrets created with `Orphan`, the reviewer service account, and the operator's own namespace are not removed by `helm uninstall`. | ||
| </Note> |
There was a problem hiding this comment.
deletionPolicy: Delete
The guide configures InfisicalPushSecret with deletionPolicy: Delete (line 364). Running kubectl delete infisicalpushsecret lab-push will therefore also delete the pushed keys from the Infisical project — not just the in-cluster resource. A user running the cleanup block without being aware of this will lose the PUSHED_KEY and ANOTHER_KEY secrets server-side. A one-line warning before the cleanup commands (or inline with the deletionPolicy explanation) would prevent accidental data loss.
| ## Cleanup | ||
|
|
||
| ```bash | ||
| kubectl delete infisicalstaticsecret lab-static-secret | ||
| kubectl delete infisicalpushsecret lab-push | ||
| kubectl delete infisicaldynamicsecret lab-dynamic-secret | ||
| kubectl delete infisicalauth lab-auth | ||
| kubectl delete infisicalconnection lab-connection | ||
| helm uninstall infisical-operator -n infisical-operator | ||
| ``` | ||
|
|
||
| **Congratulations! You successfully managed secrets with Kubernetes.** No newline at end of file | ||
| <Note> | ||
| Managed Secrets created with `creationPolicy: Owner` are removed with their owning CRD. Secrets created with `Orphan`, the reviewer service account, and the operator's own namespace are not removed by `helm uninstall`. | ||
| </Note> |
There was a problem hiding this comment.
The closing <Note> correctly states the reviewer service account is not removed by helm uninstall, but it gives users no commands to do it themselves. After following the guide, three resources remain: ServiceAccount/infisical-service-account, Secret/infisical-service-account-token, and ClusterRoleBinding/infisical-service-account-role-binding. The ClusterRoleBinding grants system:auth-delegator cluster-wide; leaving it dangling after the operator is uninstalled is unnecessary privilege. Similarly, the demo Deployment/demo-app is not listed.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 4ac803934e
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| kubectl create secret generic kubernetes-credentials \ | ||
| --from-literal=identityId="<your-machine-identity-id>" |
There was a problem hiding this comment.
When the user's current kubectl namespace is not default (-n is the namespace scope for the request per the kubectl docs), this command creates kubernetes-credentials in the wrong namespace, while the following InfisicalAuth hard-codes identityIdRef.namespace: default. In that context the operator cannot find the Secret and authentication stays NotReady; add -n default here (and to the Universal Auth credentials command later) or avoid hard-coding default in the references.
Useful? React with 👍 / 👎.
|
Preview deployment for your docs. Learn more about Mintlify Previews.
💡 Tip: Enable Workflows to automatically generate PRs for you. |
1 participant
What
Rewrites the Kubernetes Operator guide for the current v1beta1 CRD generation.
InfisicalConnection+InfisicalAuth+InfisicalStaticSecret(replaces the deprecatedInfisicalSecret+ token-reviewer-JWT walkthrough).InfisicalPushSecretandInfisicalDynamicSecretonv1alpha1(no v1beta1 replacement yet).Validation
Run end-to-end on minikube against a self-hosted Infisical:
InfisicalConnection/InfisicalAuth/InfisicalStaticSecretsync; Deployment consumption viaenvFrom+auto-reloadredeploy.InfisicalPushSecretvia both Universal and Kubernetes Auth.Not yet validated (reviewer please note)
InfisicalDynamicSecretsection: schema-verified only, not run end-to-end.