aster.cloud aster.cloud
  • /
  • Platforms
    • Public Cloud
    • On-Premise
    • Hybrid Cloud
    • Data
  • Architecture
    • Design
    • Solutions
    • Enterprise
  • Engineering
    • Automation
    • Software Engineering
    • Project Management
    • DevOps
  • Programming
    • Learning
  • Tools
  • About
  • /
  • Platforms
    • Public Cloud
    • On-Premise
    • Hybrid Cloud
    • Data
  • Architecture
    • Design
    • Solutions
    • Enterprise
  • Engineering
    • Automation
    • Software Engineering
    • Project Management
    • DevOps
  • Programming
    • Learning
  • Tools
  • About
aster.cloud aster.cloud
  • /
  • Platforms
    • Public Cloud
    • On-Premise
    • Hybrid Cloud
    • Data
  • Architecture
    • Design
    • Solutions
    • Enterprise
  • Engineering
    • Automation
    • Software Engineering
    • Project Management
    • DevOps
  • Programming
    • Learning
  • Tools
  • About
Laptop | Tools
  • Computing
  • Engineering
  • Practices

Best Practices For Securing Kubernetes Deployments

  • aster.cloud
  • December 22, 2023
  • 4 minute read

Although Kubernetes is a powerful container orchestration platform, its complexity and its adoption makes it a prime target for security attacks. We’ll go over some of the best practices for securing the Kubernetes deployments and keeping applications and data safe in this article.

This article is only about pods or deployments; I intend to cover other security related topics in subsequent articles.


Partner with aster.cloud
for your next big idea.
Let us know here.



From our partners:

CITI.IO :: Business. Institutions. Society. Global Political Economy.
CYBERPOGO.COM :: For the Arts, Sciences, and Technology.
DADAHACKS.COM :: Parenting For The Rest Of Us.
ZEDISTA.COM :: Entertainment. Sports. Culture. Escape.
TAKUMAKU.COM :: For The Hearth And Home.
ASTER.CLOUD :: From The Cloud And Beyond.
LIWAIWAI.COM :: Intelligence, Inside and Outside.
GLOBALCLOUDPLATFORMS.COM :: For The World's Computing Needs.
FIREGULAMAN.COM :: For The Fire In The Belly Of The Coder.
ASTERCASTER.COM :: Supra Astra. Beyond The Stars.
BARTDAY.COM :: Prosperity For Everyone.

Below is a list of settings and configurations that can be implemented to accomplish the intended goal.

  • securityContext.allowPrivilegeEscalation
    • The securityContext.allowPrivilegeEscalation setting determines whether a container’s privileges can be escalated. When true, it grants a container additional privileges beyond those granted by default.
    • Setting allowPrivilegeEscalation to false can help reduce the risk of privilege escalation attacks.
  containers:
  - name: webapp
    image: nginx:1.17
    securityContext:
      allowPrivilegeEscalation: false

  # Output trimmed

  • securityContext.runAsNonRoot
    • The securityContext.runAsNonRoot setting is used to prevent containers from being run as the root user, which can be dangerous.
    • When runAsNonRoot is set to true, the container is started with a non-root user ID (UID) instead of the default root UID of 0.
    • The securityContext section is used in the following example to set runAsNonRoot to true. This means the container will be started with a non-root UID.
    • It’s generally recommended to run containers as non-root whenever possible to reduce the risk of privilege escalation attacks. Keep in mind, however, that some applications may require root access to function properly.
  containers:
  - name: webapp
    image: nginx:1.17
    securityContext:
      runAsNonRoot: true

  # Output trimmed

  • securityContext.readOnlyRootFilesystem
    • The securityContext.readOnlyRootFilesystem setting is used to prevent write access to a container’s root filesystem.
    • When this setting is enabled and set to true, the container’s root filesystem is mounted as read-only, resulting in a runtime error if any attempt to write to the root filesystem fails.
    • Enabling this will for sure reduce the attack surface, However, do keep in mind that this setting may not be appropriate for all containers/applications, particularly those that require write access to the root filesystem to function properly.
  containers:
  - name: webapp
    image: nginx:1.17
    securityContext:
      readOnlyRootFilesystem: true

  # Output trimmed

  • securityContext.runAsUser
    • The securityContext.runAsUser setting in Kubernetes is used to specify the user ID that should be used to run a container.
    • Containers are run as the root user by default, which can pose a security risk if an attacker gains access to the container.
    • To reduce the risk of privilege escalation attacks, containers should be run as non-root users whenever possible.
    • This configuration can be used at the pod and/or container levels; if set at the container level, it will override the pod’s configuration.
  securityContext:
    runAsUser: 1000
  containers:
  - name: webapp
    image: nginx:1.17

  # Output trimmed

  • securityContext.runAsGroup
    • The securityContext.runAsGroup setting specifies the group ID under which the container’s main process should run.
    • This configuration too can be used at the pod and/or container levels; if set at the container level, it will override the pod’s configuration.
  containers:
  - name: webapp
    image: nginx:1.17
    securityContext:
      runAsGroup: 1000

  # Output trimmed

  • securityContext.capabilities
    • It is recommended that containers drop all capabilities, and only authorized or permitted ones should be added if necessary.
    • This helps to mitigate the risk of potential privilege escalation attacks on the containers.
    • Set the capabilities field to an empty object {} to remove all Linux capabilities from the container.
  containers:
  - name: webapp
    image: nginx:1.17
    securityContext:
      capabilities: {}

  # Output trimmed

  • securityContext.capabilities.add
    • If required you can use add to specify specific capabilities.
  containers:
  - name: webapp
    image: nginx:1.17
    securityContext:
      capabilities:
        add:
        - SYS_TIME

  # Output trimmed

  • securityContext.capabilities.drop
    • If required you can use drop to remove specific capabilities.
  containers:
  - name: webapp
    image: nginx:1.17
    securityContext:
      capabilities:
        drop:
        - SYS_ADMIN

  # Output trimmed

