Kubernetes

Overview

Feedback
Secure Access Management: Instead of using long-lived service account tokens, you can generate short-lived tokens that automatically expire, reducing the risk of token exposure.
Feedback
Temporary Access: Generate tokens with specific TTLs (Time To Live) for temporary access to your Kubernetes clusters.
Feedback
Audit Trail: Each token generation is tracked, providing better visibility into who accessed your cluster and when.
Feedback
Integration with Private Clusters: Seamlessly work with private Kubernetes clusters using Hanzo KMS's Gateway feature.

Kubernetes service account tokens cannot be revoked once issued. This is why it's important to use short TTLs and carefully manage token generation. The tokens will automatically expire after their TTL period.

Kubernetes service account tokens are JWTs (JSON Web Tokens) with a fixed expiration time. Once a token is generated, its lifetime cannot be extended. If you need longer access, you'll need to generate a new token.

Feedback
Provide temporary access to developers or CI/CD pipelines
Feedback
Rotate service account tokens frequently
Feedback
Maintain a secure audit trail of cluster access
Feedback
Manage access to multiple Kubernetes clusters

Set up Dynamic Secrets with Kubernetes

Open the Secret Overview dashboard and select the environment in which you would like to add a dynamic secret.

Before proceeding with the setup, you'll need to make two key decisions:

1. Credential Type: How you want to manage service accounts

   • Static: Use an existing service account with predefined permissions
   • Dynamic: Create temporary service accounts with specific role assignments

2. Authentication Method: How you want to authenticate with the cluster

   • Token (API): Use a service account token for direct API access
   • Gateway: Use an KMS Gateway deployed in your cluster

Static credentials generate service account tokens for a predefined service account. This is useful when you want to:

• Generate tokens for an existing service account
• Maintain consistent permissions across token generations
• Use a service account that already has the necessary RBAC permissions

Prerequisites

• A Kubernetes cluster with a service account
• Cluster access token with permissions to create service account tokens
• (Optional) Gateway for private cluster access

Authentication Setup

Choose your authentication method:

This method uses a service account token to authenticate with the Kubernetes cluster. It's suitable when:

• You want to use a specific service account token that you've created
• You're working with a public cluster or have network access to the cluster's API server
• You want to explicitly control which service account is used for operations

With Token (API) authentication, Hanzo KMS uses the provided service account token to make API calls to your Kubernetes cluster. This token must have the necessary permissions to generate tokens for the target service account.

1. Create a service account:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: kms-token-requester
  namespace: default

kubectl apply -f kms-service-account.yaml

2. Set up RBAC permissions:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: tokenrequest
rules:
  - apiGroups: [""]
    resources:
      - "serviceaccounts/token"
      - "serviceaccounts"
    verbs:
      - "create"
      - "get"
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: tokenrequest
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: tokenrequest
subjects:
  - kind: ServiceAccount
    name: kms-token-requester
    namespace: default

kubectl apply -f rbac.yaml

3. Create and obtain the token:

apiVersion: v1
kind: Secret
type: kubernetes.io/service-account-token
metadata:
  name: kms-token-requester-token
  annotations:
    kubernetes.io/service-account.name: "kms-token-requester"

kubectl apply -f service-account-token.yaml
kubectl patch serviceaccount kms-token-requester -p '{"secrets": [{"name": "kms-token-requester-token"}]}' -n default
kubectl get secret kms-token-requester-token -n default -o=jsonpath='{.data.token}' | base64 --decode

This method uses an KMS Gateway deployed in your Kubernetes cluster. It's ideal when:

• You want to avoid storing static service account tokens
• You prefer to use the Gateway's pre-configured service account
• You want centralized management of cluster operations

With Gateway authentication, Hanzo KMS communicates with the Gateway, which then uses its own service account to make API calls to the Kubernetes API server. The Gateway's service account must have the necessary permissions to generate tokens for the target service account.

