/
moving-service-accounts-to-terraform.html.md.erb
144 lines (110 loc) · 6.79 KB
/
moving-service-accounts-to-terraform.html.md.erb
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
---
title: Moving from YAML defined Service Accounts to Terraform module
last_reviewed_on: 2024-01-30
review_in: 6 months
layout: google-analytics
---
# <%= current_page.data.title %>
>This page is intended for users of the Cloud Platform who still have Kubernetes Service Accounts defined in `yaml`, and how to remove these in favour of Terraform module based Service Accounts.
## Background
As of Kubernetes version 1.24 (Cloud Platform cluster upgrade completed July 2023), Kubernetes `ServiceAccount` resources no longer automatically create an associated `Secret` for your service account's token.
In light of this change, the team made the decision to deprecate the use of YAML defined Service Accounts in favour of the [cloud-platform-terraform-serviceaccount](https://github.com/ministryofjustice/cloud-platform-terraform-serviceaccount/tree/main)
module, which creates the required token Secret for you. You can refer to the original Slack notification for this change [here](https://mojdt.slack.com/archives/CH6D099DF/p1689959699343999).
At the time of writing, over 300 YAML defined Service Account resources still exist in the [cloud-platform-environments](https://github.com/ministryofjustice/cloud-platform-environments) repository, and whilst they will continue to work if preserved, any changes (intentional or otherwise)
will result in the Service Account no longer working as expected.
This guide will help you switch your Service Account(s) to use the Terraform module, and cleanly remove all legacy YAML defined Service Accounts and their associated resources.
## Moving to the Terraform module
>We recommend that you create new Service Accounts via the Terraform module prior to removing the YAML defined Service Account. This will ensure that your application / pipelines continue working until the new credentials are generated and updated where required.
### Creating a new Service Account
Follow the steps detailed [here](https://user-guide.cloud-platform.service.justice.gov.uk/documentation/getting-started/cloud-platform-cli.html#add-a-service-account-to-your-namespace) to create a Terraform module based Service Account.
>Note the module defines [default values](https://github.com/ministryofjustice/cloud-platform-terraform-serviceaccount?tab=readme-ov-file#input_role_name) for the name of your new Service Account, and the associated Role and Rolebinding resources. If you intend to change these values, it is recommended you first [capture
the values of your old YAML defined resources](#find-the-names-of-your-service-account-and-associated-resources), to ensure there is no clash between the old and new resources at deployment time.
## Service Account best practice
At Cloud Platform we encourage users to create and manage their Service Accounts (sa) and associated tokens via our terraform module. The module handles role, role binding, token creation and token rotation. We have not completely blocked creation of sa via kubectl or by helm but would encourage users to create the service account via the module and then pass the created sa to the relevant places eg. helm chart via `values.yaml`.
here is an example from a [redis helm chart](https://github.com/bitnami/charts/blob/main/bitnami/redis/values.yaml):
```yaml
serviceAccount:
## @param master.serviceAccount.create Specifies whether a ServiceAccount should be created
##
create: false
## @param master.serviceAccount.name The name of the ServiceAccount to use.
## If not set and create is true, a name is generated using the common.names.fullname template
##
name: "$YOUR_PREVIOUSLY_CREATED_SERVICE_ACCOUNT_NAME_HERE"
## @param master.serviceAccount.automountServiceAccountToken Whether to auto mount the service account token
## ref: https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#use-the-default-service-account-to-access-the-api-server
##
automountServiceAccountToken: false
## @param master.serviceAccount.annotations Additional custom annotations for the ServiceAccount
##
annotations: {}
```
### Obtain the new Service Account credentials
If you are using the Service Account token in an external application, such as CircleCI, you will need to obtain the new token and also `ca.crt` content for your Service Account, and update the application to use the new token.
You can obtain the `ca.crt` and token using the following commands:
```bash
kubectl -n <your-namespace> get secret <name-of-serviceaccount-secret> -o json | jq -r '.data."ca.crt"'
```
>Note - CircleCI does not accept the `ca.crt base64` decoded value as an environment variable, so run the above command to get the encoded `ca.crt` value and handle the decode within your pipeline logic.
Use the `cloud-platform decode-secret` CLI tool to view and Base64-decode the token:
```bash
cloud-platform decode-secret -n <your-namespace> -s <name-of-serviceaccount-secret> | jq -r '.data."token"'
```
Now you have these values, you can update your application / pipeline to use the new credentials.
## Removing the YAML defined Service Account
#### Find the names of your Service Account and associated resources
Locate the name of your YAML defined Service Account, and it's associated Role and Rolebinding resources. You will find these in your Service Account YAML file, under the `metadata.name`fields for each resource.
```yaml
apiVersion: v1
kind: ServiceAccount
metadata:
name: circleci
namespace: my-dev-namespace
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: circleci
namespace: my-dev-namespace
rules:
- apiGroups:
...
...
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: circleci
namespace: my-dev-namespace
subjects:
- kind: ServiceAccount
name: circleci
namespace: my-dev-namespace
roleRef:
kind: Role
name: circleci
apiGroup: rbac.authorization.k8s.io
```
Locate the name of the associated Secret containing the Service Account token, found under the `secrets.name` field of the Service Account resource.
```bash
kubectl get serviceaccount circleci -oyaml -n my-dev-namespace
```
Will yield similar to:
```yaml
apiVersion: v1
kind: ServiceAccount
metadata:
name: circleci
namespace: my-dev-namespace
secrets:
- name: circleci-token-bwbcz
```
#### Delete the Service Account and associated resources
Delete the Service Account, and associated Role, Rolebinding and secret resources using the `kubectl delete` command.
```bash
kubectl delete serviceaccount circleci -n my-dev-namespace
kubectl delete role circleci -n my-dev-namespace
kubectl delete rolebinding circleci -n my-dev-namespace
kubectl delete secret circleci-token-bwbcz -n my-dev-namespace
```
Finally, delete the YAML file containing the old Service Account definition within your namespace folder in the `cloud-platform-environments` repository, raising a PR to merge the changes.