Looks like c.ctx expiring has no impact on this chain of refresh timers, it will just keep failing at backoff. Maybe this is by design (i.e. one needs to call Stop), but should probably be mentioned in the documentation?

I have removed the context parameter of the Start method type CertRefresher interface, as it is not used properly. An alternative would be removing the Stop method launching a goroutine at Start that waits on <-ctx.Done() and then stops the CertRefresher. However, I see Start and Stop methods in several interfaces in the code like SensorComponent. Also, we'll be using CertRefresher in a SensorComponent. For those two reasons I think having Start and Stop method is what works best in this case, but please let me know what you think.

It would be great to add a few sentences about how this is supposed to be used.

I've added more details, please let me know what you think

The methods in this interface are so generic that it almost seems like a waste to give it such specific name...

I have renamed this to RetryTicker that is now introduced in #350

I must say this contradiction is so striking that I'd like to find a way to relax this a bit. I can see two ways:

1. Rename ResponsesC in the interaface (and all implementations) to something like MsgsFromSensor or MsgsToCentral (in a prefactoring PR). This might require some effort (or maybe not, perhaps just an IDE-assisted rename and regenerating the mocks will be enough?) but will at least provide a hint that this channel might be used for spontaneously generated messages as well.
2. avoid the words request and response in the struct fields. Perhaps msgs{From,To}{Sensor,Central}C?

I have followed option 2., as this PR is already quite late, we can implement 1. later on if we want.
Specifically:

type sensorComponentImpl struct {
	msgFromSensorC chan *central.MsgFromSensor
	msgToSensorC   chan *central.IssueLocalScannerCertsResponse
}

which I think makes sense because we already have message MsgFromSensor and message MsgToSensor defined in sensor_iservice.proto, and IssueLocalScannerCertsResponse is a variant of message MsgToSensor

+1 to this

What's the conceptual difference between refresh and update?

That's some unfortunate naming. I have replaced that with:

• introduce an interface certSecretsRepo that certSecretsRepoImpl is implementing, that is concerned with just persisting secrets in the k8s API. updateSecrets it's now putSecrets

type certSecretsRepo interface {
	getSecrets(ctx context.Context) (map[storage.ServiceType]*v1.Secret, error)
	putSecrets(ctx context.Context, secrets map[storage.ServiceType]*v1.Secret) error
}

• refreshSecrets it's now updateSecrets, and a comment explains what this is doing:

// updateSecrets stores the certificates in the data of each corresponding secret, and then persists
// the secrets in k8s.
func (i *certIssuerImpl) updateSecrets(ctx context.Context, certificates *storage.TypedServiceCertificateSet,
	secrets map[storage.ServiceType]*v1.Secret) error {
	// FIXME: validate all fields present
        for _, cert := range certificates.GetServiceCerts() {
		secrets[cert.GetServiceType()].Data = map[string][]byte{
			mtls.ServiceCertFileName: cert.GetCert().GetCertPem(),
			mtls.CACertFileName:      certificates.GetCaPem(),
			mtls.ServiceKeyFileName:  cert.GetCert().GetKeyPem(),
		}
	}
	return i.putSecrets(ctx, secrets)
}

It should be relatively simple to create fake k8s clients if you want to use it for testing.