Closed mayleighnmyers closed 2 months ago
Would you like to close the previous #1004 PR ?
/test maistra-istio-lint-2-6
/test maistra-istio-unit-2-6
/test maistra-istio-unit-2-6
I wonder if this is necessary, since in Istio 1.20 we already have this feature on upstream...
@jwendell are you talking about 056d019? It is only available since 1.21. Maistra-2.6 is based on 1.20.
@yannuil https://github.com/istio/istio/pull/45394 and follow ups
@jwendell I think we need this change, because your upstream implementation requires permissions for namespaces.
@jwendell I think we need this change, because your upstream implementation requires permissions for namespaces.
If I understand correctly, we should not be using the GetProxyIDs
function defined in pkg/kube/inject/inject.go
.
// GetProxyIDs returns the UID and GID to be used in the RunAsUser and RunAsGroup fields in the template
// Inspects the namespace metadata for hints and fallbacks to the usual value of 1337.
func GetProxyIDs(namespace *corev1.Namespace) (uid int64, gid int64) {
uid = constants.DefaultProxyUIDInt
gid = constants.DefaultProxyUIDInt
if namespace == nil {
return
}
// Check for OpenShift specifics and returns the max number in the range specified in the namespace annotation
if _, uidMax, err := getPreallocatedUIDRange(namespace); err == nil {
uid = *uidMax
}
if groups, err := getPreallocatedSupplementalGroups(namespace); err == nil && len(groups) > 0 {
gid = groups[0].Max
}
return
}
If this is the case, the following lines (410-425) in the same file need to be changed to instead use the constants DefaultSidecarProxyUID
and DefaultSidecarProxyGID
:
proxyUID, proxyGID := GetProxyIDs(params.namespace)
data := SidecarTemplateData{
TypeMeta: params.typeMeta,
DeploymentMeta: params.deployMeta,
ObjectMeta: strippedPod.ObjectMeta,
Spec: strippedPod.Spec,
ProxyConfig: params.proxyConfig,
MeshConfig: meshConfig,
Values: params.valuesConfig.asMap,
Revision: params.revision,
ProxyImage: ProxyImage(params.valuesConfig.asStruct, params.proxyConfig.Image, strippedPod.Annotations),
ProxyUID: proxyUID,
ProxyGID: proxyGID,
CompliancePolicy: common_features.CompliancePolicy,
}
@jewertow @eoinfennessy It's still not clear to me why we can't rely on upstream solution. Can you tell me more?
Is it because pilot reads namespace annotations and thus requires namespace reading permissions? Doesn't it already have this permission for all SMMR members? If not, can't we just add this permission?
@jewertow @eoinfennessy It's still not clear to me why we can't rely on upstream solution. Can you tell me more?
@jwendell, sorry, I'm also unsure why we can't use the changes that you contributed upstream, or what exactly the namespace permissions issue is.
Doesn't it already have this permission for all SMMR members? If not, can't we just add this permission?
@jwendell no, we can't grant permissions for particular namespaces, because it's a cluster-scoped resource. You can grant access to all of them or none.
We actually can grant permissions to specific Namespace
objects (using ClusterRole.rules.resourceNames
), but I'm not sure if we should. We definitely can't grant write permissions, but even read permissions might be problematic in some cases. Users typically don't have access to the namespaces (not even read-only access). We should definitely consult with the security folks about this.
On a side note, if it turns out we can give read access to the namespaces, we can remove the locality controller (the one that copies Namespace labels to Pods).
Actually, if we can't give read access to the namespaces, we could extend the locality controller so that it also copies the userid range from the Namespace to the Pod so that the injection webhook could get the information from the Pod instead of the Namespace.
@luksa thanks for correcting me.
I am still not sure that it's worth to do it, because we would have to implement additional logic in the operator to apply proper cluster role bindings on SMMR changes. Additionally, xns-informer knows only the namespace names, so we would have to change the namespace controller and all other components that rely on it.
@jewertow, ah, of course, the Namespace object is retrieved from the informer/lister, which means giving GET permissions only to specific Namespaces won't suffice, since the lister performs a LIST operation.
Anyway, in Sail, we don't have this problem, since istiod has the permission to list namespaces, so whatever solution we come up with, is only needed in 2.6 (and only in MultiTenant mode). And since we already have a solution for this in this PR, we might as well merge it.
Superseded by https://github.com/maistra/istio/pull/1019
Safe to close this one, right?
@mayleighnmyers Thank you for your effort here!
[proxy-uid] OSSM-2292: Run sidecars with dynamically-determined user IDs (#689)
Squashed commit, incorporates changes from:
MAISTRA-551 Run sidecar with a dynamically-determined runAsUser ID
MAISTRA-611 Partial injection of just the annotation and runAsUser id
MAISTRA-668 Fix expected output of webhook injection
The sidecar injector now sets the securityContext.runAsUser field regardless if it is specified in the sidecar template or not. This is to allow the sidecar template to not include the field, which is required to ensure that istioctl kube-inject outputs manifests that pass the SCC admission controller (if the runAsUser is specified, the SCC controller will reject the pod, as the uid won't be in the proper range). The sidecar injector then injects the correct runAsUser id even if it isn't specified in the template.
MAISTRA-1751: Set securityContext.fsGroup to comply with restricted SCC (#256)
This is a rewrite of 46f0f4a819 for the Maistra 2.1 / Istio 1.8 rebase.
MAISTRA-2452 Apply dynamically-determined user ID to the istio-validation init container
[maistra-2.3] OSSM-1847 ensure ProxyUID and ProxyGID are initialized when using gat… (#618)
OSSM-1847 ensure ProxyUID and ProxyGID are initialized when using gateway injection template
do not default ProxyUID and ProxyGID for gateways
initialize ProxyGID appropriately for gateway injection
fix(gen): runs make gen
chore: combines cni plugins golden files gen into one invocation
[maistra-2.4] OSSM-2324 Ensure ProxyUID and ProxyGID are never nil (#703)
If they are nil, Helm renders them as "nil" (with quotes), which the YAML parser can't parse as a float.
Please provide a description of this PR:
To help us figure out who should review this PR, please put an X in all the areas that this PR affects.
Please check any characteristics that apply to this pull request.