Complete Features
These features were completed when this image was assembled
Epic Goal
- Complete the implementation for AWS STS, including support and documentation.
Why is this important?
- Many customers want to follow best security practices for handling credentials.
- This is the way recommended by AWS.
- Customer interest: EMEA, AMER
Acceptance Criteria
- CI - MUST be running successfully with tests automated
- Release Technical Enablement - Provide necessary release enablement details and documents.
Dependencies (internal and external)
Open questions:
- Will this cover existing OCP deployments or only new OCP deployments?
- Is there a migration path for existing customers to start using AWS STS?
- Are there considerations that apply to Operators so they can work with limited privilege credentials?
Done Checklist
- CI - CI is running, tests are automated and merged.
- Release Enablement <link to Feature Enablement Presentation>
- DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
- DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
- DEV - Downstream build attached to advisory: <link to errata>
- QE - Test plans in Polarion: <link or reference to Polarion>
- QE - Automated tests merged: <link or reference to automated tests>
- DOC - Downstream documentation merged: <link to meaningful PR>
ccoctl should be able to delete AWS resources it created
ccoctl delete <infra-name>
The tool should be able to upload an OpenID Connect (OIDC) configuration to an S3 bucket, and create an AWS IAM Identity Provider that trusts identities from the OIDC provider. It should take infra name as input so that user can identify all the resources created in AWS. Make sure that resources created in AWS are tagged appropriately.
Sample command with existing key pair:
tool-name create identity-provider <infra-name> --public-key ./path/to/public/key
Ensure the Identity Provider includes audience config for both the in-cluster components ('openshift') and the pod-identity-webhook ('sts.amazonaws.com').
Research if we can dynamically reserve memory and CPU for nodes.
Feature Overview
Openshift Sandboxed Containers provide the ability to add an additional layer of isolation through virtualization for many workloads. The main way to enable the use of katacontainers on an Openshift Cluster is by first installing the Operator (for more information about operator enablement check [1]).
Once the feature is enabled on the cluster, it just a matter of a one-liner YAML modification on the pod/deployment level to run the workload using katacontianers. That might sound easy for some, but for others who don't care about YAML they might want more abstractions on how to use katacontainers for their workloads.
This feature covers all the efforts required to integrate and present Kata in Openshift UI (console) to cater to all user personas.
Background, and strategic fit
To enable for users to adopt Kata as a runtime, it is important to make it easy to use. Adding hook-points in the UI with ease-of-use as a goal in mind is one way to bring in more users.
Goal(s)
The main goal of this feature is to make sure that:
- It is easy for users to find out how to use/enable Openshift Sandboxed Containers on their clusters (e.g., Getting started guide in the UI).
- Cluster-admins are able to differentiate between normal pods and Kata pods.
- Developers (application, CNF, ...) have an easy way to create Katacontiners (without peeking at YAMLs)
- Application End-users are able to collectively activate kata on their app packages/content (e.g., Helm, odo,...)
Documentation Considerations
Questions to be addressed:
- What educational or reference material (docs) is required to support this product feature? For users/admins? Other functions (security officers, etc)?
- Does this feature have doc impact?
- New Content, Updates to existing content, Release Note, or No Doc Impact
- If unsure and no Technical Writer is available, please contact Content Strategy.
- What concepts do customers need to understand to be successful in [action]?
- How do we expect customers will use the feature? For what purpose(s)?
- What reference material might a customer want/need to complete [action]?
- Is there source material that can be used as a reference for the Technical Writer in writing the content? If yes, please link if available.
- What is the doc impact (New Content, Updates to existing content, or Release Note)?
References
[1] https://issues.redhat.com/browse/KATA-429?jql=project %3D KATA AND issuetype %3D Feature
Goal
The grand goal is to improve the usability of Kata from Openshift UI. This EPIC aims to cover only a subset that would help:
- Make it easy to differentiate between native cluster runtime (e.g., runC) and kata.
- Enable Kata as a runtime without modifying YAMLs.
To use a different runtime e.g., Kata, the "runtimeClassName" will be set to the desired low-level runtime. Also please see [1]:
"RuntimeClassName refers to a RuntimeClass object in the node.k8s.io group, which should be used to run this pod. If no RuntimeClass resource matches the named class, the pod will not be run. If unset or empty, the "legacy" RuntimeClass will be used, which is an implicit class with an empty definition that uses the default runtime handler. More info: https://git.k8s.io/enhancements/keps/sig-node/runtime-class.md This is a beta feature as of Kubernetes v1.14.."
apiVersion: v1 kind: Pod metadata: name: nginx-runc spec: runtimeClassName: runC
The value of the runtime class cannot be changed on the pod level, but it can be changed on the deployment level
apiVersion: apps/v1
kind: Deployment
metadata:
name: sandboxed-nginx
spec:
replicas: 2
selector:
matchLabels:
app: sandboxed-nginx
template:
metadata:
labels:
app: sandboxed-nginx
spec:
runtimeClassName: kata. # ---> This can be changed
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
protocol: TCP
User-stories
- As a cluster-admin, I would like to be able to differentiate between a normal pod and a Katacontainer pod from the UI.
- As a developer, I would like to create katacontainers-based pods without dealing with YAML, i.e., from the UI.
- As a developer, I would like to switch my deployments to use Kata instead on runC (native).
Requirements
- Kata runtime MUST be viewable when checking running workloads.
- A checkbox or a similar method to create Katacontainers from the UI MUST be provided.
- The above two requirements MUST be tested.
References
[1] https://docs.openshift.com/container-platform/4.6/rest_api/workloads_apis/pod-core-v1.html
We should show the runtime class on workloads pages and add a badge to the heading in the case a workload uses Kata. A workload uses Kata if its pod template has `runtimeClassName` set to `kata`.
Acceptance Criteria:
- Kata runtime must be viewable when checking running workloads, including Pods, ReplicaSets, ReplicationControllers, StatefulSets, Deployments, and DeploymentConfigs.
- Automated test must be written to verify coverage
Andrew Ronaldson indicated that adding a "kata" badge in the heading would be too much noise around other heading badges (ContainerCreating, Failed, etc).
