v0.5.2

Commands Affected

Any command that auths to Kubernetes API.

Description

You can now specify the kubernetes config path to use using the environment variable KUBECONFIG.

Special Thanks

Special thanks to @KyleMartin901 for their contribution!

Reference

• #59

v0.5.1

Commands Affected

Any command that requires TLS subject info.

Description

The TLS subject info JSON previously only allowed one name for some of the fields (e.g org for organization), but it now allows using alternate names:

• Common Name: common_name
• Organization: org OR organization
• Organizational Unit: org_unit OR organizational_unit
• City: city OR locality
• State: state OR province
• Country: country

Reference

• #57

v0.5.0

Commands Affected

• helm grant
• helm revoke

Description

This release makes the labels used to tag the Kubernetes resources more robust so that they fit within the constraints of the label system. For example, this will modify special characters before including them into as labels.

WARNING: This revoke command is incompatible with any grant commands that were run before this version. See the "Migration Notes" for details on how to revoke access to already granted entities.

Migration Notes

The revoke command depends on labels that are set on the Role, RoleBinding, and Secret to be able to find them for deletion. The new labels are incompatible with the previous versions, preventing you from revoking entities that were granted prior to this version.

However, entities granted access on v0.4.0 can be revoked using the kubergrunt helm revoke command from v0.4.0.

Reference

• #55

v0.4.0

Commands Affected

• helm grant
• helm revoke [NEW]

Description

This release introduces the helm revoke command, which will remove access to Tiller from the specified RBAC entities. This is done by removing:

• The RoleBinding that binds permissions to access the Kubernetes Secret containing the TLS key pair and the Tiller Pod.
• The Role that grants permissions to access the Kubernetes Secret containing the TLS key pair and the Tiller Pod.
• The Kubernetes Secret containing the client TLS certificate.

To support the revoke action, this release updates the grant command to add labels to the Role, RoleBinding, and Secret that is generated.

WARNING: This revoke command is incompatible with any grant commands that were run before this version. See the "Migration Notes" for details on how to revoke access to already granted entities.

NOTE: This revoke command does not mark the TLS certificate as unusable. This means that if the entity is able to open a connection to the Tiller pod, they will be able to reuse the certificate. For a full revocation, you will need to reissue the certificates under a new CA that is installed in the Tiller pod.

Migration Notes

The revoke command depends on labels that are set on the Role, RoleBinding, and Secret to be able to find them for deletion. Previous versions of kubergrunt did not set labels on these resources during the grant operation, making them incompatible with the implementation of revoke. If you wish to revoke access to entities that were granted access using a previous version of grant, follow these steps:

• Get the entity name. For RBAC Users and Groups, this is the name of the User or Group. For ServiceAccounts, this will be the string NAMESPACE/NAME, where NAMESPACE is the namespace where the ServiceAccount is defined, and NAME is the name of the ServiceAccount.
• Take the entity name and generate a md5 hash of the string. We will refer to this as the environment variable ENTITY_ID_MD5.
• Record the name of the tiller namespace in the environment variable TILLER_NAMESPACE.
• Delete the objects using kubectl:

kubectl delete rolebinding "$ENTITY_ID_MD5-$ENTITY_ID_MD5-$TILLER_NAMESPACE-tiller-access-binding" -n "$TILLER_NAMESPACE"
kubectl delete role "$ENTITY_ID_MD5-$TILLER_NAMESPACE-tiller-access" -n "$TILLER_NAMESPACE"
kubectl delete secret "tiller-client-$ENTITY_ID_MD5-certs" -n "$TILLER_NAMESPACE"

Special Thanks

Special thanks to @bwhaley for their contribution!

Reference

• #50
• #51

v0.3.9

Commands Affected

• helm configure
• Any commands that accept TLS configurations

Description

This release updates kubergrunt helm configure with a new option --as-tf-data, which enables you to call it in an external data source. Passing this flag will cause the command to output the configured helm home directory in the output json on stdout at the end of the command.

Additionally, kubergrunt helm configure now supports a new option you can set for --helm-home (E.g --helm-home __TMP__) to inform kubergrunt that you intend to use a tmp directory for the configured helm home directory. Passing this option in will cause the command to generate a new directory in the tmp folder for the platform to use as the helm home.

The above two features, when used in combination, allows you to dynamically configure the helm provider on the host machine in Terraform.

Finally, this release also updates the TLS subject json parsing for the CLI such that it can accept equivalent arg names in the terraform TLS subject block: https://www.terraform.io/docs/providers/tls/r/cert_request.html#common_name

Reference

• #47
• #46

v0.3.8

Commands Affected

• tls gen
• helm wait-for-tiller [NEW]

Description

This release updates the tls gen command to use the new way of authenticating to Kubernetes (specifically passing in server and token info directly) and using JSON to configure the TLS subject.

This release also introduces a new command helm wait-for-tiller which can be used to wait for a tiller deployment to roll out Pods, and have at least one Pod that can be pinged. This enables chaining calls to helm after helm is deployed when using a different helm deployment process that doesn't rely on the helm client (e.g creating deployment resources manually).

Reference

• #44

v0.3.7

Commands Affected

• k8s wait-for-ingress [NEW]

Description

This release introduces the k8s wait-for-ingress sub command which can be used to wait until an Ingress resource has an endpoint associated with it.

Reference

• #43

v0.3.6

Description

All commands that setup TLS certificates (e.g helm deploy and helm grant) can now take in the TLS subject information as a json.

Reference

• #40

v0.3.5

Description

All commands that need to authenticate to Kubernetes (e.g eks deploy, helm deploy, etc) now take in direct authentication parameters as an alternative means to auth. You can now pass in the authentication parameters --kubectl-server-endpoint, --kubectl-certificate-authority and --kubectl-token to the command to setup authentication to the Kubernetes cluster, as opposed to setting up the config.

Reference

• #38
• #39

v0.3.4

Commands Affected

• eks token

Description

The eks token command now accepts a new parameter --as-tf-data, which will encode the token output in a format that can be used as an external data source in terraform. This allows you to configure the kubernetes and helm providers without configuring a kubectl context.

Reference

• #37