NOTE:

  • For more information around capabilities, fire man capabilities.
  • resources.limits.cpu
  • resources.limits.memory
    • The settings resources.limits.cpu and resources.limits.memory specifies the maximum amount of CPU/Memory that a container can use.
    • It’s used to restrict the amount of CPU/Memory resources that a container can use.
  containers:
  - name: webapp
    image: nginx:1.17
    resources:
      limits:
        cpu: "1"
        memory: "512Mi"

  # Output trimmed

  • resources.requests.cpu
  • resources.requests.memory
    • The settings resources.requests.cpu and resources.requests.memory specifies the minimum amount of CPU/Memory that a container should use.
    • It’s used to allocate the amount of CPU/Memory resources on the node for container.
  containers:
  - name: webapp
    image: nginx:1.17
    resources:
      requests:
        cpu: "0.5"
        memory: "256Mi"

  • replicas
    • A replica is a duplicate of a pod that runs a single application. When you deploy an application in Kubernetes, you can use the replicas key to specify the number of replicas you want.
    • This instructs Kubernetes on how many instances of the pod should be running at any given time.
    • In below example we are specifying replicas as 3, which mean 3 identical pods will run on the cluster.
  apiVersion: apps/v1
  kind: Deployment
  metadata:
    name: webapp
  spec:
    replicas: 3

  # Output trimmed

  • image
    • When deploying applications in production, the deployment or the pods should specify an image tag. It is best to avoid using the :latest image tag or no tag.
    • By doing this, it becomes difficult to determine which version of the image is in use and to roll back the version.
    • In below example we are specifying the tag as 1.17 for nginx image.
  containers:
  - name: webapp
    image: nginx:1.17

  # Output trimmed

  • namespace
    • Deployments should not be configured with the ‘default’ namespace; ensure that the default namespace is not used.
    • In below example we are specifying namespace as frontend, where the application webapp will be deployed.
  apiVersion: apps/v1
  kind: Deployment
  metadata:
    name: webapp
    namespace: frontend
  spec:

  # Output trimmed

NOTE:

  • There are many other securityContext options available, but these are the ones that are most commonly used.
Read More  Google Cloud Next For Application Developers: 5 Can’t Miss Breakout Sessions

Just for reference here is the list of options which are accepted on pod layer (to know more about it fire kubectl explain pod.spec.securityContext):

  • fsGroup
  • fsGroupChangePolicy
  • runAsGroup
  • runAsNonRoot
  • runAsUser
  • seLinuxOptions
  • seccompProfile
  • supplementalGroups
  • sysctls
  • windowsOptions