When using Gateway authentication, the Gateway will access the Kubernetes API server using its internal cluster URL (typically https://kubernetes.default.svc) and TLS configuration. You don't need to specify these values separately in the dynamic secret configuration.

1. Deploy the KMS Gateway in your cluster
2. Set up RBAC permissions for the Gateway's service account:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: tokenrequest
rules:
  - apiGroups: [""]
    resources:
      - "serviceaccounts/token"
      - "serviceaccounts"
    verbs:
      - "create"
      - "get"
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: tokenrequest
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: tokenrequest
subjects:
  - kind: ServiceAccount
    name: kms-gateway
    namespace: kms

kubectl apply -f rbac.yaml

Dynamic credentials create a temporary service account, assign it to a defined role/cluster-role, and generate a service account token. This is useful when you want to:

• Create temporary service accounts with specific permissions
• Automatically clean up service accounts after token expiration
• Assign different roles to different users or applications
• Maintain strict control over service account permissions
• Support multiple namespaces with a single dynamic secret configuration

Prerequisites

• A Kubernetes cluster with a service account
• Cluster access token with permissions to create service accounts and manage RBAC
• (Optional) Gateway for private cluster access

Namespace Support

When configuring a dynamic secret, you can specify multiple allowed namespaces as a comma-separated list. During lease creation, you can then specify which namespace to use from this allowed list. This provides flexibility while maintaining security by:

• Allowing a single dynamic secret configuration to support multiple namespaces
• Restricting service account creation to only the specified allowed namespaces
• Enabling fine-grained control over which namespaces can be used for each lease

For example, if you configure a dynamic secret with allowed namespaces "default,kube-system,monitoring", you can create leases that use any of these namespaces while preventing access to other namespaces in your cluster.

Authentication Setup

Choose your authentication method:

This method uses a service account token to authenticate with the Kubernetes cluster. It's suitable when:

• You want to use a specific service account token that you've created
• You're working with a public cluster or have network access to the cluster's API server
• You want to explicitly control which service account is used for operations

With Token (API) authentication, Hanzo KMS uses the provided service account token to make API calls to your Kubernetes cluster. This token must have the necessary permissions to create and manage service accounts, their tokens, and RBAC resources.

1. Create a service account:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: kms-token-requester
  namespace: default
---
apiVersion: v1
kind: Secret
type: kubernetes.io/service-account-token
metadata:
  name: kms-token-requester-token
  annotations:
    kubernetes.io/service-account.name: "kms-token-requester"

kubectl apply -f service-account.yaml

2. Set up RBAC permissions:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: tokenrequest
rules:
  - apiGroups: [""]
    resources:
      - "serviceaccounts/token"
      - "serviceaccounts"
    verbs:
      - "create"
      - "get"
      - "delete"
  - apiGroups: ["rbac.authorization.k8s.io"]
    resources:
      - "rolebindings"
      - "clusterrolebindings"
    verbs:
      - "create"
      - "delete"
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: tokenrequest
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: tokenrequest
subjects:
  - kind: ServiceAccount
    name: kms-token-requester
    namespace: default
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: kms-dynamic-role-binding-sa
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: kms-dynamic-role
subjects:
  - kind: ServiceAccount
    name: kms-token-requester
    namespace: default

kubectl apply -f rbac.yaml

This method uses an KMS Gateway deployed in your Kubernetes cluster. It's ideal when:

• You want to avoid storing static service account tokens
• You prefer to use the Gateway's pre-configured service account
• You want centralized management of cluster operations

With Gateway authentication, Hanzo KMS communicates with the Gateway, which then uses its own service account to make API calls to the Kubernetes API server. The Gateway's service account must have the necessary permissions to create and manage service accounts, their tokens, and RBAC resources.

When using Gateway authentication, the Gateway will access the Kubernetes API server using its internal cluster URL (typically https://kubernetes.default.svc) and TLS configuration. You don't need to specify these values separately in the dynamic secret configuration.

1. Deploy the KMS Gateway in your cluster
2. Set up RBAC permissions for the Gateway's service account:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: tokenrequest
rules:
  - apiGroups: [""]
    resources:
      - "serviceaccounts/token"
      - "serviceaccounts"
    verbs:
      - "create"
      - "get"
      - "delete"
  - apiGroups: ["rbac.authorization.k8s.io"]
    resources:
      - "rolebindings"
      - "clusterrolebindings"
    verbs:
      - "create"
      - "delete"
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: tokenrequest
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: tokenrequest
subjects:
  - kind: ServiceAccount
    name: kms-gateway
    namespace: kms
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: kms-dynamic-role-binding-sa
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: kms-dynamic-role
subjects:
  - kind: ServiceAccount
    name: kms-gateway
    namespace: kms

kubectl apply -f rbac.yaml

In Kubernetes RBAC, a service account can only create role bindings for resources that it has access to. This means that if you want to create dynamic service accounts with access to certain resources, the service account creating these bindings (either the token requester or Gateway service account) must also have access to those same resources. For example, if you want to create dynamic service accounts that can access secrets, the token requester service account must also have access to secrets.

Name by which you want the secret to be referenced

Default time-to-live for a generated secret (it is possible to modify this value after a secret is generated)

Maximum time-to-live for a generated secret

Select a gateway for private cluster access. If not specified, the Internet Gateway will be used.

Kubernetes API server URL (e.g., https://kubernetes.default.svc). Not required when using Gateway authentication as the Gateway will use its internal cluster URL.

Whether to enable SSL verification for the Kubernetes API server connection. Not required when using Gateway authentication as the Gateway will use its internal TLS configuration.

Custom CA certificate for the Kubernetes API server. Leave blank to use the system/public CA. Not required when using Gateway authentication as the Gateway will use its internal TLS configuration.

Choose between Token (API) or Gateway authentication. If using Gateway, the Gateway must be deployed in your Kubernetes cluster.

Token with permissions to create service accounts and manage RBAC (required when using Token authentication)

Choose between Static (predefined service account) or Dynamic (temporary service accounts with role assignments)

Name of the service account to generate tokens for

Kubernetes namespace where the service account exists

Kubernetes namespace(s) where the service accounts will be created. You can specify multiple namespaces as a comma-separated list (e.g., "default,kube-system"). During lease creation, you can specify which namespace to use from this allowed list.

Type of role to assign (ClusterRole or Role)

Name of the role to assign to the temporary service account

Optional list of audiences to include in the generated token

After submitting the form, you will see a dynamic secret created in the dashboard.

Generate and Manage Tokens

Ensure that the TTL for the lease falls within the maximum TTL defined when configuring the dynamic secret.

Audit or Revoke Leases

While you can delete the lease from Hanzo KMS, the actual Kubernetes service account token cannot be revoked. The token will remain valid until its TTL expires. This is why it's crucial to use appropriate TTL values when generating tokens.