WIP: Security Context #6287
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -599,12 +599,10 @@ type Container struct { | |
| Lifecycle *Lifecycle `json:"lifecycle,omitempty"` | ||
| // Required. | ||
| TerminationMessagePath string `json:"terminationMessagePath,omitempty"` | ||
| // Required: Policy for pulling images for this container | ||
| ImagePullPolicy PullPolicy `json:"imagePullPolicy"` | ||
| // SecurityContext defines the security context the pod should run with | ||
| SecurityContext `json:",inline"` | ||
| } | ||
|
|
||
| // Handler defines a specific action that should be taken | ||
|
|
@@ -1776,6 +1774,110 @@ type SecretList struct { | |
| Items []Secret `json:"items"` | ||
| } | ||
|
|
||
| // SecurityContext holds security configuration that will be applied to a container. If a security context | ||
| // is set on the container spec then it must comply with any constraints defined in the SecurityConstraints context | ||
|
There was a problem hiding this comment. Which component is going to read this object? Kubelet? There was a problem hiding this comment. The question was about which component is going to read SecurityConstraints. There was a problem hiding this comment. Maybe SecurityConstraints and its dependencies are part of the kubelet API but not necessarily part of the core kubenetes API? Take a look at how scheduler has its own API: SecurityContext seems like it is part of the core API since Pods use it. There was a problem hiding this comment. What we've discussed so far was that enforcement of constraints by the There was a problem hiding this comment. Apologies, poor pronoun use. we := myself and @smarterclayton discussed in the link provided above. |
||
| // it is running in. If a security context is not supplied and the pod is running under a SecurityConstraints context | ||
| // then a default SecurityContext may be applied. | ||
| type SecurityContext struct { | ||
| // Capabilities are the capabilities to add/drop when running the container | ||
| Capabilities *Capabilities `json:"capabilities,omitempty"` | ||
|
|
||
| // Run the container in privileged mode | ||
| Privileged bool `json:"privileged,omitempty"` | ||
|
|
||
| // SELinuxOptions are the labels to be applied to the container | ||
| // and volumes | ||
| SELinuxOptions *SELinuxOptions `json:"seLinuxOptions,omitempty"` | ||
|
|
||
| // RunAsUser is the UID to run the entrypoint of the container process. Corresponding option is --user or -u | ||
| RunAsUser int64 `json:"runAsUser,omitempty"` | ||
|
There was a problem hiding this comment. This has to be *int64 because not specifying a RunAsUser is the same as saying "use the image's default". |
||
| } | ||
|
|
||
| // SELinuxOptions are the labels to be applied to the container | ||
| type SELinuxOptions struct { | ||
| // User --security-opt="label:user:USER" | ||
| User string `json:"user,omitempty"` | ||
|
|
||
| // Role --security-opt="label:role:ROLE" | ||
| Role string `json:"role,omitempty"` | ||
|
|
||
| // Type --security-opt="label:type:TYPE" | ||
| Type string `json:"type,omitempty"` | ||
|
|
||
| // Level --security-opt="label:level:LEVEL" | ||
| Level string `json:"level,omitempty"` | ||
|
|
||
| // Disabled --security-opt="label:disable" | ||
| Disabled bool `json:"disabled,omitempty"` | ||
| } | ||
|
|
||
| // SecurityConstraints provides the constraints that at security context provider will | ||
| // ensure that applied SecurityContext requests follow. When a setting is provided in the SecurityConstraints | ||
| // that conflicts with an actual request it will be implementation specific whether that request is | ||
| // ignored and the container is still run (without the requested constraint) or if the container will be failed | ||
| type SecurityConstraints struct { | ||
|
There was a problem hiding this comment. Are you expecting that there is one SecurityConstraints for the whole cluster, or per namespace, or per user or what? There was a problem hiding this comment. These would eventually be scoped to a |
||
| // EnforcementPolicy will drive behavior for how the constraints are enforce | ||
| EnforcementPolicy SecurityConstraintPolicy `json:"enforcementPolicy,omitempty"` | ||
|
|
||
| // AllowPrivileged indicates whether this context allows privileged mode containers | ||
| AllowPrivileged bool `json:"allowPrivileged,omitempty"` | ||
|
|
||
| // SELinux provides the security constraint options for selinux | ||
| SELinux *SELinuxSecurityConstraints `json:"seLinux,omitempty"` | ||
|
|
||
| // AllowCapabilities dictates if a container can request to add or drop capabilites | ||
| AllowCapabilities bool `json:"allowCapabilities,omitempty"` | ||
|
|
||
| // AllowCapabilities dictates if a container can request to run the entry point process as a specific user | ||
| AllowRunAsUser bool `json:"allowRunAsUser,omitempty"` | ||
|
There was a problem hiding this comment. This is interesting, but there's probably a number of options here like:
That means this probably needs to be a struct. |
||
|
|
||
| // Capabilities represents, if AllowCapabilities is true, the caps that requests | ||
| // are allowed to add or drop. | ||
| Capabilities *Capabilities `json:"capabilities,omitempty"` | ||
|
|
||
| // DefaultSecurityContext is applied to any container that does not have a security context set. It must | ||
| // also conform to the constraints defined in SecurityConstraints object | ||
| DefaultSecurityContext *SecurityContext `json:"defaultSecurityContext,omitempty"` | ||
|
|
||
|
There was a problem hiding this comment. Containers (not pods) have a security context. The context is declarative:
The security provider in the kubelet, and the security context that is associated with the service account, will say what the containers can do:
One of these objects is part of the pod spec and is "do this" |
||
| // List of pod sources for which using host network is allowed. | ||
| HostNetworkSources []string | ||
| } | ||
|
|
||
| // SELinuxSecurityConstraints defines what is allowed in SecurityContext requests with regards to SELinux label options | ||
| // that are currently supported by docker | ||
| type SELinuxSecurityConstraints struct { | ||
| // AllowUserLabel --security-opt="label:user:USER" | ||
| AllowUserLabel bool `json:"allowUserLabel,omitempty"` | ||
|
|
||
| // AllowRoleLabel --security-opt="label:role:ROLE" | ||
| AllowRoleLabel bool `json:"allowRoleLabel,omitempty"` | ||
|
There was a problem hiding this comment. All of these have complex constraints that can't be captured with booleans (i.e. this doesn't look like it's being driven by the concrete requirements in the security doc). Can you include the options necessary to satisfy the requirements? There was a problem hiding this comment. do we need the ability to support the nuance of "I allow you to make requests on the container spec but will set it based on my security constraint settings if you don't"? If so the booleans are still useful and the SecurityConstraints need to be changed. There was a problem hiding this comment. Almost certainly. ----- Original Message -----
|
||
|
|
||
| // AllowTypeLabel --security-opt="label:type:TYPE" | ||
| AllowTypeLabel bool `json:"allowTypeLabel,omitempty"` | ||
|
|
||
| // AllowLevelLabel --security-opt="label:level:LEVEL" | ||
| AllowLevelLabel bool `json:"allowLevelLabel,omitempty"` | ||
|
|
||
| // AllowDisable --security-opt="label:disable" | ||
| AllowDisable bool `json:"allowDisable,omitempty"` | ||
| } | ||
|
|
||
| // SecurityConstraintPolicy dictates how the security context provider should behave with regards to contexts that | ||
| // do not meet the requirements of the policy. | ||
| type SecurityConstraintPolicy string | ||
|
|
||
| const ( | ||
| // SecurityConstraintPolicyDisabled means that any containers that do not meet policy constraints are still | ||
| // allowed to run and will be given their requested permissions. This could be used if an admin needs to allow | ||
| // a pod to run for testing without deleting and recreating the policy. Implementation may log warnings for | ||
| // permission requests that do not comply with the policy that would be enforced | ||
| SecurityConstraintPolicyDisable = "Disable" | ||
|
|
||
| // SecurityConstraintPolicyReject means that any containers that do not meet policy constraints will be rejected | ||
| // (in the case of the api server) or not run (in the case of the kubelet) | ||
| SecurityConstraintPolicyReject = "Reject" | ||
| ) | ||
|
|
||
| // These constants are for remote command execution and port forwarding and are | ||
| // used by both the client side and server side components. | ||
| // | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: Suggest you wrap this text at no more than 100 chars.