KUBERNETES SECURITYCONTEXT — CKA REVISION

1. WHAT IS SECURITYCONTEXT?
---------------------------
SecurityContext defines security-related settings for a Pod or Container.

It controls:
- Linux user/group
- Root vs non-root
- File permissions
- Linux capabilities
- Privilege escalation
- Privileged mode
- Read-only filesystem
- Seccomp
- SELinux

Two levels:
- Pod-level securityContext → applies to Pod/containers by default
- Container-level securityContext → applies specifically to that container

If a setting exists at both Pod and Container level, container-level setting takes precedence.

2. POD-LEVEL SECURITYCONTEXT
----------------------------
Example:

spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
    runAsNonRoot: true
    fsGroup: 2000

3. runAsUser
------------
Specifies the Linux UID that the container process runs as.

securityContext:
  runAsUser: 1000

Meaning:
- Process runs as UID 1000
- Instead of root (UID 0)

Purpose:
- Avoid running applications as root
- Improve security

4. runAsGroup
-------------
Specifies the primary Linux GID.

securityContext:
  runAsUser: 1000
  runAsGroup: 3000

Meaning:
- UID = 1000
- Primary GID = 3000

5. runAsNonRoot
---------------
Ensures the container does NOT run as root.

securityContext:
  runAsNonRoot: true

Important:
runAsNonRoot: true does NOT mean UID 1000.

It means:
"The process must not run as UID 0."

Difference:
runAsUser     → "Run as this UID"
runAsNonRoot  → "Do NOT run as root"

6. fsGroup
----------
Defines the group ownership/access behavior for files associated with volumes mounted into the Pod.

Example:

spec:
  securityContext:
    fsGroup: 2000

Think:
Application
    ↓
Volume
    ↓
fsGroup
    ↓
Group-based access

Useful when an application needs group-based access to mounted volumes.

7. fsGroupChangePolicy
----------------------
Controls when Kubernetes changes volume ownership/permissions for fsGroup.

Values:
- Always
- OnRootMismatch

Always:
Always apply the ownership/permission changes.

OnRootMismatch:
Apply them only when the volume root does not already have the expected ownership/permissions.

8. supplementalGroups
---------------------
Adds additional Linux groups to the container process.

Example:

securityContext:
  supplementalGroups:
  - 4000
  - 5000

Think:
Primary group
    +
Supplementary groups

9. privileged
-------------
Runs a container in privileged mode.

Example:

securityContext:
  privileged: true

Meaning:
- Gives the container highly elevated access
- Can access host devices/kernel capabilities

Generally:
privileged: false

Remember:
Privileged = highly elevated container access

10. CAPABILITIES
----------------
Linux capabilities split root privileges into individual permissions.

Example:

securityContext:
  capabilities:
    add:
    - NET_ADMIN
    drop:
    - ALL

Can:
- ADD capabilities
- DROP capabilities

Example:

capabilities:
  drop:
  - ALL

Meaning:
Remove all capabilities.

Example:

capabilities:
  add:
  - NET_ADMIN

Meaning:
Give NET_ADMIN capability.

Security best practice:
Drop unnecessary capabilities and add only what is required.

11. allowPrivilegeEscalation
----------------------------
Controls whether a process can gain more privileges than its parent process.

Example:

securityContext:
  allowPrivilegeEscalation: false

Meaning:
Do not allow the process to gain additional privileges.

For restricted security configurations:
allowPrivilegeEscalation: false

12. readOnlyRootFilesystem
--------------------------
Makes the container's root filesystem read-only.

Example:

securityContext:
  readOnlyRootFilesystem: true

Meaning:
Container cannot write to its root filesystem.

If application needs writable temporary storage:

volumes:
- name: tmp
  emptyDir: {}

Then mount it where required.

13. seccompProfile
------------------
Seccomp restricts which Linux system calls a process can make.

Example:

securityContext:
  seccompProfile:
    type: RuntimeDefault

Common types:
- RuntimeDefault
- Unconfined
- Localhost

