Identity, secrets, supply chain and adversarial risk.
6 items at beginner level · all topics
An application running on Amazon EC2 instances in an Auto Scaling group needs to read objects from an Amazon S3 bucket. The instances are replaced frequently as the group scales. Which approach for granting access requires the LEAST operational overhead?
Anything running on EC2 gets its permissions from an instance profile, not from credentials placed on the instance. The role is attached to the launch template, so every instance the Auto Scaling group creates is already authorised and there is nothing to distribute or rotate.
You need to grant a user permission to list nodes. Which object must the permission be defined in, and why?
Nodes are cluster-scoped, so permission on them can only be expressed in a ClusterRole, granted through a ClusterRoleBinding. A Role covers namespaced resources only.
True or false: you can stop a user who has been granted cluster-wide pod read access from reading Pods in one sensitive namespace by adding a Role in that namespace that denies it.
False. RBAC permissions are purely additive and there are no deny rules. To take access away you have to change or remove the binding that granted it.
A developer says Secrets are safe to commit to Git because Kubernetes encrypts them. What is the accurate correction?
Secret data is base64 encoded, not encrypted. Anyone with API or etcd access can read it, so protecting Secrets means RBAC plus encryption at rest, which is off by default.
A Pod is scheduled to a node but its status reads CreateContainerConfigError. The image pulled fine. What class of problem is this, and where do you look?
The kubelet could not assemble the container's configuration, usually because a referenced ConfigMap, Secret or key does not exist. The Pod events name the missing object.