thanks all for your feedback
I modified the test and hope answered to all the answers.
Q1: both column are indicated with titles "Expected Expiration Date" and
"Remaining Days"
Q2: I set a min (30) and max (389) for the validity, if certificates is not
between => test is FAIL
Q3: light changes
RED => certificate expired
Orange => < 30
Orange light < 60 or > 389
Green light: autogenerated
+ red circle / green box for root CA verification
Q4: Error table kept + Error details logged
Q5: success criteria = f(expiration_date, root_CA_validity)
Q6: xfail list created, if node port in this list, success criteria is not
modified
Q7: for the name I use the service_name already
patch in gate: https://gerrit.onap.org/r/c/integration/+/109207/5
once merged, I will integrate it in CI in the infra-healthcheck part
then I will complete this test to run it from inside the clusters and perform
it also on ingress scenario
/Morgan
________________________________________
De : Stern, Ittay [[email protected]]
Envoyé : mercredi 1 juillet 2020 06:23
À : [email protected]; ZWARICO, AMY; Krzysztof Opasiak; RICHOMME
Morgan TGI/OLN; 'Pawel Pawlak'; DESBUREAUX Sylvain TGI/OLN; ROUZAUT
Fabian TGI/OLN
Cc : Geissler, Andreas; Closset, Christophe; ROSE, DANIEL V; Lefevre,
Catherine; PLATANIA, MARCO; FREEMAN, BRIAN D; [email protected];
[email protected]; [email protected]; Kuzmicki, Krzysztof
(Nokia - PL/Wroclaw); [email protected]
Objet : RE: [onap-discuss] [ONAP] [Guilin] [SECCOM] [Integration] check
certificates, open questions and result table and success criteria
Adding my cents here; recently Apple's Safari announced the browser will not
accept certificates which expire later than 1 year ahead. Chrome will follow a
similar approach.
https://www.theregister.com/2020/02/20/apple_shorter_cert_lifetime/https://www.thesslstore.com/blog/google-chrome-to-join-apple-safari-in-one-year-certificate-validity/
These are different use-cases, but I guess it'll affect the whole industry
standard to *avoid* long-lasting certificates.
-----Original Message-----
From: [email protected] <[email protected]> On Behalf Of
ZWARICO, AMY
Sent: Wednesday, July 1, 2020 2:49 AM
To: Krzysztof Opasiak <[email protected]>; [email protected];
'Pawel Pawlak' <[email protected]>; DESBUREAUX Sylvain TGI/OLN
<[email protected]>; ROUZAUT Fabian TGI/OLN
<[email protected]>
Cc: Geissler, Andreas <[email protected]>; Closset, Christophe
<[email protected]>; ROSE, DANIEL V <[email protected]>; Lefevre,
Catherine <[email protected]>; PLATANIA, MARCO
<[email protected]>; FREEMAN, BRIAN D <[email protected]>;
[email protected]; [email protected];
[email protected]; Kuzmicki, Krzysztof (Nokia - PL/Wroclaw)
<[email protected]>; [email protected];
[email protected]
Subject: Re: [onap-discuss] [ONAP] [Guilin] [SECCOM] [Integration] check
certificates, open questions and result table and success criteria
*** Security Advisory: This Message Originated Outside of AT&T ***.
Reference http://cso.att.com/EmailSecurity/IDSP.html for more information.
Nice report!
Question 1: I'd like to see both, but if you only keep one, I agree with
Krzysztof that it should be the date
Question 2: Cert expiration - one year certs for ONAP out of the box. Industry
best practices say 2years max for client or server certs, and in practice
organizations generally renew after one year. Roots and intermediates can last
a lot longer. Yes, Krzysztof, there are use cases for more frequent renewals:
days, hours, minutes; ONAP out of the box doesn't need that.
Question 3: +1
Question 4: Keep the error table
Question 5: success criteria => expiration date + root CA (again, industry best
practice says you check both expiration date and root)
Question 6: xfail list => yes
Question 7: I can't think of anything else, but when you are at your busiest,
I'll ask you to add something. It's what I do best.
-----Original Message-----
From: Krzysztof Opasiak <[email protected]>
Sent: Tuesday, June 30, 2020 12:59 PM
To: [email protected]; ZWARICO, AMY <[email protected]>; 'Pawel Pawlak'
<[email protected]>; DESBUREAUX Sylvain TGI/OLN <[email protected]>;
ROUZAUT Fabian TGI/OLN <[email protected]>
Cc: Geissler, Andreas <[email protected]>; CLOSSET, CHRISTOPHE
<[email protected]>; ROSE, DANIEL V <[email protected]>; LEFEVRE,
CATHERINE <[email protected]>; PLATANIA, MARCO
<[email protected]>; FREEMAN, BRIAN D <[email protected]>;
[email protected]; [email protected];
[email protected]; Kuzmicki, Krzysztof (Nokia - PL/Wroclaw)
<[email protected]>; [email protected];
[email protected]
Subject: Re: [ONAP] [Guilin] [SECCOM] [Integration] check certificates, open
questions and result table and success criteria
Hi,
On 30.06.2020 17:02, [email protected] wrote:
> Hi,
>
> I updated the test to verify the certificates:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__gerrit.onap.org_r
> _c_integration_-2B_109207&d=DwID-g&c=LFYZ-o9_HUMeMTSQicvjIg&r=PJ-KGa4e
> srIcYgd1dEzHLA&m=GIWK9IfQTwItnf0yBoeIsBe9GoBeauvx8pgIPoYYMqY&s=ZgI6beA
> aU0gcdk2E_fHAvtTsP-yg1WsW4xCNl97SAYI&e=
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__protect2.fireeye
> .com_url-3Fk-3D6e831ab1-2D3357a6d9-2D6e8291fe-2D0cc47a3356b2-2D9f03ccf
> daa554d41-26q-3D1-26u-3Dhttps-253A-252F-252Fgerrit.onap.org-252Fr-252F
> c-252Fintegration-252F-252B-252F109207&d=DwID-g&c=LFYZ-o9_HUMeMTSQicvj
> Ig&r=PJ-KGa4esrIcYgd1dEzHLA&m=GIWK9IfQTwItnf0yBoeIsBe9GoBeauvx8pgIPoYY
> MqY&s=BFHWSzBjUL1TKvlweD5webTyV04P5hXNWJt-Vs8pdM8&e= >
>
> I see 3 possible "modes": nodeports, internal and ingress
>
> for the moment I worked the nodeport mode, you will find attached the
> results of the test on the daily frankfurt.
> I have some questions for SECCOM/OOM.
>
> For this test, I retrieve all the ONAP services from the kubernetes
> client, then for each service I give a try to the nodeport.
> then at the end I build a table, the main table includes the following
> fields Component = service name | Port = node port | Expiration date
> | Remaining days | Cluster IP = cluster IP associated with the node
> port | Root CA = info got from the certificate issuer | Root CA
> Validity
>
> The other tables below correspond to specific errors (SSL,
> connection,..), I do not consider them as error criteria as the test
> being executed from outside the cluster, it is usually logical to get
> the error but I prefer to keep a trace in a table.
> I should be able to test these ports in internal mode later.
>
> *Question 1*: Expiration date and Remaining days are redundant: shall
> I keep the 2 columns or keep only the remaining days?
I'm a stupid guy so I'll argue with Sylvain and Fabian and say that we should
keep certificate expiration day.
Why?
Because if someone runs the test around midnight one part of certificates may
have "90 days to go" and the other part "89 days to go"
which I expect may cause our tests to fail;)
>
> I do consider 2 parameters for the test success criteria
> - the certificate remaining days
I'd replace this with "expected expiration date" because of the reason above.
> - the root CA validity
+1
>
> The color code is as follow and can be easily amended if you have any
> recommendations or design advices
>
> remaining days
> > 1000 => line is light blue
> *Question 2*: 1000 is totally arbitrary, what is the recommendation to
> say that the certificates is probably too long > 365 > 1000 > ?
It all depends who you ask. If admin then there is no such thing as a too long
valid certificate xD
If security expert then probably 10 minutes could be too long.
Fortunately I'm non of those so I'd opt for the middle ground suggested by
Sylvain base on major browsers.
> 30< expiration < 60 => line is orange
> expiration < 30 => line is red light
> = 364 (+ Root CA OK) => line is green light => it corresponds to
> auto-generated certificates
> no color in any other case
>
> *Question 3*: are you OK with the color code?
+ 1
>
> *Question 4*: Shall I keep the error table or is it misleading >
> root CA
> if I got C=US;O=ONAP;OU=OSAAF;CN=intermediateCA_9 => I consider the Root
> CA as OK => Validity is a green square
> if not => red circle
>
> Both indicators are independent
> we can be red with a good certificate Root CA and we can be green and
> have a red circle if the certificate is still valid but the Root CA not
> correct
>
> At the end the success criteria is False is 1 of the certificate is
> under 30 days or Root CA are not correct.
> It means that it will be FAIL until everything is fxed..
I'd keep it as it brings some useful information.
>
> *Question 5*: success criteria => only expiration date or expiration
> date + root CA?
both
>
> *Question 6*: shall we plan a xfail list here?
yes. Empty for now but I expect that closer to the release we get more
"exception requests" we'll see.
>
> *Question 7*: Note I added the Cluster IP for information, any other
> info you would like to see in the table?
How about having a direct mapping to pod/service name instead of cluster
IP to make it easier for project teams to notice "hey it's my on that
list I need to do sth with it"
>
> I started working on the integration in CI
> Once open questions clarified, the code in integration repository will
> be merged
> I will create a xtesting docker (I did already one quickly in
> gitlab.com, I will create a new patch in ONAP as xtesting and its
> associated docker build chain has be reintegrated in ONAP repositories)
> I put this test in the infra-healthcheck docker (was almost ready from a
> dependency perspective)
>
> +--------------------------------+------------------+------------------+----------------+
> | TEST CASE | PROJECT | DURATION | RESULT |
> +--------------------------------+------------------+------------------+----------------+
> | nodeport_check_certs | security | 00:02 | FAIL |
> +--------------------------------+------------------+------------------+----------------+
>
>
> Once the new docker would be created, the test will be automatically
> run, I would 'just" need to adapt the dashboard to display the result of
> this test (daily and gating)
>
> /Morgan
>
>
>
>
>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.
>
--
Krzysztof Opasiak
Samsung R&D Institute Poland
Samsung Electronics
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21568): https://lists.onap.org/g/onap-discuss/message/21568
Mute This Topic: https://lists.onap.org/mt/75215203/21656
Group Owner: [email protected]
Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
