You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
GitHub Token Permissions Are Not Set to Minimum in Workflow
Summary
The GitHub token permissions in your workflow file (.github/workflows/k3s.yml) exceed the minimum required. Reducing permissions to the minimum necessary enhances security by limiting the access scope of the token, thereby lowering the risk of accidental or malicious misuse.
Why This is Important
Using excessive permissions in GitHub workflows can expose your repository to potential security risks. The GitHub token grants access to repository resources, and any unnecessary permissions increase the likelihood of sensitive actions being performed without justification. By applying the principle of least privilege, you protect your repository from unintended data exposure and ensure that each job only has access to what it absolutely needs.
Evidence of Excessive Permissions
For more context, please refer to the build log from your recent workflow run, which highlights the permissions granted to the GitHub token that exceed the recommended minimum.
Suggested Fix
Below is the updated permissions configuration, which minimizes access for the GitHub token. Update your workflow file with this suggested configuration to resolve this issue:
```diff
name: k3s Outbound Connectivity Test
on:
workflow_dispatch:
+ permissions:+ contents: read
jobs:
k3s-test:
runs-on: ubuntu-latest
steps:
- name: Harden Runner
uses: step-security/harden-runner@int-sh
with:
egress-policy: audit
- name: Checkout repository
uses: actions/checkout@v3
- run: cat /etc/resolv.conf
- name: Install k3d
shell: bash
run: |
# Disable swap otherwise memory enforcement does not work
# See: https://kubernetes.slack.com/archives/CEKK1KTN2/p1600009955324200
sudo swapoff -a
sudo rm -f /swapfile
curl -Lo ./k3d https://github.com/k3d-io/k3d/releases/download/v5.7.4/k3d-$(uname)-amd64
chmod +x ./k3d
sudo mv k3d /usr/local/bin
- name: Create k3d cluster
shell: bash
run: |
cat > k3d.yaml <<EOF
apiVersion: k3d.io/v1alpha5
kind: Simple
agents: 0
image: "rancher/k3s:latest"
registries:
create:
name: "registry.local"
host: "0.0.0.0"
hostPort: "5000"
config: |
mirrors:
"mirror.gcr.io":
endpoint:
- "https://mirror.gcr.io"
options:
k3s:
extraArgs:
# Let consumers use their own ingress and leave the builtin LB unclaimed
- arg: --disable=traefik
nodeFilters:
- server:*
# Let consumers use their own metrics-server and leave the builtin unclaimed
- arg: --disable=metrics-server
nodeFilters:
- server:*
# This is needed in order to support projected volumes with service account tokens.
# See:
# https://kubernetes.slack.com/archives/CEKK1KTN2/p1600268272383600
# https://stackoverflow.com/questions/74603633/k3s-allow-unauthenticated-access-to-oidc-endpoints
- arg: --kube-apiserver-arg=anonymous-auth=true
nodeFilters:
- server:*
# This sets the issuer to what sigstore scaffolding expects.
# See also: https://github.com/k3d-io/k3d/issues/1187
- arg: --kube-apiserver-arg=service-account-issuer=https://kubernetes.default.svc
nodeFilters:
- server:*
- arg: --kubelet-arg=max-pods=110
nodeFilters:
- server:*
- agent:*
EOF
echo "Using k3d config file: "
cat k3d.yaml
#k3d cluster create mycluster --wait --verbose
k3d cluster create mycluster --config k3d.yaml --timeout 5m --verbose
# K3d sets this up for us in the node, but we're responsible for the host
sudo echo "127.0.0.1 registry.local" | sudo tee -a /etc/hosts
- name: Set start time output
id: start-time
run: echo "k3d-start-time=$(echo $(($(date +%s%N)/1000000)))" >> $GITHUB_OUTPUT
shell: bash
- name: Verify k3s installation
run: kubectl get nodes
- run: docker ps
- name: Deploy app to local k8s cluster
run: |
kubectl apply -f k8s/deployment.yml # Ensure your deployment YAML is in the k8s folder
kubectl rollout status deployment/nginx-deployment # Use the correct deployment name
- name: Deploy test pod
run: |
kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
name: test-pod
spec:
containers:
- name: curl-container
image: curlimages/curl:7.85.0
command: ["sh", "-c", "sleep infinity"]
EOF
- name: Wait for pod to be ready
run: kubectl wait --for=condition=Ready pod/test-pod --timeout=60s
- name: Verify outbound connectivity
run: |
kubectl exec test-pod -- curl -I https://www.google.com
- name: Check pod logs
run: kubectl logs test-pod
- run: cat /etc/resolv.conf
- name: Get Kubernetes events
run: kubectl get events --all-namespaces
- name: Print k3s server logs
if: always()
run: |
docker logs k3d-mycluster-server-0
docker exec k3d-mycluster-server-0 cat /etc/resolv.conf
docker inspect k3d-mycluster-server-0 | grep -i networkmode
- name: Print k3s agent logs (if any)
if: ${{ inputs.worker-count != '0' }}
run: |
echo "==== k3s Agent Logs ===="
AGENT_CONTAINERS=$(docker ps --filter "name=k3d-${CLUSTER_NAME}-agent-" --format "{{.Names}}")
for AGENT_CONTAINER in $AGENT_CONTAINERS; do
echo "Agent container: $AGENT_CONTAINER"
docker logs $AGENT_CONTAINER
done
Next Steps
Please review and update the workflow file with these minimum permissions. If additional permissions are necessary for certain steps, specify only those permissions explicitly.
GitHub Token Permissions Are Not Set to Minimum in Workflow
Summary
The GitHub token permissions in your workflow file (.github/workflows/k3s.yml) exceed the minimum required. Reducing permissions to the minimum necessary enhances security by limiting the access scope of the token, thereby lowering the risk of accidental or malicious misuse.
Why This is Important
Using excessive permissions in GitHub workflows can expose your repository to potential security risks. The GitHub token grants access to repository resources, and any unnecessary permissions increase the likelihood of sensitive actions being performed without justification. By applying the principle of least privilege, you protect your repository from unintended data exposure and ensure that each job only has access to what it absolutely needs.
Evidence of Excessive Permissions
For more context, please refer to the build log from your recent workflow run, which highlights the permissions granted to the GitHub token that exceed the recommended minimum.
Suggested Fix
Below is the updated permissions configuration, which minimizes access for the GitHub token. Update your workflow file with this suggested configuration to resolve this issue:
Next Steps
Please review and update the workflow file with these minimum permissions. If additional permissions are necessary for certain steps, specify only those permissions explicitly.
For further guidance, refer to the GitHub documentation on fine-grained permissions.
Severity: High
The text was updated successfully, but these errors were encountered: