Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Blog on "Ensure secret pulled images" feature #47053

Closed
wants to merge 1 commit into from
Closed

Blog on "Ensure secret pulled images" feature #47053

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
82 changes: 82 additions & 0 deletions content/en/blog/_posts/2024-07-01-ensure-secret-pulled-images.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,82 @@
---
layout: blog
title: "Kubernetes: 1.31 KubeletEnsureSecretPulledImages feature gate"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
title: "Kubernetes: 1.31 KubeletEnsureSecretPulledImages feature gate"
title: "Kubernetes 1.31: Additional Security Measures For Container Image Pulls"

date: 2024-07-01
slug: ensure-secret-pulled-images
author: >
Sai Ramesh Vanka (Red Hat)
---
Reference KEP: https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2535-ensure-secret-pulled-images
# Scenario: Enable KubeletEnsureSecretPulledImages FeatureGate

## Objective
Enable a new feature gate `KubeletEnsureSecretPulledImages` and create two pods that pull same image from a private registry (for ex: `quay.io`) with one pod configured with valid image pull credentials and another having invalid image pull credentials.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Enable a new feature gate `KubeletEnsureSecretPulledImages` and create two pods that pull same image from a private registry (for ex: `quay.io`) with one pod configured with valid image pull credentials and another having invalid image pull credentials.
Enable a new feature gate `KubeletEnsureSecretPulledImages` and create two pods that pull same
image from a private registry (for ex: `quay.io`) with one pod configured with valid image
pull credentials and another having invalid image pull credentials.

## Steps

### Step 1: Modify kubelet Configuration
First, let's modify the kubelet configuration to adjust a parameter related to Pod security.

```yaml
# File: /etc/kubernetes/kubelet.conf
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
featureGates:
KubeletEnsureSecretPulledImages: true
pullImageSecretRecheck: true
pullImageSecretRecheckPeriod: 60s
```
In this configuration:
`KubeletEnsureSecretPulledImages: true` enables the feature gate
`pullImageSecretRecheck: true` is a boolean to enable the recheck
`pullImageSecretRecheckPeriod: 60s` is the duration after which the kubelet's image related cache gets invalidated
### Step 2: Create a valid and an invalid image pull secrets
Create two secrets one valid (`valid-creds`) and another invalid(`invalid-creds`) to be used while creating pods using this [reference](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/)
### Step 3: Create two simple nginx pods that use the above image pull secrets
Now, deploy simple nginx pods that utilize the above created image pull secrets
```yaml
# File: nginx-pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: image-with-valid-creds
spec:
containers:
- image: quay.io/<private-repo>/nginx:latest
name: nginx
command: [ "sleep", "10000" ]
imagePullSecrets:
- name: valid-creds
---
apiVersion: v1
kind: Pod
metadata:
name: image-with-invalid-creds
spec:
containers:
- image: quay.io/<private-repo>/nginx:latest
name: nginx
command: [ "sleep", "10000" ]
imagePullSecrets:
- name: invalid-creds
```
In this Pod specification:
- The nginx container is based on a private image `quay.io/<private-repo>/nginx:latest`

### Step 3: Apply Configuration
Apply the kubelet configuration and deploy the nginx Pod.
`$ kubectl apply -f nginx-pod.yaml`

### Step 4: Verify Deployment
Verify that the nginx pod with valid creds is running and the pod with invalid creds errors out.
```
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
image-with-valid-creds 1/1 Running 0 10s
image-with-invalid-creds 1/1 ErrImageNotEnsured 0 10s
```
### Step 5: Repeat the pod creation after turning off the feature gate
Modify the kubelet configuration by setting the `KubeletEnsureSecretPulledImages` feature gate to `false` and verify both the pods are `Running` successfully which is the default/current behavior.

### Conclusion
As of today, if a pod pulls an image from a private registry with valid credentials on to a node, the same can be leveraged by any another pod on the same node even without a valid image pull seceret/credentials.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
As of today, if a pod pulls an image from a private registry with valid credentials on to a node, the same can be leveraged by any another pod on the same node even without a valid image pull seceret/credentials.
As of today, if a pod pulls an image from a private registry with valid credentials on to a node, the same can be
leveraged by any another pod on the same node even without a valid image pull seceret/credentials.

This newly introduced feature would help the cluster admin to have a better access control in terms of multi tenant scenarios by allowing the access of an image only incase of having a valid credentials even if the image is already present on the node.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
This newly introduced feature would help the cluster admin to have a better access control in terms of multi tenant scenarios by allowing the access of an image only incase of having a valid credentials even if the image is already present on the node.
This newly introduced feature would help the cluster admin to have a better access control
in terms of multi tenant scenarios by allowing the access of an image only incase of having
a valid credentials even if the image is already present on the node.