diff --git a/docs/integrations/platforms/kubernetes/infisical-dynamic-secret-crd.mdx b/docs/integrations/platforms/kubernetes/infisical-dynamic-secret-crd.mdx index 82e60af7f3..21f54994a1 100644 --- a/docs/integrations/platforms/kubernetes/infisical-dynamic-secret-crd.mdx +++ b/docs/integrations/platforms/kubernetes/infisical-dynamic-secret-crd.mdx @@ -264,6 +264,7 @@ The available authentication methods are `universalAuth`, `kubernetesAuth`, `aws - `credentialsRef.secretName`: The name of the Kubernetes secret. - `credentialsRef.secretNamespace`: The namespace of the Kubernetes secret. + Example: ```yaml @@ -296,6 +297,9 @@ The available authentication methods are `universalAuth`, `kubernetesAuth`, `aws - `serviceAccountRef`: The name and namespace of the service account that will be used to authenticate with Infisical. - `serviceAccountRef.name`: The name of the service account. - `serviceAccountRef.namespace`: The namespace of the service account. + - `autoCreateServiceAccountToken`: If set to `true`, the operator will automatically create a short-lived service account token on-demand for the service account. Defaults to `false`. + - `serviceAccountTokenAudiences`: Optionally specify audience for the service account token. This field is only relevant if you have set `autoCreateServiceAccountToken` to `true`. No audience is specified by default. + Example: @@ -303,6 +307,9 @@ The available authentication methods are `universalAuth`, `kubernetesAuth`, `aws spec: kubernetesAuth: identityId: + autoCreateServiceAccountToken: true # Automatically creates short-lived service account tokens for the service account. + serviceAccountTokenAudiences: + - # Optionally specify audience for the service account token. No audience is specified by default. serviceAccountRef: name: namespace: diff --git a/docs/integrations/platforms/kubernetes/infisical-push-secret-crd.mdx b/docs/integrations/platforms/kubernetes/infisical-push-secret-crd.mdx index 0664f0cd87..50f07bb76f 100644 --- a/docs/integrations/platforms/kubernetes/infisical-push-secret-crd.mdx +++ b/docs/integrations/platforms/kubernetes/infisical-push-secret-crd.mdx @@ -291,6 +291,8 @@ After applying the InfisicalPushSecret CRD, you should notice that the secrets y - `serviceAccountRef`: The name and namespace of the service account that will be used to authenticate with Infisical. - `serviceAccountRef.name`: The name of the service account. - `serviceAccountRef.namespace`: The namespace of the service account. + - `autoCreateServiceAccountToken`: If set to `true`, the operator will automatically create a short-lived service account token on-demand for the service account. Defaults to `false`. + - `serviceAccountTokenAudiences`: Optionally specify audience for the service account token. This field is only relevant if you have set `autoCreateServiceAccountToken` to `true`. No audience is specified by default. Example: @@ -298,6 +300,9 @@ After applying the InfisicalPushSecret CRD, you should notice that the secrets y spec: kubernetesAuth: identityId: + autoCreateServiceAccountToken: true # Automatically creates short-lived service account tokens for the service account. + serviceAccountTokenAudiences: + - # Optionally specify audience for the service account token. No audience is specified by default. serviceAccountRef: name: namespace: diff --git a/docs/integrations/platforms/kubernetes/infisical-secret-crd.mdx b/docs/integrations/platforms/kubernetes/infisical-secret-crd.mdx index f23eb010db..4c33b893bf 100644 --- a/docs/integrations/platforms/kubernetes/infisical-secret-crd.mdx +++ b/docs/integrations/platforms/kubernetes/infisical-secret-crd.mdx @@ -156,157 +156,420 @@ spec: The Kubernetes machine identity authentication method is used to authenticate with Infisical. The identity ID is stored in a field in the InfisicalSecret resource. This authentication method can only be used within a Kubernetes environment. - - - 1.1. Start by creating a service account in your Kubernetes cluster that will be used by Infisical to authenticate with the Kubernetes API Server. + + + Short-lived service account tokens are automatically created by the operator and are valid only for a short period of time. This is the recommended approach for using Kubernetes auth in the Infisical Secrets Operator. - ```yaml infisical-service-account.yaml - apiVersion: v1 - kind: ServiceAccount - metadata: - name: infisical-auth - namespace: default + + + **1.1.** Start by creating a reviewer service account in your Kubernetes cluster that will be used by Infisical to authenticate with the Kubernetes API Server. - ``` + ```yaml infisical-reviewer-service-account.yaml + apiVersion: v1 + kind: ServiceAccount + metadata: + name: infisical-token-reviewer + namespace: default - ``` - kubectl apply -f infisical-service-account.yaml - ``` + ``` - 1.2. Bind the service account to the `system:auth-delegator` cluster role. As described [here](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#other-component-roles), this role allows delegated authentication and authorization checks, specifically for Infisical to access the [TokenReview API](https://kubernetes.io/docs/reference/kubernetes-api/authentication-resources/token-review-v1/). You can apply the following configuration file: + ```bash + kubectl apply -f infisical-reviewer-service-account.yaml + ``` - ```yaml cluster-role-binding.yaml - apiVersion: rbac.authorization.k8s.io/v1 - kind: ClusterRoleBinding - metadata: - name: role-tokenreview-binding - namespace: default - roleRef: - apiGroup: rbac.authorization.k8s.io - kind: ClusterRole - name: system:auth-delegator - subjects: - - kind: ServiceAccount - name: infisical-auth - namespace: default - ``` + **1.2.** Bind the reviewer service account to the `system:auth-delegator` cluster role. As described [here](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#other-component-roles), this role allows delegated authentication and authorization checks, specifically for Infisical to access the [TokenReview API](https://kubernetes.io/docs/reference/kubernetes-api/authentication-resources/token-review-v1/). You can apply the following configuration file: - ``` - kubectl apply -f cluster-role-binding.yaml - ``` + ```yaml infisical-reviewer-cluster-role-binding.yaml + apiVersion: rbac.authorization.k8s.io/v1 + kind: ClusterRoleBinding + metadata: + name: infisical-token-reviewer-role-binding + namespace: default + roleRef: + apiGroup: rbac.authorization.k8s.io + kind: ClusterRole + name: system:auth-delegator + subjects: + - kind: ServiceAccount + name: infisical-token-reviewer + namespace: default + ``` - 1.3. Next, create a long-lived service account JWT token (i.e. the token reviewer JWT token) for the service account using this configuration file for a new `Secret` resource: + ```bash + kubectl apply -f infisical-reviewer-cluster-role-binding.yaml + ``` - ```yaml service-account-token.yaml - apiVersion: v1 - kind: Secret - type: kubernetes.io/service-account-token - metadata: - name: infisical-auth-token - annotations: - kubernetes.io/service-account.name: "infisical-auth" - ``` + **1.3.** Next, create a long-lived service account JWT token (i.e. the token reviewer JWT token) for the service account using this configuration file for a new `Secret` resource: + + ```yaml service-account-reviewer-token.yaml + apiVersion: v1 + kind: Secret + type: kubernetes.io/service-account-token + metadata: + name: infisical-token-reviewer-token + annotations: + kubernetes.io/service-account.name: "infisical-token-reviewer" + ``` - ``` - kubectl apply -f service-account-token.yaml - ``` + ```bash + kubectl apply -f service-account-reviewer-token.yaml + ``` - 1.4. Link the secret in step 1.3 to the service account in step 1.1: + **1.4.** Link the secret in step 1.3 to the service account in step 1.1: - ```bash - kubectl patch serviceaccount infisical-auth -p '{"secrets": [{"name": "infisical-auth-token"}]}' -n default - ``` + ```bash + kubectl patch serviceaccount infisical-token-reviewer -p '{"secrets": [{"name": "infisical-token-reviewer-token"}]}' -n default + ``` - 1.5. Finally, retrieve the token reviewer JWT token from the secret. + **1.5.** Finally, retrieve the token reviewer JWT token from the secret. - ```bash - kubectl get secret infisical-auth-token -n default -o=jsonpath='{.data.token}' | base64 --decode - ``` + ```bash + kubectl get secret infisical-token-reviewer-token -n default -o=jsonpath='{.data.token}' | base64 --decode + ``` - Keep this JWT token handy as you will need it for the **Token Reviewer JWT** field when configuring the Kubernetes Auth authentication method for the identity in step 2. + Keep this JWT token handy as you will need it for the **Token Reviewer JWT** field when configuring the Kubernetes Auth authentication method for the identity in step 2. + - + + To create an identity, head to your Organization Settings > Access Control > Machine Identities and press **Create identity**. - - To create an identity, head to your Organization Settings > Access Control > Machine Identities and press **Create identity**. + ![identities organization](/images/platform/identities/identities-org.png) - ![identities organization](/images/platform/identities/identities-org.png) + When creating an identity, you specify an organization level [role](/documentation/platform/role-based-access-controls) for it to assume; you can configure roles in Organization Settings > Access Control > Organization Roles. - When creating an identity, you specify an organization level [role](/documentation/platform/role-based-access-controls) for it to assume; you can configure roles in Organization Settings > Access Control > Organization Roles. + ![identities organization create](/images/platform/identities/identities-org-create.png) - ![identities organization create](/images/platform/identities/identities-org-create.png) + Now input a few details for your new identity. Here's some guidance for each field: - Now input a few details for your new identity. Here's some guidance for each field: + - Name (required): A friendly name for the identity. + - Role (required): A role from the **Organization Roles** tab for the identity to assume. The organization role assigned will determine what organization level resources this identity can have access to. - - Name (required): A friendly name for the identity. - - Role (required): A role from the **Organization Roles** tab for the identity to assume. The organization role assigned will determine what organization level resources this identity can have access to. + Once you've created an identity, you'll be prompted to configure the authentication method for it. Here, select **Kubernetes Auth**. - Once you've created an identity, you'll be prompted to configure the authentication method for it. Here, select **Kubernetes Auth**. + + To learn more about each field of the Kubernetes native authentication method, see step 2 of [guide](/documentation/platform/identities/kubernetes-auth#guide). + - - To learn more about each field of the Kubernetes native authentication method, see step 2 of [guide](/documentation/platform/identities/kubernetes-auth#guide). - - - ![identities organization create auth method](/images/platform/identities/identities-org-create-kubernetes-auth-method.png) + ![identities organization create auth method](/images/platform/identities/identities-org-create-kubernetes-auth-method.png) - - - To allow the operator to use the given identity to access secrets, you will need to add the identity to project(s) that you would like to grant it access to. + + + To allow the operator to use the given identity to access secrets, you will need to add the identity to project(s) that you would like to grant it access to. - To do this, head over to the project you want to add the identity to and go to Project Settings > Access Control > Machine Identities and press **Add identity**. + To do this, head over to the project you want to add the identity to and go to Project Settings > Access Control > Machine Identities and press **Add identity**. - Next, select the identity you want to add to the project and the project level role you want to allow it to assume. The project role assigned will determine what project level resources this identity can have access to. + Next, select the identity you want to add to the project and the project level role you want to allow it to assume. The project role assigned will determine what project level resources this identity can have access to. - ![identities project](/images/platform/identities/identities-project.png) + ![identities project](/images/platform/identities/identities-project.png) - ![identities project create](/images/platform/identities/identities-project-create.png) + ![identities project create](/images/platform/identities/identities-project-create.png) - - - Once you have created your machine identity and added it to your project(s), you will need to add the identity ID to your InfisicalSecret resource. - In the `authentication.kubernetesAuth.identityId` field, add the identity ID of the machine identity you created. - See the example below for more details. - - - Add the service account details from the previous steps under `authentication.kubernetesAuth.serviceAccountRef`. - Here you will need to enter the name and namespace of the service account. - The example below shows a complete InfisicalSecret resource with all required fields defined. - + - + + You have already created the reviewer service account in step **1.1**. Now, create a new Kubernetes service account that will be used to authenticate with Infisical. + This service account will create short-lived tokens that will be used to authenticate with Infisical. The operator itself will handle the creation of these tokens automatically. - - Make sure to also populate the `secretsScope` field with the project slug - _`projectSlug`_, environment slug _`envSlug`_, and secrets path - _`secretsPath`_ that you want to fetch secrets from. Please see the example - below. - + ```yaml infisical-service-account.yaml + kind: ServiceAccount + apiVersion: v1 + metadata: + name: infisical-service-account + ``` -## Example + ```bash + kubectl apply -f infisical-service-account.yaml -n default + ``` -```yaml example-kubernetes-auth.yaml -apiVersion: secrets.infisical.com/v1alpha1 -kind: InfisicalSecret -metadata: - name: infisicalsecret-sample-crd -spec: - authentication: - kubernetesAuth: - identityId: - serviceAccountRef: - name: - namespace: + - # secretsScope is identical to the secrets scope in the universalAuth field in this sample. - secretsScope: - projectSlug: your-project-slug - envSlug: prod - secretsPath: "/path" - recursive: true - ... -``` + + Once you have created your machine identity and added it to your project(s), you will need to add the identity ID to your InfisicalSecret resource. + In the `authentication.kubernetesAuth.identityId` field, add the identity ID of the machine identity you created. + See the example below for more details. + + + Add the service account details from the previous steps under `authentication.kubernetesAuth.serviceAccountRef`. + Here you will need to enter the name and namespace of the service account. + The example below shows a complete InfisicalSecret resource with all required fields defined. + Make sure you set `authentication.kubernetesAuth.autoCreateServiceAccountToken` to `true` to automatically create short-lived service account tokens for the service account. + + + + + Make sure to also populate the `secretsScope` field with the project slug + _`projectSlug`_, environment slug _`envSlug`_, and secrets path + _`secretsPath`_ that you want to fetch secrets from. Please see the example + below. + + + ## Example + + ```yaml example-kubernetes-auth.yaml + apiVersion: secrets.infisical.com/v1alpha1 + kind: InfisicalSecret + metadata: + name: infisicalsecret-sample-crd + spec: + authentication: + kubernetesAuth: + identityId: + autoCreateServiceAccountToken: true # Automatically creates short-lived service account tokens for the service account. + serviceAccountTokenAudiences: + - # Optionally specify audience for the service account token. No audience is specified by default. + serviceAccountRef: + name: infisical-service-account # The service account we just created in the previous step. + namespace: + + # secretsScope is identical to the secrets scope in the universalAuth field in this sample. + secretsScope: + projectSlug: your-project-slug + envSlug: prod + secretsPath: "/path" + recursive: true + ... + ``` + + + + Manual long-lived service account tokens are manually created by the user and are valid indefinitely unless deleted or rotated. In most cases, you should be using the automatic short-lived service account tokens as they are more secure and easier to use. + + + **1.1.** Start by creating a reviewer service account in your Kubernetes cluster that will be used by Infisical to authenticate with the Kubernetes API Server. + + ```yaml infisical-reviewer-service-account.yaml + apiVersion: v1 + kind: ServiceAccount + metadata: + name: infisical-token-reviewer + namespace: default + + ``` + + ```bash + kubectl apply -f infisical-reviewer-service-account.yaml + ``` + + **1.2.** Bind the reviewer service account to the `system:auth-delegator` cluster role. As described [here](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#other-component-roles), this role allows delegated authentication and authorization checks, specifically for Infisical to access the [TokenReview API](https://kubernetes.io/docs/reference/kubernetes-api/authentication-resources/token-review-v1/). You can apply the following configuration file: + + ```yaml infisical-reviewer-cluster-role-binding.yaml + apiVersion: rbac.authorization.k8s.io/v1 + kind: ClusterRoleBinding + metadata: + name: infisical-token-reviewer-role-binding + namespace: default + roleRef: + apiGroup: rbac.authorization.k8s.io + kind: ClusterRole + name: system:auth-delegator + subjects: + - kind: ServiceAccount + name: infisical-token-reviewer + namespace: default + ``` + + ```bash + kubectl apply -f infisical-reviewer-cluster-role-binding.yaml + ``` + + **1.3.** Next, create a long-lived service account JWT token (i.e. the token reviewer JWT token) for the service account using this configuration file for a new `Secret` resource: + + ```yaml service-account-reviewer-token.yaml + apiVersion: v1 + kind: Secret + type: kubernetes.io/service-account-token + metadata: + name: infisical-token-reviewer-token + annotations: + kubernetes.io/service-account.name: "infisical-token-reviewer" + ``` + + + ```bash + kubectl apply -f service-account-reviewer-token.yaml + ``` + + **1.4.** Link the secret in step 1.3 to the service account in step 1.1: + + ```bash + kubectl patch serviceaccount infisical-token-reviewer -p '{"secrets": [{"name": "infisical-token-reviewer-token"}]}' -n default + ``` + + **1.5.** Finally, retrieve the token reviewer JWT token from the secret. + + ```bash + kubectl get secret infisical-token-reviewer-token -n default -o=jsonpath='{.data.token}' | base64 --decode + ``` + + Keep this JWT token handy as you will need it for the **Token Reviewer JWT** field when configuring the Kubernetes Auth authentication method for the identity in step 2. + + + + To create an identity, head to your Organization Settings > Access Control > Machine Identities and press **Create identity**. + + ![identities organization](/images/platform/identities/identities-org.png) + + When creating an identity, you specify an organization level [role](/documentation/platform/role-based-access-controls) for it to assume; you can configure roles in Organization Settings > Access Control > Organization Roles. + + ![identities organization create](/images/platform/identities/identities-org-create.png) + + Now input a few details for your new identity. Here's some guidance for each field: + + - Name (required): A friendly name for the identity. + - Role (required): A role from the **Organization Roles** tab for the identity to assume. The organization role assigned will determine what organization level resources this identity can have access to. + + Once you've created an identity, you'll be prompted to configure the authentication method for it. Here, select **Kubernetes Auth**. + + + To learn more about each field of the Kubernetes native authentication method, see step 2 of [guide](/documentation/platform/identities/kubernetes-auth#guide). + + + ![identities organization create auth method](/images/platform/identities/identities-org-create-kubernetes-auth-method.png) + + + + + To allow the operator to use the given identity to access secrets, you will need to add the identity to project(s) that you would like to grant it access to. + + To do this, head over to the project you want to add the identity to and go to Project Settings > Access Control > Machine Identities and press **Add identity**. + + Next, select the identity you want to add to the project and the project level role you want to allow it to assume. The project role assigned will determine what project level resources this identity can have access to. + + ![identities project](/images/platform/identities/identities-project.png) + + ![identities project create](/images/platform/identities/identities-project-create.png) + + + + + You have already created the reviewer service account in step **1.1**. Now, create a new Kubernetes service account that will be used to authenticate with Infisical. + + ```yaml infisical-service-account.yaml + kind: ServiceAccount + apiVersion: v1 + metadata: + name: infisical-service-account + ``` + + ```bash + kubectl apply -f infisical-service-account.yaml -n default + ``` + + + + Create a service account token for the newly created Kubernetes service account from the previous step. + + ```yaml infisical-service-account-token.yaml + apiVersion: v1 + kind: Secret + type: kubernetes.io/service-account-token + metadata: + name: infisical-service-account-token + annotations: + kubernetes.io/service-account.name: "infisical-service-account" + ``` + + ```bash + kubectl apply -f infisical-service-account-token.yaml -n default + ``` + + Patch the service account with the newly created service account token. + + ```bash + kubectl patch serviceaccount infisical-service-account -p '{"secrets": [{"name": "infisical-service-account-token"}]}' -n default + ``` + + + + Once you have created your machine identity and added it to your project(s), you will need to add the identity ID to your InfisicalSecret resource. + In the `authentication.kubernetesAuth.identityId` field, add the identity ID of the machine identity you created. + See the example below for more details. + + + Add the service account details from the previous steps under `authentication.kubernetesAuth.serviceAccountRef`. + Here you will need to enter the name and namespace of the service account. + The example below shows a complete InfisicalSecret resource with all required fields defined. + + + + + Make sure to also populate the `secretsScope` field with the project slug + _`projectSlug`_, environment slug _`envSlug`_, and secrets path + _`secretsPath`_ that you want to fetch secrets from. Please see the example + below. + + + ## Example + + ```yaml example-kubernetes-auth.yaml + apiVersion: secrets.infisical.com/v1alpha1 + kind: InfisicalSecret + metadata: + name: infisicalsecret-sample-crd + spec: + authentication: + kubernetesAuth: + identityId: + serviceAccountRef: + name: infisical-service-account # The service account we just created in the previous step. (*not* the reviewer service account) + namespace: + + # secretsScope is identical to the secrets scope in the universalAuth field in this sample. + secretsScope: + projectSlug: your-project-slug + envSlug: prod + secretsPath: "/path" + recursive: true + ... + ``` + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/k8-operator/.gitignore b/k8-operator/.gitignore index e917e5cefe..8f80e8ef55 100644 --- a/k8-operator/.gitignore +++ b/k8-operator/.gitignore @@ -24,3 +24,6 @@ Dockerfile.cross *.swp *.swo *~ + +# Testing directories +auto-token \ No newline at end of file diff --git a/k8-operator/api/v1alpha1/common.go b/k8-operator/api/v1alpha1/common.go index 3c94b8ab04..2362857d82 100644 --- a/k8-operator/api/v1alpha1/common.go +++ b/k8-operator/api/v1alpha1/common.go @@ -51,7 +51,7 @@ type GenericKubernetesAuth struct { ServiceAccountRef KubernetesServiceAccountRef `json:"serviceAccountRef"` // Optionally automatically create a service account token for the configured service account. - // If this is set to `true`, the operator will automatically create a service account token for the configured service account. + // If this is set to `true`, the operator will automatically create a service account token for the configured service account. This field is recommended in most cases. // +kubebuilder:validation:Optional AutoCreateServiceAccountToken bool `json:"autoCreateServiceAccountToken"` // The audiences to use for the service account token. This is only relevant if `autoCreateServiceAccountToken` is true. diff --git a/k8-operator/packages/util/auth.go b/k8-operator/packages/util/auth.go index ec4b0f9206..7305ca45e0 100644 --- a/k8-operator/packages/util/auth.go +++ b/k8-operator/packages/util/auth.go @@ -19,10 +19,6 @@ import ( func GetServiceAccountToken(k8sClient client.Client, namespace string, serviceAccountName string, autoCreateServiceAccountToken bool, serviceAccountTokenAudiences []string) (string, error) { if autoCreateServiceAccountToken { - if len(serviceAccountTokenAudiences) == 0 { - return "", fmt.Errorf("serviceAccountTokenAudiences is required when autoCreateServiceAccountToken is true") - } - restClient, err := GetRestClientFromClient() if err != nil { return "", fmt.Errorf("failed to get REST client: %w", err) @@ -30,11 +26,16 @@ func GetServiceAccountToken(k8sClient client.Client, namespace string, serviceAc tokenRequest := &authenticationv1.TokenRequest{ Spec: authenticationv1.TokenRequestSpec{ - Audiences: serviceAccountTokenAudiences, ExpirationSeconds: ptr.Int64(600), // 10 minutes. the token only needs to be valid for when we do the initial k8s login. }, } + if len(serviceAccountTokenAudiences) > 0 { + // Conditionally add the audiences if they are specified. + // Failing to do this causes a default audience to be used, which is not what we want if the user doesn't specify any. + tokenRequest.Spec.Audiences = serviceAccountTokenAudiences + } + result := &authenticationv1.TokenRequest{} err = restClient. Post().