Using a Service Account for GitHub Actions

Table of Contents

• Background
• Creating the Service Account
• Configuring the Service Account
• Deleting the Service Account

Background

When logging in to a Kubernetes cluster from an automated environment, it is recommended to use a functional Service Account rather than personal credentials. See Managing Service Accounts, and Service Account Tokens.

The advantages of this approach are:

• Service Account tokens do not expire, resolving the problem of constantly needing to log in.
• Developers working on workflow automation do not have to worry about securing personal credentials.
• Service Account tokens can be trivially revoked without disrupting a specific user.

Creating the Service Account

Also see How can I create a Service Account for Scripted Access?.

Linux/MacOS (sh)

Paste the following into a bash or sh prompt or script file.

# First, name your Service Account (the Kubernetes shortname is "sa")
export SA=github-actions-sa
# and create it.
oc create sa $SA

# Now, we have to find the name of the secret in which the Service Account's apiserver token is stored.
# The following command will output two secrets. 
export SECRETS=$(oc get sa $SA -o jsonpath='{.secrets[*].name}{"\n"}') && echo $SECRETS
# Select the one with "token" in the name - the other is for the container registry.
export SECRET_NAME=$(printf "%s\n" $SECRETS | grep "token") && echo $SECRET_NAME

# Get the token from the secret. 
export ENCODED_TOKEN=$(oc get secret $SECRET_NAME -o jsonpath='{.data.token}{"\n"}') && echo $ENCODED_TOKEN;
export TOKEN=$(echo $ENCODED_TOKEN | base64 -d) && echo $TOKEN

Windows (batch)

Save the following into a .bat file and run it.

@echo off 
rem First, name your Service Account (the Kubernetes shortname is "sa") and create it.
set SA=github-actions-sa 
oc create sa %SA%

rem Now, we have to find the `name` of the secret in which the Service Account's apiserver token is stored.
rem The following command will output two secrets. 
oc get sa %SA% -o jsonpath='{.secrets[*].name}' >tmp.secret
set /P SECRETSQ=< tmp.secret
set SECRETS=%SECRETSQ:'=%  
echo NOMATCH >tmp.per_line 
for %%a in (%SECRETS%) do echo %%a >>tmp.per_line  
grep  "token" tmp.per_line > tmp.secret_name 
set /P SECRET_NAMEQ=< tmp.secret_name 
set SECRET_NAME=%SECRET_NAMEQ:'=%   

oc get secret %SECRET_NAME%  -o jsonpath='{.data.token}' > tmp.token
set /P ENCODED_TOKENQ=< tmp.token
set ENCODED_TOKEN=%ENCODED_TOKENQ:'=%   
echo %ENCODED_TOKEN% > tmp.token
certutil -decode tmp.token tmp.data > nul
set /P TOKEN=< tmp.data 

del tmp.secret tmp.per_line tmp.secret_name tmp.secret_name tmp.token  tmp.data
echo TOKEN is %TOKEN% and is in your clipboard
echo|set /p=%TOKEN%| clip

Troubleshooting Tokens

The Service Account Token will be a JWT. You can use this tool to test your token is valid. JWTs always start with eyJhb.

If the token is retrieved using oc describe secret then it will be decoded and will be a valid JWT.

Alternatively, if the token is retrieved using oc get secret -o yaml then it will be base64 encoded an extra time (as Kubernetes secret values are). In this case, the token will start with ZXlKaG.

You will have to decode it using an online tool or echo $TOKEN | base64 -d, and test it is a valid JWT before pasting it into the GitHub secret.

Configuring the Service Account

Now, you have to give your Service Account permissions to make changes to your cluster. By default, it has no permissions. Refer to Understanding and Creating Service Accounts.

You will need permission to edit rolebindings in your namespace in order to edit the Service Account's permissions.

If you receive permissions errors when running oc policy commands, ask your cluster administrator for help.

Think about what permissions your action's Service Account needs, and what namespaces it may need those permissions in.

See oc get clusterrole for the list of ClusterRoles you can add to the Service Account. See oc describe clusterrole edit for what those permissions include.

For example, to allow your Service Account to have user-level edit permissions:

oc policy add-role-to-user edit -z $SA

With the necessary permissions configured, you can now use the Service Account in your workflows.

Deleting the Service Account

If you want to revoke the Service Account's access, simply delete it.

oc delete sa $SA

You can also delete specific secrets that contain Service Account Tokens to revoke tokens without deleting the Service Account.