And below are the ones which are accepted on container layer (to know more about it fire kubectl explain pod.spec.containers.securityContext):

  • allowPrivilegeEscalation
  • capabilities
  • privileged
  • procMount
  • readOnlyRootFilesystem
  • runAsGroup
  • runAsNonRoot
  • runAsUser
  • seLinuxOptions
  • seccompProfile
  • windowsOptions

If there are any important configurations or use cases that I may have missed from deployments perspective, please feel free to add them.

References:

  • https://kubernetes.io/docs/home/
  • Linux man pages.
  • Documentation from kubectl explain command.

Community post originally published on DEV.to by Sunny Bhambhani

By: Sunny Bhambhani
Published at: Cloud Native Computing Foundation

Source: cyberpogo.com


For enquiries, product placements, sponsorships, and collaborations, connect with us at [email protected]. We'd love to hear from you!

Our humans need coffee too! Your support is highly appreciated, thank you!

aster.cloud

Related Topics
  • Best Practices
  • Cloud
  • Containers
  • Kubernetes
  • Security
You May Also Like
View Post
  • Computing
  • Multi-Cloud
  • Technology

Pure Accelerate 2025: All the news and updates live from Las Vegas

  • June 18, 2025
View Post
  • Computing
  • Multi-Cloud
  • Technology

‘This was a very purposeful strategy’: Pure Storage unveils Enterprise Data Cloud in bid to unify data storage, management

  • June 18, 2025
View Post
  • Computing
  • Multi-Cloud
  • Technology

What is cloud bursting?

  • June 18, 2025
View Post
  • Computing
  • Multi-Cloud
  • Technology

There’s a ‘cloud reset’ underway, and VMware Cloud Foundation 9.0 is a chance for Broadcom to pounce on it

  • June 17, 2025
View Post
  • Computing
  • Multi-Cloud
  • Technology

What is confidential computing?

  • June 17, 2025
View Post
  • Computing
  • Multi-Cloud
  • Technology

Oracle adds xAI Grok models to OCI

  • June 17, 2025
View Post
  • Computing
  • Multi-Cloud
  • Technology

Fine-tune your storage-as-a-service approach

  • June 16, 2025
View Post
  • Computing
  • Multi-Cloud
  • Technology

Global cloud spending might be booming, but AWS is trailing Microsoft and Google

  • June 13, 2025

Stay Connected!
LATEST
  • 1
    Pure Accelerate 2025: All the news and updates live from Las Vegas
    • June 18, 2025
  • 2
    ‘This was a very purposeful strategy’: Pure Storage unveils Enterprise Data Cloud in bid to unify data storage, management
    • June 18, 2025
  • What is cloud bursting?
    • June 18, 2025
  • 4
    There’s a ‘cloud reset’ underway, and VMware Cloud Foundation 9.0 is a chance for Broadcom to pounce on it
    • June 17, 2025
  • What is confidential computing?
    • June 17, 2025
  • Oracle adds xAI Grok models to OCI
    • June 17, 2025
  • Fine-tune your storage-as-a-service approach
    • June 16, 2025
  • 8
    Advanced audio dialog and generation with Gemini 2.5
    • June 15, 2025
  • 9
    A Father’s Day Gift for Every Pop and Papa
    • June 13, 2025
  • 10
    Global cloud spending might be booming, but AWS is trailing Microsoft and Google
    • June 13, 2025
about
Hello World!

We are aster.cloud. We’re created by programmers for programmers.

Our site aims to provide guides, programming tips, reviews, and interesting materials for tech people and those who want to learn in general.

We would like to hear from you.

If you have any feedback, enquiries, or sponsorship request, kindly reach out to us at:

[email protected]
Most Popular
  • Google Cloud, Cloudflare struck by widespread outages
    • June 12, 2025
  • What is PC as a service (PCaaS)?
    • June 12, 2025
  • 3
    Crayon targets mid-market gains with expanded Google Cloud partnership
    • June 10, 2025
  • By the numbers: Use AI to fill the IT skills gap
    • June 11, 2025
  • 5
    Apple services deliver powerful features and intelligent updates to users this autumn
    • June 11, 2025
  • /
  • Technology
  • Tools
  • About
  • Contact Us

Input your search keywords and press Enter.