RuntimeDefault:
Use container runtime's default seccomp profile.

Unconfined:
No seccomp restrictions.

Localhost:
Use a custom profile already present on the node.

14. seLinuxOptions
------------------
Configures SELinux-related security settings.

Example:

securityContext:
  seLinuxOptions:
    level: "s0:c123,c456"

More advanced and depends on SELinux configuration.

15. MAJOR SECURITYCONTEXT FIELDS
--------------------------------
For CKA, remember these core fields:

Pod-level:
- runAsUser
- runAsGroup
- runAsNonRoot
- fsGroup
- fsGroupChangePolicy
- supplementalGroups
- seccompProfile
- seLinuxOptions

Container-level:
- runAsUser
- runAsGroup
- runAsNonRoot
- privileged
- allowPrivilegeEscalation
- readOnlyRootFilesystem
- capabilities
- seccompProfile
- seLinuxOptions

16. SIX CORE FIELDS FOR QUICK CKA REVISION
------------------------------------------
1. runAsUser
2. runAsGroup
3. runAsNonRoot
4. fsGroup
5. capabilities
6. allowPrivilegeEscalation

Note:
"Major 6 fields" is a useful study shortcut, NOT an official Kubernetes limit.

17. SECURE POD EXAMPLE
----------------------

apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
    runAsNonRoot: true
    fsGroup: 2000

  containers:
  - name: app
    image: nginx
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop:
        - ALL

Meaning:

Pod:
- UID = 1000
- GID = 3000
- Must not run as root
- Volume group = 2000

Container:
- Cannot escalate privileges
- Root filesystem is read-only
- All Linux capabilities are dropped

18. SECURITYCONTEXT vs POD SECURITY ADMISSION
---------------------------------------------
SecurityContext:
Defines HOW a Pod/container runs.

Examples:
- runAsUser
- privileged
- capabilities
- fsGroup

Pod Security Admission:
Defines WHAT security configuration is allowed in a namespace.

Levels:
- Privileged
- Baseline
- Restricted

Think:

Pod Security Admission
    ↓
"Are you ALLOWED to create this Pod?"

SecurityContext
    ↓
"HOW will this Pod/container run?"

19. SECURITYCONTEXT vs RBAC
---------------------------
RBAC:
Controls what a user/service account can do to Kubernetes API resources.

Examples:
- get Pods
- delete Deployments
- create Secrets

SecurityContext:
Controls how the container process runs on Linux.

Examples:
- UID
- GID
- root/non-root
- capabilities
- privileges
- filesystem

20. CKA QUICK MEMORY
--------------------

Question:
"Run container as user 1000"
→ runAsUser: 1000

"Run as non-root"
→ runAsNonRoot: true

"Set group ownership for volumes"
→ fsGroup: 2000

"Set primary group"
→ runAsGroup: 3000

"Add/remove Linux privileges"
→ capabilities

"Remove all capabilities"
→ capabilities:
    drop:
    - ALL

"Don't allow gaining additional privileges"
→ allowPrivilegeEscalation: false

"Make container filesystem read-only"
→ readOnlyRootFilesystem: true

"Run with elevated privileges"
→ privileged: true

"Restrict Linux system calls"
→ seccompProfile

FINAL MENTAL MODEL
------------------

                 Kubernetes Security
                         |
        +----------------+----------------+
        |                |                |
       RBAC       Pod Security       SecurityContext
                       Admission            |
        |                |                   |
   API permissions   Pod restrictions    Linux process
                                            |
              +-----------------------------+----------------+
              |          |          |        |        |       |
         runAsUser  runAsGroup  fsGroup  capabilities  privileged
              |          |          |        |        |
             UID        GID       Volume   Privileges  Root
                                                   |
                                          allowPrivilegeEscalation

MOST IMPORTANT FOR CKA:
-----------------------
runAsUser
runAsGroup
runAsNonRoot
fsGroup
capabilities
allowPrivilegeEscalation
privileged
readOnlyRootFilesystem
seccompProfile